How good does an AI feature have to be before launch? Nine operators on where the bar actually sits.

Dmitri Dolgov opened his YC talk by separating two things founders routinely merge: an early working prototype, and a production-grade service. The gap between them is not a percentage of remaining effort. Dolgov describes reliability as living on an exponential ladder of nines, where climbing from 90 percent to 99 is expensive and climbing from 99 to 99.9 costs more again. Each nine is a different engineering problem, not more of the last one.

Waymo now drives over four million fully autonomous miles every week, and that number is what the ladder buys after years of paying for it. The founder version is smaller and identical in shape. Your demo cleared the first rung. Price the rest of the climb before you promise anyone a date.

Kavak sells used cars, finances them and moves them, and now runs 96 percent of customer interactions and 95 percent of transactions through agents. That is not a pilot. The thing their team credits for the speed is evals, and the word they use is brakes. A car with no brakes does not go faster.

It goes slower, because the driver never commits to a corner. Evals do the same job for a shipping team. They let you change a prompt, swap a model or widen a workflow on a Tuesday and know by Tuesday afternoon whether you broke a customer path. Without them every change is a guess, so every change gets deferred, and the team that skipped the eval suite to move faster ends up moving slowest.

Peter Steinberger maintains an open-source agent with thousands of contributors, so his code review problem is the extreme version of yours. His answer is to stop treating review as reading. He treats it as risk management: the question is not whether every line is correct, it is what breaks if this is wrong and who it hurts. That reframe scales down to a solo founder shipping AI-written code, where reading every line is both impossible and beside the point.

The model wrote it faster than you can audit it. What you can audit is blast radius. His companion rule for early product points the same instinct at scope: build what annoys you, for your first users, and let the irritation choose the work.

The failures that hurt are the ones your real traffic almost never produces. Waymo answers with large-scale generative world models and closed-loop simulation, built to train and evaluate against rare scenarios a fleet would take years to encounter naturally. Closed-loop is the load-bearing word: the simulated world reacts to what the agent does, so you are testing a whole chain of decisions instead of one frozen input. Founders read this as a self-driving budget problem and skip it.

The cheap version is not a budget problem. Take the ten weirdest inputs your product has ever seen, the malformed paste, the hostile prompt, the empty state, the customer who typed in a second language, and make them a fixture. You do not need a world model to stop being surprised by the same ten things.

OpenClaw went vertical on Discord over New Year's Eve, and the reward was not a moat. It was security pressure, false media claims about malicious skills, and a codebase carrying thousands of configuration options plus dependency churn nobody had signed up to manage. Every option is a supported path. Every supported path has to keep working, get documented and get patched.

Flexibility feels free while you are building and turns expensive the moment strangers arrive, which for an AI product is also the moment the option space becomes an attack surface. The launch-readiness read is blunt: an unshipped setting is cheaper to delete than to defend, and the number of switches you expose is a reliability decision wearing a product costume.

Brett gave AI seven days to get real users for an app and spent two of them building. The first paying customer arrived on day four, immediately after he fixed a geo-targeting setting that had been quietly buying junk traffic and repaired the mobile onboarding bugs killing completion. Neither fix was a feature. Both were worth more than one.

The pattern generalizes past paid ads: an AI product that answers well and loses people at the third screen has a plumbing problem, not a model problem, and model problems are the ones founders enjoy solving. He finished at a 15 dollar acquisition cost with seven trials on day six, a validation signal produced almost entirely by debugging the path he had already built.

Enterprise AI pilots have a way of becoming permanent residents. The a16z sales conversation names the fix without ceremony: set a hard end date and written success criteria before the proof of concept starts, or you are running a science project on your own payroll. For an AI feature this matters more than it does for ordinary software, because a pilot with no bar can always be extended on the promise that the next model release will close the gap. It usually will not close the gap you care about, and while you wait the pilot eats the engineering attention that would have won a second customer.

The end date is what converts a pilot into either revenue or a decision.

Matt Swulinski, who ran growth at Superhuman and Wispr Flow, treats a three-to-one ratio of lifetime value to acquisition cost as the target and flags where AI products quietly miss it. Inference is a variable cost that moves with usage, so the customer who loves your product most is also the one eroding your margin fastest. Traditional software has the opposite shape, which means the instinct founders bring to this is wrong by default. He is equally direct that early burn is acceptable while you are still learning.

What is not acceptable is a model of the business with tokens left out of it, because then you cannot tell growth from a leak. Launch readiness includes your cost per heavy user, not just your cost per signup.

Greg Isenberg's answer to why the SaaS apocalypse keeps not arriving is unglamorous and correct. Enterprises stay on established tools because software maintenance is a real pain they are paying somebody else to own, and because they need a clear accountability structure when something goes wrong. AI-only vendors cannot sign that line yet. For a founder selling into any company with a procurement process, this belongs on the launch checklist.

Somebody has to be answerable when the agent gets a number wrong, and if your answer is that the model did it, the product is not finished. The bar was never perfect output. It is a named owner, a way to detect the error, and a path to make the customer whole.