The launch date was fixed before I started. Twelve weeks from a private beta that worked to a public launch, a consumer AI product, open to anyone with a card. The part I worried about least was the product.

The engineering was genuinely hard. It’s just that by the time there’s a date on a calendar, the product question has usually been answered. Someone has already decided what the thing is and roughly how it behaves. What hasn’t been decided, and what quietly eats a twelve-week window, is everything that has to be true before you’re allowed to sell it to strangers.

I’ve done a few of these now and the shape repeats. Even so, I’ve never read a launch retrospective that spends its length on refund paths, gate cohorts, and who is allowed to halt a launch at three in the morning. Those are the things that decide whether you open on time.

A fixed date is what makes cuts real #

When the date can move, the cut list is theoretical. Something slips every week and nothing gets dropped, because slipping is free while the date is soft. A fixed date turns a slip into a decision with somebody’s name on it, which is the only reason cuts happen at all.

I used a four-part test and wrote it down in week one. Does it deliver the core experience. Does it take money correctly. Does it keep the product from doing harm. Does it tell us when it’s broken. Anything that failed all four waited, and some of what waited was more interesting than what we kept. The deferrals were all internal, the things only we would ever see.

By week nine everyone is arguing about the same item and nobody remembers the rule, which is why it goes in writing in week one.

Billing is not the checkout page #

The checkout page can be a couple of days of work. Everything after the charge succeeds is where the weeks go.

Start with the failure that the happy path hides. A charge can settle while provisioning doesn’t, and then somebody has paid for something they can’t reach. They won’t see it until they try to use the product, and you won’t see it at all unless you’re specifically watching the gap between who paid and who’s entitled. Reconciling those two lists is its own piece of work, and it belongs in the design rather than in the incident review.

Then refunds, which have to be issuable by someone who can’t deploy. If a refund needs an engineer, then some engineer is doing refunds at two in the morning instead of watching the thing they built.

Webhooks are the third one. Stripe may deliver the same event more than once, and doesn’t guarantee that events arrive in the order they were generated. Idempotency at that boundary is what separates a correct ledger from a support queue.

Underneath all of it sits the account state table, which I wrote before any of the billing code. Every state an account can be in, what each one permits, and what moves it to the next. Trialing, active, past due, canceled, refunded, and a safety hold, which is really its own dimension that the table flattened into a row. That table turned out to be the billing system. The rest was plumbing.

The number of consumer products that can charge you correctly but can’t stop charging you correctly is not small. That asymmetry exists because taking money is the part somebody demos.

The beta gate is a commercial instrument #

As engineering, a beta gate is invite codes and a waitlist, a week of work at most. As a commercial instrument it gives you a controllable middle ground between nobody and everybody, and it pays to treat it that way.

Ramping load is the obvious reason to have one and the least interesting. What mattered more is that your first public cohort is what the internet decides your product is, and you want to choose that cohort rather than receive it.

The gate also has to close. A gate that only opens is a switch, and a switch makes the launch irreversible on exactly the day you’d most like it reversible. Keeping ours closeable meant that opening on schedule didn’t have to be a bet.

One detail that’s easy to get wrong. Enforce the gate where the money is, which is generation, not only at signup. A gate on the front door with an open side entrance to the expensive path is decoration.

You have to know it’s broken before your users tell you #

During a launch the question is never whether the site is up. It’s whether anyone is stuck between paying and receiving.

So I put everything on one screen: errors, edge traffic, payment events, security alerts. One screen, not because a unified dashboard is elegant, but because during launch week nobody checks four dashboards. They check one, or they check none and find out from somebody tweeting at them.

The signals worth watching turned out to be ratios rather than counts. Successful generations per paying session. Failed payments as a share of attempts. Error rate by route instead of in aggregate. Counts spike on launch day for entirely good reasons, so a count tells you almost nothing on the one day you need it to.

What twelve weeks costs #

Twelve weeks works when the product decision is already made. It compresses execution, not discovery. If “what is this product” is still open in week one, the date is fiction and everyone involved knows it by week four.

You also carry debt, and the only real choice is where. I put ours in internal tooling and reporting, the things only we would ever look at. Not in billing correctness, gate enforcement, or the safety checks, because those are the places where the bill arrives with interest and in public.

The last one is smaller than it sounds, and I’d do it earlier next time. Decide before launch week who is allowed to say stop. There’s always a moment where somebody has to judge whether an anomaly is worth pausing signups over, and if nobody has been named in advance, it falls to whoever happens to be awake.

I still find it a bit funny that most of a launch went on refunds and gates, and that the artifact I’m proudest of is a table of six account states. Nobody asks about that part afterwards. It’s what decided whether we opened, though, so it may as well get written down somewhere.