The AI app you ship in eight weeks: what production-ready means

'Production-ready' is the most quietly abused phrase in AI work. It gets attached to a demo that worked once, on a laptop, on data someone chose. A demo is a proof that the thing is possible. Production-ready is a proof that it is reliable, and the distance between those two claims is where most AI projects quietly die. It is worth saying concretely what closes that distance, because production-ready should mean a specific set of things or it means nothing at all.

A demo and a production system can look identical in a screen recording. They differ in what you cannot see. The demo runs on inputs that were, consciously or not, curated: the clean record, the well-lit invoice, the question phrased the way the builder expected. It has no evaluation set, so nobody can say whether the next answer will be as good as the one on screen. It has no monitoring, so when it drifts, the first signal is a complaint. It has no error path, so the moment a malformed input arrives, the behaviour is undefined. And it has no human lane for the cases that should not be decided by a model. None of that shows up in the recording, which is exactly why the demo is convincing and the production system is hard. The demo is not dishonest about any of this. The people who built it never had to meet the inputs they did not choose, and everything that makes production hard lives precisely in the inputs nobody would put on a slide: the malformed, the empty, the surprising, the ones that arrive at the worst possible moment.

So the first artifact we write is the evaluation set, before the model, before the interface, before anything that photographs well. It is a fixed collection of real inputs with judged correct answers, drawn from the actual data including its ugly parts: the typo, the half-missing record, the request phrased three different ways. A threshold gets attached to it, the level of performance below which the system does not ship. This is unglamorous, and it is the single highest-leverage decision in the build, because everything downstream (which model, which retrieval, whether a given change helped or hurt) can only be judged against it. Teams that skip it are not moving faster. They have just chosen not to know whether the thing works.

The second thing production-ready means is that the boring ninety percent is handled. A demo shows the interesting path: the clever extraction, the fluent answer. A production system spends most of its code on the unglamorous remainder. What happens when the input is empty, malformed, or in a format nobody anticipated. What happens when the model is slow or unavailable. What happens when confidence is low. What gets logged, what gets retried, what gets escalated. This is ordinary software engineering, it is most of the work, and its absence is the difference between something that survives a Tuesday and something that only survives a rehearsal. Teams underweight this remainder consistently, because it is invisible in every artifact that ever gets shown: the slide, the recording, the update to the sponsor. It becomes visible in exactly one place, the first week of real traffic, which is the most expensive place there is to discover it.

Third, there is a human review lane, and it is designed rather than improvised. Routine outputs auto-execute; the consequential ones route to a named person with the context assembled and their decision logged. This is not a hedge against a weak model. It is how a serious system draws the line between what is cheap to get wrong and what is not, and it is the same design whether the domain is a newsroom, a lender, or a clinic. Six months later, when someone asks who approved a particular output and why, the system can answer. That answer is part of what production means.

This is why the engagement has the shape it does. Scope produces a written plan and a single success metric both sides agree on before any code is written. Build runs as weekly demos on your data, not slides, so the thing is exercised against reality from the first week rather than the last, and an eval suite comes with it. Ship deploys into your stack, behind your systems, wired to the tools you already run, with monitoring and runbooks. Operate means we stay until it is boring: the monitoring quiet, the escalations rare, the surprises gone. A bounded first build of this shape tends to fit in roughly eight weeks, not because eight weeks is magic, but because a scope that cannot reach boring-in-production in that window is usually a scope trying to do too much at once. The weekly rhythm is the real safeguard. A system exercised against your data every week cannot hide its failures until the end, because there is no end to hide them in, only the next demo. Problems that would otherwise ambush a launch surface in week two instead, when they are cheap to fix and nobody has staked a date on them yet.

The evidence that production is a real and reachable bar, not a marketing word, is that our principals have cleared it repeatedly. One built fifteen production AI applications on top of a thirty-million-document index at a national newsroom. Not fifteen demos: fifteen systems editors depended on every day, with the search staying up and the outputs staying accurate inside the workflow people already used. Fifteen is a number you only reach if production means something specific and you hit it every time. That is the bar we build to. The demo is the easy part, and we treat it as the start of the work, not the end of it. We lead with that record not to impress but to set an expectation. When we say we will make something production-ready, we mean the specific list above, and we would rather lose a deal by being clear about that bar than win one by quietly lowering it.