B2C · Live
One moment.
Every screen.
A synchronized gender reveal experience: second-perfect countdowns, real-time voting and a shared reveal animation that fires on every device at once, anywhere in the world.
- Role
- Sole engineer, designer and operator
- Timeline
- 2025 — live
- Live at
- revealtogether.com ↗
The problem
A gender reveal is one moment. When half the family is on another continent, that moment stops being shared — someone finds out from a video call three seconds late, or from a group chat, and the surprise is already spent.
The product is not a video player. It is a promise that the reveal happens at the same instant on every screen, whether the guest is in the room or six time zones away.
Constraints
Simultaneity is the product
If one guest sees the result before another, the feature has failed in the only way that matters. Clock skew between devices, network latency and render time all had to fit inside a budget small enough that nobody perceives an order.
The event happens once
There is no retry. A party at 4pm is not reschedulable because a deploy went wrong. This is the constraint that drives everything else: changes ship away from live events, and the system degrades toward showing the reveal rather than toward showing an error.
Guests never sign up
Anything standing between a grandparent and the reveal is a failure. Guests open a link and are in — no account, no app, no install. The host is the only person who ever authenticates.
Three languages, from the first line
English, French and Spanish are not a translation layer added later. Sub-path routing, hreflang and locale-aware URLs were structural from the start, because retrofitting them into an indexed site is a migration nobody enjoys.
Decisions
- 01
A server-held countdown, not a client timer
Devices disagree about what time it is. The reveal fires from a shared server clock and clients synchronize to it, rather than each device counting down on its own and hoping they agree.
- 02
WebSockets for the moment, HTTP for everything around it
Live voting and the reveal itself need a push channel. Setup, payment and dashboards do not. Keeping the real-time surface deliberately small keeps the part that must not fail small too.
- 03
A Java backend beside a Next.js front end
The reveal path lives in the stack I trust for stateful, long-lived connections. The marketing site, the funnel and the content live where they are fastest to iterate. The seam between them is a contract that is versioned rather than assumed.
- 04
Treat the API contract as breaking by default
The guest client rejects response keys it does not recognize. That was a costly thing to learn, and the lesson stuck: adding a field to a public endpoint is a breaking change until proven otherwise.
Where it landed
- Families served
- 1K+
- Countries
- 40+
- Languages, fully localized
- 3
- Real time
- Java · WebSockets · Redis
- Application
- Next.js · React · i18n sub-path routing
- Commerce & lifecycle
- Stripe · Transactional email · Analytics