From prototype to production application

A draft that convinces in a conversation is a good start, but not yet an application a business can use. This article names what lies in between — so that your schedule does not hinge on the demo.

Who it is forClients, project managers
LevelProject planning
Reading timeabout 6 minutes
Last updated16 October 2026

What you will learn

What a prototype is for — and what it is not for
The six areas that lie between draft and deployment
Why the road from “it runs” to “it is usable” is underestimated
When it is right to throw a prototype away

What a prototype is good for

A prototype answers one question: does this work the way we imagine it? It shows a process, makes an idea visible and uncovers misunderstandings that no description would reveal. For that, it may be incomplete.

What it does not answer: what happens with ten thousand records? What if two people work at the same time? What about an input error? Who may see what? These questions were not forgotten — they were not the purpose.

Six areas between draft and deployment

Rights and roles: In the prototype everyone is an administrator. In the application each role sees something different — and that has to hold at every point, not just in the menu.
Error cases: What happens with missing, contradictory or duplicate data is work in its own right and often more than the normal case.
Data volumes: A list with twenty rows and one with twenty thousand are different tasks — search, sorting and paging included.
Concurrency: Two people edit the same record. Who wins, and does the other find out?
Operation: Backups, monitoring, updates, a rehearsed recovery.
Handover: User guidance, training and the question of who will maintain the application in future.

None of these areas is an extra. Together they are often larger than the part the demo showed — and that is why a convincing prototype leads to over-optimistic expectations.

A real-world example

The list that grew with the data

An overview showed all records on one page in the draft — pleasantly fast with 40 test records. In production there were 18,000 after four months. The page took ten seconds to load, the export aborted, and the search found nothing because it ran across all fields.

The work afterwards was bigger than the list itself: paging, targeted search across the right fields, an export in parts. With the question “how many records do we expect in two years?” before building, it would have been a third of that.

When a prototype should be thrown away

When it was built to answer a question quickly, and its structure shows that. A draft without separation of data, logic and presentation cannot be extended without every change having to be made in three places.

That sounds wasteful and is the opposite: the prototype fulfilled its purpose when it answered the question. Making it the foundation because “it already runs” is the more expensive route — and the one that later demands a rebuild.

The counter-check is simple: if the draft was built with a sound structure from the start, it can be the foundation. Then it was not a prototype but a first stage of development — and that is a deliberate decision made beforehand.

Common misconceptions

“Runs” means: the intended path works once. Usable means: it works for all roles, at all data volumes and also when something goes wrong.

Possible, but risky: a prototype uncovers misunderstandings for a fraction of the effort. The question is not whether, but how much of it will be reused later.

Backups, monitoring and updates have to be set up and someone has to be responsible for them. Whoever does not settle that in the project settles it at the first outage.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that come up in real projects.

Questions about this article? Write to us