A prototype is a small working version of the software, built first, so you can use it before anybody commits to the whole thing.
Not a drawing and not a slide deck. Something you open and click, doing a real job with real information.
What it settles
Five questions, and they're the ones that cost the most to get wrong.
- Whether the idea works at all. Some good ideas turn out to be awkward the moment they're on a screen, and no amount of discussion reveals that.
- What the screens need to show. Everybody pictures something different until there's a screen to point at.
- Which steps you missed. There's always at least one, and it's always obvious the moment somebody tries to do the job.
- Whether your team would use it. The hardest of the five and the one nobody can answer in advance.
- What the real build has to cover. By the end you have a specification written from use instead of from imagination.
That last one is why it goes first. The most expensive mistake in any software project is building the wrong thing well.
What it deliberately leaves out
Leaving these out is what makes a prototype quick, and it's also why it isn't the finished software.
- Accounts and permissions. Everyone sees everything in a prototype. Fine for five people trying it, wrong for a business.
- Your old records. It starts empty or with a sample. Bringing across fifteen years of history is its own project.
- What happens when a step fails. A prototype assumes every step succeeds. Real software assumes one won't.
- Running at full volume. Ten records behave differently from a hundred thousand.
- Backups and undo. No safety net, which is exactly why you shouldn't run the business on it.
Anybody offering a prototype that includes all of that is offering you the build and calling it something else.
How to judge one
Use it on a real job. Not a demo where somebody drives, and not a walkthrough.
Take something that actually happened last week and put it through. That's when the missing step appears, and finding it here costs a conversation instead of a change order.
Then give it to whoever would use it every day and watch without helping. Where they hesitate is where the design is wrong, and they'll usually apologize for it, which is the tell that it's the software's fault.
Three questions afterwards: what took longer than it should, what did you expect to be here, and what would stop you using this daily.
Why it's free here
Because it's the only honest way to sell something that doesn't exist yet.
You can't judge a quote for custom software from a description. Everybody's idea of what was agreed is slightly different, and the differences don't surface until something is built. A prototype makes them surface first, while changing your mind is still cheap.
It also protects you. If you use it and it's wrong, you've lost nothing and you've learned something worth knowing. That's a better outcome than a build nobody wanted, for both of us.
It's usually ready within a week. The full build is scoped after it, with a fixed price agreed before that starts, and builds begin at $5,000.
What happens after
Three outcomes and all of them are useful.
It's right and you want it built. The prototype becomes the specification and the build is scoped against something everybody has actually used.
It's nearly right. Commonest by a distance. A few details move, and the build is scoped against the corrected version.
It's wrong. Sometimes the honest conclusion is that this isn't a software problem, or that a product on the market already does it. That's a good week's work and it saved you a build.