Prototype Hardening Checklist
A checklist for seeing which product decisions your prototype has quietly left for someone else to make.
Before you start
Your prototype was built along the path you described, and that path tends to work well, which is why it demos convincingly. Products spend a good deal of their working life away from it.
Wherever you did not specify something, the tool supplied a default without telling you. This checklist finds them.
Anything you cannot answer is not a fault. It is a decision that has not been made yet, and making it now is much cheaper than making it during a build.
The paths you never demonstrated
- What does each screen show when there is nothing there yet? A new customer sees your product empty. Has anyone designed that?
- What happens with far more data than the demo has? Fifty rows, five thousand.
- What happens when something fails? The payment declines, the upload times out, the connection drops mid-action.
- What happens when someone leaves halfway through? Close the tab in the middle of a form, come back, and see what survives.
- What happens when two people do the same thing at once?
- Can anything be undone? Should it be?
Who is allowed to do what
- List every type of person who will use this. Now check: is the difference between them a real rule, or just a hidden menu item?
- If someone typed the admin URL directly, what stops them? "They would not think to" is not an answer.
- Who can see other people's data? Check by logging in as someone else, not by reading the code.
- Who can delete things, and what happens to everything attached?
What things actually are
- Pick your central object: customer, order, project, patient, booking. Do all the screens agree about what it is?
- What is required for one to exist, and what is optional?
- What states can it be in, and which changes are allowed between them?
- What happens to it when someone leaves the company, cancels, or asks to be deleted?
What the tool decided for you
AI builders supply defaults wherever you did not specify something. Those defaults tend to persist unless someone names them.
- Look at any list. Why is it sorted that way? Did you choose that?
- Look at any form. Why those fields, in that order?
- Look at any wording that appears on screen. Did you write it, or did the model?
- What did it name things? Do your users use those words?
What has actually been validated
- Which parts has a real potential customer used, rather than watched?
- Which parts are you confident about because you have seen them work, and which because they look finished?
- What did you learn that changed the product, as opposed to confirming it?
Real content, real devices
- Replace the sample content with the ugliest realistic example you can find. Long names, missing fields, unusual characters. What breaks?
- Open it on your phone. Is the workflow still possible, or just visible?
- Try it with only a keyboard.
What a developer would have to guess
- If you handed this over tomorrow with no conversation, write down the first five questions they would ask.
- Those questions are your specification gap. They are also what a fixed-price quote will either exclude or pad for.
Reading your results
| What you noticed | What it means | What to do |
|---|---|---|
Mostly sections 1 and 6 | Normal. The prototype proved the idea and skipped the edges | Specify the missing states before building. Keep the prototype |
Section 2 has real gaps | Treat as urgent if any real data is involved | Decide the access rules before anyone signs up |
Section 3 is unclear | Expensive to leave open, because later work builds on it | Settle what your core objects are before implementation |
Section 4 surprised you | Very common, and worth knowing | Decide which defaults you actually want to keep |
Section 5 is thin | You have a convincing demo, not validated evidence | Test the risky assumption before scaling the build |
Section 7 is long | You are not ready to brief a developer | Close the questions first. It costs less now |
A prototype failing most of this is not a bad prototype. It is a prototype doing its job. The mistake is treating it as a specification.
What this does not tell you
What to do next
The prototype hardening definition explains the distinction between demonstration evidence and production work. If the questions in section 5 are the live ones, Prototyping and Usability Testing addresses them directly.
To have a practitioner work through one workflow with you, the Prototype Hardening Review starts with a free audit. Send a link and one workflow.
Prototype Hardening Review
Have a practitioner work through one workflow with you.