When Is a Product Ready to Launch?

Altitude: the founder journey

I've spent the last few weeks deep in a video production process for ka-do, built as automated tests rather than screen recordings, and I want to be honest about what that's involved: some genuinely productive building, and some genuine rabbit holes. Automated screenshot decks. Per-step clip libraries. AI review passes on the footage. Somewhere in the middle of it, the question every founder circles started circling me: when is this thing actually ready to launch?

I don't have a date to announce. What I have is something more useful: I accidentally answered the question while building a tool for a different one.

The answer that doesn't work

The default answer to "when is it ready?" is a feeling. You'll know. It'll feel done. And I can report from the field that the feeling does not arrive, because the process that would produce it works against itself: the closer you look at a product, the more you find, and a founder pre-launch does nothing but look. Every review pass generates findings. Every finding, fixed, sharpens your eye for the next one. "Ready" recedes at exactly the speed you approach it, which is why waiting for the feeling is how products stay six months from launch for three years.

I've caught this pattern before, on the front door rather than the launch date (see I Built the Whole Product Before I Fixed the Front Door). I know this pattern from twenty years of programme delivery, where it has a less romantic name: no go-live criteria. A programme that hasn't defined "done" in advance will discover, at every review gate, new reasons it isn't. The fix there was never trying harder to feel confident. It was writing down, before you look, what would count as good enough, and then being bound by your own answer.

What I built instead of an answer

Here's where the rabbit hole earned its keep. As part of the video work, I built a review harness: each recorded walkthrough of the app gets bundled up (screenshots per step, clips, the full recording, a ground-truth file of what each step was supposed to do) and handed to an AI reviewer with written instructions. The reviewer reports defects against the ground truth, scores the flow on several dimensions, and checks everything it finds against a ledger of known issues that already have decisions attached: fixed, deferred, or working as intended.

Two pieces of that prompt turned out to matter more than the rest. The first is the stop condition. The instructions literally say that a review scoring above the bar is good enough, so act on its findings and move on rather than re-running or re-tuning. Two failed revisions means the approach is wrong, not the wording; stop tweaking and reassess. I wrote that clause because I know myself. Without it, I would tune that prompt forever, and tuning feels exactly like working.

The second is the known-issues ledger: not a list of everything wrong, but a list of everything wrong that has a decision written down. Deferred, with a reason. Working as intended, with a rationale. The reviewer is instructed not to re-report those, which means the review converges instead of churning: each pass surfaces only what's new or regressed, and the noise of relitigating settled questions goes to zero.

I built all that to review fifty-second videos. It took me an embarrassing while to notice it was the launch question, answered in miniature.

Ready is a bar you set before you look

Because here's what the harness actually encodes: readiness is not a property you discover in the product. It's a bar you define before inspecting it, plus a stop condition that binds you when it's met. The score answers "is this good enough" only because "good enough" was written down first. The stop condition exists because the person doing the looking cannot be trusted to stop otherwise. Not from weakness, but because looking always finds more, and finding more always feels like diligence.

And the known-issues ledger is the part most founders miss about what shipping actually is. A launched product is not a product with no known issues. It's a product whose known issues have decisions attached. Deferred, with a reason you'd say out loud. Working as intended, with a rationale you'd defend. The difference between "not ready" and "ready" is rarely the defect count; it's whether the defect list has been converted from an anxiety into a set of choices someone has signed.

So my answer to the question, arrived at sideways: a product is ready to launch when it clears a bar you set before you started looking, and everything below that bar has a written decision against it. Anything else (any version where readiness is a feeling you're waiting to have) isn't a launch criterion. It's a way of never being wrong by never being done.

The honest coda

Two admissions, in the spirit this blog runs on. First: building a review harness to avoid over-reviewing is, yes, a suspiciously elaborate way to manage one's own tendencies, and for a while I genuinely couldn't tell whether it was infrastructure or the most sophisticated rabbit hole yet. The test that settled it is one I'd offer to any solo builder staring down their own version: a rabbit hole ends where it started, with nothing reusable; infrastructure comes back with a tool that has a stop condition attached. This came back.

Second: I haven't launched yet. This post isn't written from the far shore; it's written by someone who just noticed he'd built the instrument he'll be held to. The bar is being set now, before the final looking begins. Whether I obey my own stop condition when it triggers: that's a future post, and I already know it'll be an honest one, because the clause is in writing and this blog is where I'd have to account for it.

It's the same planning document that's forced me to correct course before, as The Day My Planning Doc Corrected Me tells it.

Steve is building ka-do in the open, one stop condition at a time.