Demo-ready versus production-ready

Demo-ready software is the version that clicks through: happy path, right screens, one afternoon with a good agent. Production-ready is the version an organisation can sell, support, and keep running. The last mile between the two is still the hard part, and AI didn’t close it.

Two years of the author’s work with AI tools show a substantial reduction in the cost of demos. Producing software ready for production remains difficult. Confusing the two leads to unrealistic expectations and missed engineering work.

Demo-ready: the thing AI made cheap

A demo has screens, calls the intended API and handles the happy path. With a capable agent and a clear brief, it can take an afternoon instead of a fortnight.

A working demo helps stakeholders assess a product. A product owner can evaluate the flow, a designer can assess copy in context and a compliance lead can identify fields that need logging. Concrete feedback can arrive in twenty minutes where a document might take twenty hours. This makes prototypes useful before the build.

A demo supplies evidence for product decisions. It still needs the engineering work described below before it is ready for production.

Production-ready: the thing that stayed hard

Production readiness requires software that an organisation can sell, support and operate reliably. It includes the following work:

The cases the demo didn’t exercise. Empty inputs, enormous inputs, unicode, negative numbers, simultaneous writes, expired sessions, partial failures from third parties. Real users will hit every one of these within a week. The demo will not have hit any of them. The agent didn’t invent the edge cases the demo skipped; it followed the brief, and the brief was the happy path.

The decisions the agent made without telling you. Agents choose schemas, retry policies, error messages and default permissions to produce running code. Those choices become product policies even when the team has neither approved nor recorded them.

The supportability layer. Production software needs searchable logs, useful alerting metrics and identifiable errors. Operations teams need these capabilities to diagnose failures and keep the service running.

The security posture. Auth, authorisation, input validation, secrets handling, audit logging, the things compliance will look for whether you did them on purpose or not. The agent will produce code that compiles regardless of how the auth is wired; it won’t produce code that’s right unless the requirement said so explicitly. Most demo briefs don’t say so explicitly.

The maintenance horizon. Behaviour must remain correct as later features change the system. Traceability and maintained tests preserve that evidence. Code Nodes also preserve the criterion-to-code link: if a later refactor breaks the reference, validation flags it and blocks shipping until it is resolved.

These requirements predate AI. A running AI-built demo can make them easier to overlook in the delivery schedule.

The gap, plainly

The gap between demo-ready and production-ready isn’t a fixed ratio. It varies enormously by domain. Greenfield SaaS in a forgiving regulatory environment, where users can be retrained on a bad release, has a smaller gap than financial software running through a regulator’s audit cycle. A consumer app where a bad release means a one-star review has a smaller gap than an internal tool that thousands of people depend on hourly. The shape is the same in every case; the size of the gap is project-specific.

What’s constant is the structural difference. Demo-ready proves the thing could exist. Production-ready proves the thing does exist, behaves the way the team committed to, and won’t degrade silently. The mechanism for that second thing is documents, tests, traceability, and a disciplined build cycle, none of which the demo had.

The dangerous version of this

Product owners and executives can now build demos themselves in an afternoon. Some recognise them as prototypes. Others assume the hard work is complete and underestimate the engineering required to review and prepare them for production. This misconception is likely to create substantial industry problems over the next year or two.

Most of the work remains, and many companies lack a plan to ship, fund and support AI-built demos. McKinsey’s State of AI work reports broad adoption but material business value for only a small minority, with most organisations still working out how to scale beyond pilots. This is consistent with the gap between producing a demo and delivering a supported product.

A non-engineer’s working flow, algorithm or screen sequence is a useful input to requirements. Runnable behaviour makes acceptance criteria easier to write. Treat the demo as a brief for the engineering work.

What this means for methodology

Before AI accelerated code writing, methodology debates often centred on the time taken by documentation and process. Waterfall, agile, TDD and lighter delivery practices made different trade-offs. Teams rejected processes that added too much work around an already expensive implementation stage.

With demo output now inexpensive, requirements and verification account for more of delivery. Writing requirements, stories and criteria, sequencing work, reviewing changes and running the build cycle turn a prototype into software the team can ship.

This work has continuing benefits. Requirements preserve intent, build sequences guide future work and suites linked to acceptance criteria protect behaviour through later changes.

Teams that treat a demo as complete can produce more code than they understand. That growing gap is AI drift at team scale.

How do you take an AI prototype to production?

Treat the prototype as the brief, not the build. Write the requirements it implies, break them into stories, set acceptance criteria over the cases the demo never exercised, and run the build cycle against those. That work is the last mile from prototype to production, and it’s the part AI didn’t make cheap.

The prototype helps make requirements concrete. Its stakeholder-reviewed flows inform the stories and criteria that guide the build.

What RCF is for, in this context

RCF defines the work needed between a demo and a production feature. The document chain records the artefacts. The build cycle structures implementation and verification. The AC-as-contract rule checks cases the demo omitted. The human signature at the approval gates keeps the chain tied to accountable decisions.

RCF applies engineering checks that were already necessary. Cheaper code generation leaves more of the schedule available for them.