Implementation worksheet · 6 min read
How to Document the Limits of a Generated Prototype
Write a limits register before the prototype reaches anyone who might treat it as a product. Each entry names an area, the prototype's actual behaviour there, its status (missing, stubbed, built but unverified, or verified on a named build), the risk if someone assumes more, and what would lift the limit. Cover the areas people over-assume: data and backups, users and permissions, integrations, payments, scale, offline use, security, accessibility, devices, and who can change it. Put the three limits that matter most on the prototype's first screen, keep the full register next to its link, and update it with every build you share.
Scope: the actor is whoever built a prototype with an AI builder and is about to share it with a stakeholder, a customer, an investor or a developer who may take it further. The starting state is a working prototype and no documentation. The boundary is the prototype's current behaviour and its gaps; whether to build the real thing is a separate decision. The outcome is a register with evidence behind each entry, and a short note the audience sees first.
Put it into practice
1. Write limits as behaviour, not disclaimers
'Not production-ready' tells a reader nothing. 'Payments run in test mode; no real card can be charged' tells them what they can and can't do. Every entry should describe something a reader could check.
2. Go area by area
Data, backups, users and permissions, integrations, payments, scale, offline use, security, accessibility, devices, and who can change the app. For each, write what was built and tested, and what was stubbed, skipped or never tried. An area you didn't test is still a limit: 'Accessibility: not tested' is an honest entry.
3. Give every entry a status
Missing, stubbed, built but unverified, or verified on a named build. A stubbed email integration and a real one that was tested once are different limits, and the status column is what tells them apart.
4. Say what goes wrong if someone assumes more
The risk column is what makes the register useful. 'Data isn't backed up' matters little in a demo and a great deal if a customer starts entering real records, which can happen as soon as a link is forwarded.
5. Say what would lift each limit
Not in days, but in what's needed: 'a tenant key and a two-account test', 'a real payment account and webhook handling', 'a keyboard and screen reader pass'. This turns the register into the scope of the next phase.
6. Put the top three where the audience will see them
A banner or first-screen note in the prototype, with the full register linked beside it. A register filed in a separate folder isn't read by the person who opens the link.
7. Update it with every build you share
Stamp the register with the build it describes. When a limit is lifted, move it to a lifted section with its evidence instead of deleting it, so the history of what changed stays visible.
8. Worked example (illustrative, synthetic data)
A fictional field-inspection prototype built for a pitch to a facilities company. The top three, shown on the sign-in screen: 'Sample data only; anything you enter may be wiped', 'Photos are stored but not backed up', 'One inspector and one manager account; no permission rules beyond that'. The full register has eleven entries, including 'Offline use: missing; the app needs a connection', 'Accessibility: not tested' and 'Report PDF: verified on build 6 with 20 inspection items; untested beyond that'. The facilities company's IT lead read the register before the meeting and asked two questions, both already answered in it.
Prototype limits register
Copy this structure into your review document and record your observed result for each row.
| Area | Current behaviour | Status | Risk if someone assumes more | What would lift it |
|---|---|---|---|---|
| Data | Sample records; anything entered may be wiped | Built, not for real data | A customer enters real records | Backups, retention rules, an import path |
| Backups | None for photos; database backup never restored | Missing | Anything entered can be lost | Automated backups and a restore rehearsal |
| Users and permissions | One inspector and one manager account | Built but unverified | Inspectors see each other's reports | A role model and a two-account test |
| Integrations | Email notifications written to a log, not sent | Stubbed | People expect real emails | A real sending domain and failure handling |
| Payments | None | Missing | Treating it as ready to sell | Payment provider, webhooks, entitlements |
| Scale | Reports tested with 20 inspection items | Verified on build 6 at that size | Large sites produce broken reports | A test at the largest real site's size |
| Offline use | Needs a connection | Missing | Inspectors lose work where there's no signal | Offline storage and a sync design |
| Security | No review done | Unverified | Real users exposed to unreviewed code | A security review before real data |
| Accessibility | Not tested | Unverified | Users of assistive technology are shut out | Keyboard and screen reader passes |
| Devices | One laptop browser and one phone | Verified on build 6 for those two | Other devices misbehave in a pilot | Test the pilot's actual devices |
| Who can change it | Only the builder account's owner | Built | A stakeholder assumes their team can edit it | An access plan and a code export test |
A failure worth checking
The prototype that became production by being forwarded. A stakeholder likes the demo and forwards the link to a customer, who starts entering real inspections. There are no backups and one shared manager account, and nothing in the app says so, because the limits lived in the builder's head. Two weeks later the question isn't whether to build the product, it's how to rescue the customer's data. A first-screen note would have stopped it. The counterexample: a register so long and hedged that nobody reads it. A dozen plain entries beat forty qualified ones; if everything is listed as a limit, readers stop telling apart the ones that matter.
Common questions
Won't listing the limits make the prototype look weak?
It makes everything said about it credible. A prototype is supposed to have limits, and a stakeholder who later finds one that wasn't disclosed trusts every other statement less. A stated limit with what would lift it reads as a plan.
How is this different from a bug list?
A bug is behaviour that differs from what was intended. A limit is a known boundary: something not built, stubbed or not yet verified. Both matter, and they answer different questions.
Who should read the register?
Anyone the link reaches, and especially whoever decides whether to build the real thing. A developer asked to take the prototype further should get it first, because it is the quickest way to see what's missing.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.