We Shipped an Insurance Product in a Week. Here's What That Actually Means

Week one buys you information, not a product

The point of shipping in a week was never to declare the product done. It was to stop arguing about a hypothesis we could test. Employee benefits is a category where everyone has an opinion about what HR teams and employees want, and none of those opinions are worth as much as one real enrolment.

So the first version answered exactly one question: will people actually opt in and pay for voluntary cover through this flow? Everything that wasn't required to answer that question got cut. That's not speed for its own sake, it's a decision about what you're willing to be wrong about in public.

The five weeks are where insurance products are actually built

Insurance is not a category where a happy path is enough. Premium calculation has to be right. Edge cases around eligibility, dependents, and enrolment windows have to be right. If you get the pricing wrong, you don't ship a bug, you ship a liability.

The five weeks after launch were spent on exactly those things, in the order that real usage told us mattered. That's the trade I'd defend to anyone: launch narrow and hard-coded where you must, then let live behaviour tell you which edge case to build first, instead of a workshop guessing at all of them.

Speed comes from what you already own

We could move that fast because we weren't starting from zero. The platform already had enrolment, corporate onboarding, and the endorsement machinery running for 55+ corporates and 45,000+ users. GVL was a new product riding on infrastructure that had already survived contact with reality.

This is the honest caveat to every "we shipped it in a week" story. Week-one delivery is usually the visible tip of two years of unglamorous platform work. When I plan a 0→1 product now, the first question is which existing rails it can run on, because that's what decides the timeline far more than scope does.

Agile only works if the loop actually closes

Iterating to maturity in five weeks required release discipline more than it required velocity. Tracking QA health, sprint progress, bug closure rates, and release timelines across three products isn't glamorous, but without it "iterate" just means "ship half-finished things repeatedly".

The loop closes when a defect found in week two changes what's in the sprint for week three. If your backlog is immune to what you learned last release, you're not iterating, you're just deploying on a schedule.

What I'd do again

Launch small, but be explicit about which parts are provisional and which are permanent. Write down the question the first release is meant to answer. And treat the weeks after launch as part of the launch, because in insurance, the product isn't real until the unhappy paths work.