PrototypeMethodRequirementsSMEs
See your software before you pay: what a free prototype is for
8 min read
Buying business software usually means buying a document first. A proposal, a statement of work, a feature list, sometimes a few static mockups. You sign, development starts, and the first thing you see working arrives weeks later. In between, you have paid for someone's interpretation of your needs without any way to check it.
A visual prototype reverses that order. It puts the application in front of you before you commit any budget, so you judge something real instead of a description of it.
What a document cannot prove
A requirements document is text. It describes intentions, and two equally competent readers will build two different products from it. "The user approves the order" can mean a single button, a two-level approval workflow, or an automatic check against available stock. Until someone sees the screen, nobody knows which of the three was priced.
That gap always gets paid for, and it gets paid for late. It shows up during user acceptance testing (UAT), when the software does exactly what was written and not what was expected. At that point, fixing it no longer means editing a sentence: it means reopening work that has already been billed, and often renegotiating the scope.
Design mockups reduce the risk without removing it. They show what a page looks like, rarely how pages connect. You see a screen, not what happens when a piece of data is missing, when two people edit the same record, or when someone needs to undo a step.
| What you buy first | What it shows | What it leaves open |
|---|---|---|
| Proposal or statement of work | The intended scope, in words | How each rule is read and built |
| Static mockups | The look of key screens | Navigation, edge cases, roles |
| Visual prototype | Connected screens with realistic data | Production concerns: security, performance, integrations |
| Delivered application | The working product | Nothing, but it is the most expensive place to learn |
What a prototype actually is
What it contains
A visual prototype shows the real screens of the application, linked together and filled with data that looks like yours. You can follow a use case from start to finish: create a record, move it through its stages, find it again the following week, export it. The labels use your vocabulary, not generic placeholders.
That continuity is where the value lies. It forces decisions on the questions a document left open, and it makes them visible in a few minutes of demonstration rather than across several meetings. Our guide to the differences between a prototype, an MVP and a POC explains what each of these proves, and why they should not be confused.
What it is not
A prototype is not a beta. It has no production database, no fine-grained permissions, no backups and no guaranteed performance. It processes no real data and should never be handed to end users as a working tool.
Confusing the two is the most expensive mistake in this area. You believe you hold an almost finished product, you start using it, and you discover in production that most of the work was still ahead. A prototype is for deciding. It is not for operating.
Why ours is free, and why it is not delivered
At LPR Studio, the prototype is free and presented in a video call within 5 working days. It is not a promotional stunt: it is the fastest way to find out whether a project stands up. A few days of work are worth more than a three-month pre-sales cycle spent agreeing on wording.
In return, the demonstration prototype remains our property. It is presented, not delivered. What we sell afterwards is the finished application, deployed and maintained. This rule rules out a situation nobody wants: a prototype taken elsewhere, handed to a third party, and a project that starts from something designed to convince rather than to last.
If the prototype does not convince you, nothing happens. No invoice, no commitment on either side. It is the one moment in a software project where saying no costs nothing.
What to ask any vendor who offers a free prototype
Free prototypes are not unusual, and they do not all mean the same thing. Before you rely on one, ask:
- Is it a demonstration or a deliverable? Know whether you will receive anything, and in what form.
- Who builds it? A prototype made by the people who will build the product carries more information than one made by a pre-sales team.
- What happens if you say no? The answer should be "nothing". If there is a hidden fee or a minimum commitment, it is a paid discovery phase under another name.
- Will it become the reference for the quote? If not, it was a sales visual, not a scoping tool.
What a prototype changes for the budget
An estimate is reliable when the scope is closed. A scope described in text stays open: every review adds a clarification, and every clarification moves the price. This is what produces cautious quotes, padded with a safety margin that you pay to cover the vendor's uncertainty.
A validated prototype closes the scope because it shows it. It becomes the shared reference: what is on screen is in the fixed price, and anything else needs an explicit decision. That is what makes a firm price possible before the first line of code. Our comparison of fixed price and time and materials explains why this matters for who carries the risk, and our article on the cost of a custom business application covers what drives that price.
It also changes the internal conversation. A leadership team struggles to decide on a thirty-page document; it decides easily in front of a screen that shows what its staff's working day will look like. The prototype is as much an internal decision tool as a scoping tool.
Where the prototype sits in the project
The prototype comes early, after a short scoping conversation and before any contract. In the full sequence, from framing the problem to go-live and maintenance, it is the step that turns a written brief into something people can react to. Our buyer's guide to the custom software development process places it among the other steps.
It does not remove the need to write things down. Data volumes, permissions by role, connections to your ERP or accounting software and regulatory constraints are invisible on screen. They belong in a short written specification, which becomes much easier to write once everyone has seen the prototype. Our guide to the software requirements document covers what it should contain.
How to prepare
Three things are enough to get a useful prototype.
- The problem to solve, phrased in business terms rather than as a solution. "Our schedules live in four spreadsheets and nobody knows which one is right" is more useful than "we need a planning module".
- The people who will use it, and what they actually do during the day. A tool designed for a manager and used by twenty operators fails for that reason alone.
- The tools already in place: ERP, accounting, CRM, shared files. An application that ignores the rest of your systems helps nobody.
You need no specification, no approved budget and no prior sign-off. Those are precisely what the prototype helps you build. If you can, bring one or two of the future users to the video call: their reactions in the first five minutes are often the most useful feedback you will get.
Signs the prototype did its job
A prototype review is useful when it changes something. After the video call, you should be able to say yes to most of these:
- Someone on your side spotted a missing step, status or role.
- The people who will use the tool recognised their own work on screen.
- You can name what belongs in the first release, and what can wait.
- The disagreements that remain are about priorities, not about what the software is supposed to do.
If the review produced only polite approval, it was too abstract or the wrong people were in the room. Better to find that out now than at go-live.
After the prototype
Once the prototype is validated, you choose how to go further, among our three models: a fixed-price build, a subscription where you do not pay for development upfront, or a SaaS we publish. In every case we sell a result, not hours or people. The rest of the path, from prototype to production, is described in our approach.