Prototype vs production build: which to commission next

On-Off Group

September 2026

Commission another prototype while you are still unsure who uses the thing or whether it helps. Commission a production build once real users have tried a rough version, the behaviour you wanted showed up, and you have a before number to compare against.

Your rough version worked, and now someone is asking what it costs to make it real. Another prototype or a production build? The prices are nowhere near each other.

It comes up most when the rough version already works and the budget question is next.

We build software with client teams as well as run workshops, so we get asked this a lot. This is how we answer it.

What you are paying for in each case

A prototype is built to answer a question. It can fake the data, skip the login, and only work on one path. It exists so someone can try it and you can watch what they do.

A production build is built to survive. It has to handle the customer who types the wrong thing, the branch staff member on an old laptop, security review, and the person who inherits the code next year.

Almost all the extra cost sits in that second list. People get caught out because the prototype looked finished. Logo on it, buttons working. So everyone assumes production is a tidy-up.

Then the estimate lands at several times the prototype, and the argument turns into whether the engineers padded it. Usually they did not. The prototype never had to handle a customer who abandons the form halfway and comes back on their phone.

Build another rough version if you cannot say what people did with the last one

Get five people who are not on the project to use it while you watch. Then write down what happened in plain sentences.

If you can write down what people actually did, and the thing you hoped for showed up, you have your answer. If the team is still arguing about who the feature is for, or the answer is that people liked it, you have not.

Another round of rough building costs a fraction of a production build. Paying for a production build of something nobody has watched anyone use is an expensive way to find out the idea was wrong.

If the open question is about customers, put five of them on video using the thing before you spend anything on code. We run that as a two week check with five real users on video. Details at onoffgroup.com.

Do not commission a production build without a before number

A pilot runs, the team says it went well, and a few months later the boss asks whether it worked. Nobody can answer, because nobody wrote down what the old process did first.

Pick one number and take it now, before anything ships. Turnaround time on the onboarding flow. Completion rate on the application. The share of cases that come back for rework. One number, measured the same way twice.

We ran a series of five-day design sprints with a large insurer. Customer journeys that had taken six months or more were designed and tested with customers in two weeks and live in four. Completion rates on the new journeys rose 80 per cent and the old drop-off points went away. The client measured all of it, and they could only report it because they had the old numbers written down.

Know what carries over and what gets thrown away

When the production build starts, the flow, the screens, the copy and the prompts usually survive. That is where the thinking went. The code underneath normally gets thrown out, and nobody should be protecting it.

The trouble starts when someone has told a committee the prototype is eighty per cent done. Now the team is stuck defending code that was written to be binned, and the honest estimate looks like bad news.

So say it when you show the prototype. The screens and the flow are tested. What runs behind them is temporary and will be rebuilt. People take that fine early on, less well once the budget is signed.

This gap is wider on an AI feature. A prompt that works on the cases you tried is not a prompt you can trust on real customer data, and the checking work is a big part of the production cost.

Make the decision with everyone in the room

Nobody argues about this decision, and that is the problem. The product lead thinks the prototype settled it. The risk team thinks nothing has started yet. The engineers have read the code and say nothing in the meeting.

Get everyone in a room with the prototype open and walk a real customer case through it, step by step, including the awkward ones. That is where the work nobody costed shows up.

We run sessions like that too.

What to do this week

Write down the one question the prototype was meant to answer, and whether it did.
Pull one before number from the current process and note the date and how you got it.
Watch five people who are not on the project use the prototype, and write down what they did.
Ask your engineers which parts of the prototype they would keep and which they would bin.
If you still cannot say what customers did with the prototype, do another round of rough building before you ask for a production budget.

Questions people ask

How do we know the prototype has told us enough?
If people outside the project team have used it and you can describe what they did without arguing about it, the prototype has done its work. If the team is still debating what the feature is for, build another rough version instead.

Can a prototype become the production build?
Parts of it can, mostly the screens, the flow and the prompts. The rough version behind it is usually thrown away, and that is fine as long as nobody promised the board it was nearly finished.

What number should we have before commissioning a production build?
One number from the current process, taken before anything changes. Turnaround time, completion rate or the share of applications that need rework are all fine, as long as someone can pull it again in three months the same way.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with building software.