Both are called a prototype in the proposal. Only one of them tells you anything about your implementation.
If you are going to use a prototype as a decision input, you need a way to test it. What follows is the method we give clients, including the parts that make our own work harder to sell.
First, establish what you are looking at
Three things get presented as prototypes, and they carry different weight.
A demo is a prepared path through the software, run by the person selling it. Every record it touches was created to make the path work. A demo tells you the software exists and the presenter knows it. It tells you nothing about your business.
A mockup is a design of screens and flows, usually in Figma or slides. It is useful for agreeing on intent. It cannot be tested, because there is no system underneath it.
A prototype is a running instance you can log into yourself, configured for your operating model, containing data shaped like your data. You can create a record it was not built to handle and see what happens. That last property is the whole point. If you cannot break it, you are looking at a demo.
Ask one question to tell them apart: can I log in without you, with my own credentials, and enter a transaction you did not plan for?
What to agree before it is built
A prototype is only as informative as the scope it was given. Before anyone starts configuring, settle three things in writing.
Which processes are in scope. Two or three end-to-end flows are enough, and they should be the ones that carry your revenue or your risk, not the ones that are easiest to configure. Order to cash and procure to pay are common choices. If your margin lives in production scheduling, that is the flow to build.
Where the data comes from. Realistic data means your product structure, your customer types, your document sequences, your tax treatment. It does not require production exports. A masked or synthetically generated set that preserves the structure is usually enough for evaluation, and it keeps the legal review short.
What decision the prototype is meant to support. Platform choice, partner choice, and scope definition are three different questions. A prototype built to answer one of them will be shaped differently from one built to answer another.
Five tests to run yourself
Once you have access, do not follow the walkthrough. Run these instead, with your own people, in your own time.
Load your master data and look for the fields that are missing. Take fifty real products, ten customers and your actual chart of accounts structure. The interesting result is not that they import. It is which attributes you track today that have nowhere to live in the standard configuration, because each one is either a customisation, a process change, or something you were tracking for no reason.
Run the exception, not the happy path. Every business has a transaction type that causes arguments. A partial delivery with a price correction, a return against an invoice from a previous period, a work order that splits mid-production. Enter that one. How the system handles your exceptions predicts your implementation far better than how it handles your standard order.
Close a period. Post transactions across a month boundary, then run the reconciliation and the reports your finance team actually files. Period close is where configuration debt surfaces, and it surfaces late in real projects, usually after go-live.
Test the integration boundary, at least on paper. If the system has to exchange data with a fiscal device, a bank, a marketplace or a warehouse system, ask to see the interface defined, the field mapping, and what happens when the external system is unavailable. A prototype rarely includes live integrations. It should still show you the boundary and who owns each side of it.
Ask one reporting question you cannot answer today. Most ERP purchases are justified by visibility. Name the question you want answered on the first of the month, then check whether the data model as configured can produce it without a manual step.
Give each test to the person who does that job now, not to the project sponsor. Sponsors evaluate whether software looks capable. Operators find out whether it fits.
What a prototype will not tell you
Anyone presenting a prototype as proof of the whole project is overselling it, so it is worth being explicit about the limits.
It will not tell you how the system behaves at full transaction volume with concurrent users. It will not tell you how clean your historical data is, which only migration testing reveals. It will not predict adoption, because a prototype is used by volunteers and a live system is used by everyone. It will not fix a process you have not decided on, and if two departments disagree about who owns an approval, the prototype will simply show you the disagreement rendered in software.
That last point is worth sitting with. A prototype is a good instrument for surfacing unmade decisions early, when changing them costs a conversation rather than a change request.
Turn the result into contract language
The value of the exercise leaks away if the findings stay in someone's notebook. Before the project moves forward, write down four things: the configuration decisions confirmed during testing, the gaps that require development and their rough size, the process changes the business has agreed to accept, and the items deliberately deferred to a later phase.
That document is the most accurate scope input available to you, because every line in it was produced by touching a working system rather than by discussing one. Used properly, it becomes the acceptance criteria for phase one, and the arguments that normally appear in month four happen before the contract is signed instead.
That is the whole argument for building the prototype first. Not that it removes risk, but that it moves the expensive decisions to the point where they are still cheap to change.
Contact Us
We'd love to hear from you! Whether you have questions, feedback, or need support, our team is here to help. Simply fill out the form below, and we aim to respond to all inquiries within 24 hours. Thank you for getting in touch!
Frequently asked questions
For two or three end-to-end flows with structured sample data, weeks rather than months. If the estimate approaches the length of a normal discovery phase, you are being sold a discovery phase.
No. A masked or synthetically generated set that preserves your data structure is sufficient for evaluation and avoids a lengthy data protection review. Production extracts belong to the migration phase, under a signed agreement.
Three things. The two or three processes you want to see working, a description of how your products, customers and documents are structured, and the decision the prototype is meant to support. Platform choice, partner choice and scope definition are different questions and produce differently shaped prototypes.
You should ask any vendor this. Configuration decisions and the gap list are portable regardless of who runs the implementation. A vendor unwilling to let the findings travel is protecting their pipeline rather than your project.
No. A pilot runs real operations in a limited part of the business and carries real operational risk. A prototype is an evaluation instrument used before commitment, with no live transactions depending on it.
You receive a written record of the configuration decisions confirmed during testing, the gaps that require development, the process changes the business has agreed to accept, and the items deferred to a later phase. That document becomes the scope and the acceptance criteria for phase one.