How to turn a business-built AI prototype into production software

Business teams increasingly arrive with more than requirements. After a workshop they use AI-assisted tools to build their own prototype, test ideas between sessions, and come back with a version that expresses what they mean far more clearly than a slide deck could.

The old reaction would be to treat that prototype as informal, incomplete or technically naive. That misses what it is. A business-built prototype is an executable expression of domain knowledge: workflow, language, priority and user expectation, in a form everyone can inspect. The question is no longer whether the prototype is any good. It is what an engineering team should do with it.

What the evidence says about AI-assisted delivery

AI-assisted development is no longer experimental. DORA's 2025 report puts daily AI use at around 90% of developers. Adoption has not brought trust with it: in Stack Overflow's 2025 survey, 46% of developers actively distrusted the accuracy of AI tools against 33% who trusted them.

Security shows the same split between working and safe. Veracode's 2026 testing across more than a hundred models found syntax correctness effectively solved while the security pass rate stalled at 56%. Code can compile, run and demo convincingly and still carry a known vulnerability class.

Gartner has reported that on average only 41% of generative-AI prototypes reach production. That figure covers a broader category than vibe-coded business applications, so it is not a benchmark for any single project. It does describe the same organisational problem from the other end: producing a prototype is getting cheap, and owning software is not. The gap it measures is the one we describe in operational AI versus AI pilots.

Vibe-coded describes how software was made, not how mature it is

Most of the confusion in this discussion comes from treating "vibe-coded" as a quality grade. It is an origin story. Maturity is a separate axis, and it is the one that decides what has to happen next.

The translation method, in six steps

The productive approach starts by listening to what the business has made and why, then converting it into something an engineering team can build against. Each step below has an output, and the fourth is where the actual decision gets made.

1. Capture the intent

Work out what the prototype is trying to communicate, with its authors in the room. The output is an intent map, not a technical assessment.

• Target user and the job being done
• Business outcome the screens are aiming at
• Workflow, in the order the work actually happens
• Terminology, exactly as the business uses it
• Priorities: what is on the first screen and what was left out
• Exceptions the authors already know about
• Questions the prototype does not answer

2. Extract the specification

Translate screens and interactions into explicit behaviour: roles, permissions, business rules, state transitions, data ownership, validation, edge cases and acceptance criteria. This is the same move that spec-driven tooling such as GitHub's Spec Kit formalises, and it works on a prototype because a prototype is already a specification written in the wrong language.

A button labelled "Create tenancy" is an interface element. The specification has to say who may press it, which spot states allow it, what happens to the waiting list, how a key is assigned, and what gets recorded.

3. Challenge the prototype

A visible prototype anchors everyone who sees it, including the engineers. Screens get preserved because they exist, and a polished happy path gets mistaken for a complete operating model.

• Which assumptions have never been tested against a real case?
• Which users or roles are missing entirely?
• What happens when an operation fails halfway through?
• What does the prototype make look simpler than it is?
• Are participants agreeing with the workflow, or reacting to the presentation?

4. Classify every significant element

This is a component-level decision, not a verdict on the prototype as a whole. Each significant element gets one of three outcomes.

• Preserve as intent: the business rule or workflow is the valuable part, whatever the code around it looks like
• Reuse after verification: the implementation survives review, testing and a security pass, so it goes forward
• Rebuild: the shortcut conflicts with the target architecture, the security model or the operating requirements

Recording the reason alongside each decision matters as much as the decision. It is what lets you answer, six months later, why a screen the business built no longer looks the way they built it.

5. Engineer the production foundation

Then resolve what a prototype structurally cannot address. Most of this is systems architecture work that no amount of prompting produces as a by-product.

• Architecture and service boundaries
• Durable data model and migrations
• Identity, permissions and tenancy isolation
• Integrations with the systems the work actually flows through
• Accessibility
• Security posture and dependency management
• Observability
• Deployment, rollback, backup and recovery
• A named operational owner

6. Prove readiness

Readiness is evidence, not confidence. The list is short, and every item produces an artefact somebody can look at: acceptance tests for the critical workflows, security and dependency scanning, accessibility validation, load testing where volume is real, a restore actually performed from a backup, monitoring and alerting that someone receives, a rehearsed rollback, a named service owner, and a validation pass with the people who built the prototype in the first place.

What a prototype encodes, and what it leaves out

Reading a prototype well means knowing which parts of it carry information. A business-built prototype is dense in the areas its authors work in every day, and close to silent on the areas they never see.

• Usually reliable: naming, sequence, and which fields belong together on the screen where a decision is made
• Not expressible in a prototype: behaviour under concurrent use, at real data volumes, or when an upstream source is unavailable
• Silently assumed: one role with full access, because the person building it had no reason to model anyone else's permissions
• Incidental: structures that reflect what the tool made easy rather than what the domain requires

The last category causes the trouble, because a prototype cannot say which of its decisions were deliberate. Only its authors can, and their recollection of why a field sits where it does fades quickly. The read-through belongs early, with those authors present, and should mark each significant choice as domain requirement, convenience, or open question.

The production-readiness matrix

Garage admin: what the prototype actually said

The garage administration prototype was valuable because it exposed an operating model, not because it produced usable code. It showed that a location holds different kinds of spot; that a client can move from contact to lead and then either onto a waiting list or straight into a tenancy; that a key needs a custody state of its own rather than a field on a client record; and that tasks and observations belong to exception handling rather than to a generic to-do list bolted on the side.

Those were domain decisions worth preserving. Making them production software meant turning them into explicit entities, permissions, state transitions, validation rules and history. Eight domain entities, three roles (admin, manager and clerk) and five spot states came out of the read-through as things the business had already decided and could defend.

A prototype can colour a spot as occupied. Production software has to define which actions produce that state, whether two tenancies may overlap on one spot, who can override it, what happens to the spot when a tenancy ends, how the change is audited, and what the system does when two clerks act on it at the same second.

When a business-built prototype slows delivery down

This approach is not free, and it does not always pay. A prototype hurts more than it helps when any of the following are true.

• Stakeholders have anchored on an early interface and now defend it as a requirement
• Polished screens are covering an incomplete business process nobody has finished thinking through
• The generated code carries architecture or dependencies that cannot go anywhere near the target platform
• No accountable product owner exists, so classification decisions have nobody to make them
• Sensitive data has already gone into an uncontrolled tool, and the first task is containment
• Salvaging the code is costing more than rebuilding it coherently would
• Users are validating visual familiarity rather than whether they can complete the task

Two failure modes account for most of it. The first is over-fidelity: a prototype that looks finished invites a team to inherit its data model along with its insight, and a structure adopted by default is expensive to change once the rest of the system rests on it. Screens can be redrawn late. The shape of the data cannot.

The second is discarding it quietly. If the delivered system bears no visible relation to what participants handed over, with no account of what was kept and why, they conclude the exercise was decorative and the next round produces less. Where a domain choice was overruled, saying so keeps the input channel open.

Respecting the prototype does not mean accepting its decisions. Preserve the domain insight, challenge the assumptions, and discard the implementation when understanding and repairing it costs more than rebuilding it coherently.

A better role for prototype tools

AI-assisted prototype tools create real value when they help non-engineers express intent precisely. They shorten the distance from first thought to production direction, and they leave implementation discipline exactly where it was. That is also the honest framing to give a business team: their prototype is the input the specification is written from, and the specification is what gets built. The same division of labour applies inside the engineering team, where frontier models change how implementation work is done without changing who is accountable for the result.

Handled this way the exercise pays for everyone: the business sees its thinking carried forward, engineers get a far richer input than a requirements document, and the organisation ends up with software it can actually operate.

Classifying a prototype's components as preserve, reuse-after-verification, or rebuild is an architecture decision made under time pressure, and it is easy to get generous with the middle category. That classification is the first working session in any systems architecture engagement we run against a business-built prototype, and it is worth doing with someone who was not in the room when the prototype was built.

Can a vibe-coded prototype be used in production?

Not as it stands, and not because of how it was written. A prototype has not answered the questions production asks: access control, tenancy isolation, data integrity, failure behaviour, observability, recovery and ownership. Individual parts of it can go to production once they have been reviewed, tested and security-scanned like any other code.

Should AI-generated prototype code be rewritten?

Decide per component, not per prototype. Preserve the business rules and workflow as intent. Reuse the implementation where it survives review, testing and a security pass. Rebuild where the shortcut conflicts with the target architecture or security model. Veracode's 2026 testing found AI-generated code secure in about 56% of cases without security-specific prompting, which is the reason review is a gate rather than a formality.

What parts of a business prototype should developers preserve?

The parts only the business could have produced: terminology, the order work actually happens in, which fields belong together at the point a decision is made, the exceptions they already know about, and what they chose to leave off the first screen. Those are domain decisions. Layout, data structures and library choices are usually artefacts of the tool.

What is the difference between a prototype and an MVP?

A prototype proves that an idea can be made visible and tested. An MVP proves that the smallest viable product can serve real users and produce learning, which means it has to be operable, supportable and safe for those users. A prototype has no such obligation, which is exactly what makes it fast.

What does a production-readiness review include?

Evidence rather than opinion: acceptance tests for critical workflows, security and dependency scanning, accessibility validation, load testing where volume is real, a restore performed from a backup, monitoring and alerting that reaches a person, a rehearsed rollback, a named service owner, and validation against the intent the prototype expressed.

Who owns software that a business team originally created?

Ownership has to move explicitly at the point it becomes a production system. A named service owner is accountable for it, an engineering team can read, review and change it, and the original authors stay involved as domain owners. Leaving ownership with whoever can prompt the tool is how a prototype becomes an unsupported dependency.

How do you stop business-led prototypes from becoming shadow IT?

Give prototyping a sanctioned path rather than banning it: approved tools, clear rules about what data may go into them, and a standing route into the translation method described here. The risk is not that business teams build things. It is that nobody finds out until the thing is load-bearing.

Research referenced

1. State of AI-assisted Software Development 2025 — DORA, Google Cloud
2. 2025 Developer Survey: AI — Stack Overflow
3. 2026 GenAI Code Security Report — Veracode
4. AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production — Gartner
5. Spec Kit: spec-driven development — GitHub