When should we build a prototype before committing to custom software?

Build a prototype when the problem is clearly worth solving but the right solution is not. A good prototype answers one specific business question, such as whether your rules can be written down or whether your team will trust the result, before you pay for the full system. Build enough to validate the decision, then decide.

If you already know exactly what to build, skip the prototype and build it. If you are not yet sure the problem is worth solving, a prototype is the wrong tool as well. Start by putting a number on what the problem costs.

When does a prototype make sense?

When three things are true at once.

The problem matters. It costs real money, time, or risk, and you would build something if you knew what.

The solution is uncertain. You are not sure what the software should do, how the rules work at the edges, or whether the people involved agree on how the process runs today.

Being wrong is expensive. A full build that misses the real workflow costs months, and replacing it costs more.

That combination is common in operations software. The process works today because experienced people carry its rules in their heads. Nobody has had to write those rules down, and the first attempt usually shows that two people apply them differently.

What should a prototype prove?

One business question, agreed before the work starts. Not "let's see what we can build." Something closer to: can our purchasing rules be applied consistently by software? Will the team trust the system's recommendation enough to act on it? Does connecting these three sources of data show us something we cannot see today?

I built a prototype for a commercial distributor that has to decide when inventory purchases can wait and when stock can move between projects. Those calls were being made in spreadsheets, one order at a time. The question was whether the rules behind them could be captured and applied across every project at once, so a delay in one project showed its effect on all the others.

The prototype models projects, purchase orders, warehouses, and delivery schedules together. When a schedule changes, it recalculates demand and flags early arrivals, orders that can safely be held, and shortages before they happen. Just as useful, it exposed rules nobody had stated. Those gaps are cheap to find in a prototype and expensive to find after launch.

Why test it with the real people and the real rules?

Because the people who do the work know where the edges are. A prototype in front of a purchasing lead gets reactions a requirements document never will: "that's not how we'd handle a partial shipment," or "we'd never pull stock from that warehouse." Each of those is a rule that would otherwise have shown up later as a production bug.

Use real data where you can, or realistic data shaped like it. Rules that hold up on tidy sample data often break on real records.

How is a prototype different from production software?

A prototype is built to answer a question. Production software is built to run part of your business every day.

Production needs things a prototype can skip: security and access control, integration with your live systems, handling for every kind of bad input, backups, monitoring, support, and documentation. That is most of the cost of real software, and it is why a prototype can be built so much faster.

The risk is treating one like the other. A prototype that works in a demo is not ready for your team to depend on, and a vendor who blurs that line is setting you up for a hard year. I label my prototypes as prototypes, including on this site. The distributor prototype has not been run in production, and nobody has measured savings from it yet.

When do you stop, revise, or proceed?

Agree on the criteria before you build, then judge what the prototype showed against them.

Stop if the rules turn out to be too inconsistent to automate, or the value is smaller than it looked. A prototype that saves you from a full build has paid for itself.

Revise if the core idea holds but the workflow is wrong. That is the most common outcome, and it is the cheapest point to change direction.

Proceed if the prototype answered the question, the people who will use it want it, and the value still justifies the full cost. Then scope the production system from what the prototype taught you, not from the original guess.

What does a prototype cost compared with the full system?

Much less, which is the point. A focused prototype is often a few weeks of work. It also tends to make the eventual build cheaper, because the hard decisions get made before the expensive work starts.

AI-assisted development has shortened that further. A working model of a decision process used to take long enough that companies skipped straight to the full build. Now testing the idea first is usually the cheaper path, and it gives leadership something concrete to approve or reject instead of a proposal.

If you have a process that clearly needs better software and you are not sure yet what that software should do, that is exactly where a short, focused engagement starts.