From Vibe Coding in Design
From Prototype to Product
When is a prototype ready to ship?
Intermediate / 5 min
After this reading, you can list what must be resolved before an AI-made prototype becomes a product, and which of it is design work.
A vibe-coded prototype can look like a finished product. It runs, it responds, it may even be online. That resemblance is the risk. A prototype is built to answer a question—does this flow make sense, do people want this—and it only has to work for the people in the room. A product has to work for everyone it is meant to serve, on the devices and connections it says it supports, on their worst day, with their data at stake.
Martin Fowler, describing vibe coding, notes that it suits disposable software and prototypes, and that its risks grow with how widely the software is used and what depends on it. He names them plainly: leaked data or credentials, errors presented with confidence, changes that break what worked, and code that becomes hard to change.
Decide what the prototype was for
Before asking whether a prototype can become a product, ask what it was meant to prove, and whether it proved it. A prototype that answered its question has done its job, even if none of its code survives. Rebuilding with what you learned is often faster and safer than hardening something that was never meant to last.
The distance between the two
| Area | A prototype can | A product must |
|---|---|---|
| Content | Use sample text and ideal data | Handle real content, including the longest, the missing and the unexpected |
| States | Show the path that works | Design empty, loading, error, offline and success states |
| Accessibility | Skip what its question does not test, but still work for the participants it includes | Meet WCAG 2.2: contrast, keyboard use, labels and screen readers |
| Data and privacy | Use made-up data | Collect only what it needs, store it safely and tell people what happens to it |
| Security | Run on a laptop | Keep secrets out of the code and defend against known attacks |
| Performance | Run on a fast connection | Work on modest phones and slow networks |
| Maintenance | Be understood by no one | Be readable and changeable by the people who will look after it |
| Consistency | Invent each screen afresh | Follow a shared system of components, type and spacing |
Where a designer’s responsibility lies
Most of these are not only engineering problems. Content, states, accessibility and consistency are design decisions, and they are exactly the ones generated work tends to skip. A designer who carries a prototype forward should be able to show every state of every screen, explain the system behind them, and say how each was tested.
Security, data and code quality need people who can read the code. If you cannot, the responsible step is to say so and involve someone who can—not to ship it because it appears to work. The OWASP Top 10, a widely used list of the most common web security risks, is a good starting point for that conversation.
Turn open issues into a release decision
A list of gaps is not yet a decision. Start by writing who the product is for and what it supports. Say the prototype is a booking tool for a college’s shared studio, used by its students and staff on their own phones and the campus network, and review leaves four issues open.
| Open issue | Decision | Why |
|---|---|---|
| Two people can book the same slot at once | Blocks release | The core task fails, and someone loses a slot they believe they hold |
| The Book button cannot be reached by keyboard or announced by a screen reader | Blocks release | The primary action is closed to some of the people the tool is for |
| Every signed-in user can see other students’ phone numbers | Blocks release | Personal data is exposed with no need for it |
| There is no weekly view of the calendar | Can wait | No one is stopped from booking; it gets a named owner and a date to revisit |
An issue that can wait is written down with its scope and an owner; an improvement no one owns is a problem with no date. The decision itself belongs to whoever is accountable for the product, made with the people who built it and the evidence in front of them, not to whoever is most eager to launch.
Hand it over well
Whether the prototype is rebuilt or refined, what carries forward is the knowledge in it. Write down what it was testing, what you learned, which decisions are settled and which are still open. A clear handover turns a fast experiment into a useful start; a polished prototype without one is just something for someone else to reverse-engineer.
- State what the prototype was meant to prove, and what it actually showed.
- List the content, states and edge cases it does not yet handle.
- Check it against WCAG 2.2 with a keyboard and a screen reader, and note what fails.
- Mark every place it stores, sends or shows personal data.
- Ask someone who reads code to review its structure and security before anyone else depends on it.
- Record each open risk, whether it blocks release and who owns it.
- Decide, with them, whether to refine it or rebuild it with what you learned.
AI has made the first version of almost anything cheap. It has not made the last version any cheaper. The distance between them is where design, engineering and care still do their work.
Takeaway