Prototype Hardening Review
A review that separates demonstrated product value from shortcuts in data, identity, security, state, accessibility, performance and operations.
- Prototype review
- Production readiness
- Risk assessment
Decide whether to retire, harden or rebuild the prototype
A prototype may create valuable evidence while hiding production risk. A convincing demonstration can be the right artefact for an investment or product decision, but its persuasiveness does not prove that the underlying software can safely carry real users, records and obligations.
Tcules reviews both what should survive and what must change, so useful learning is preserved without turning untested shortcuts into production assumptions.
First identify what the prototype proved
The review records the decision the prototype was built to inform, the audience that used it, the scenarios demonstrated and the evidence produced.
A prototype that proved interaction value may not have tested architecture. A coded technical spike may not establish usability. A synthetic dataset may conceal data quality and access conditions.
Hardening checklist
Each surface is reviewed to separate evidence the prototype actually produced from assumptions that need more work before production use.
| Surface | Questions |
|---|---|
Product state | Are edge, partial and recovery states real? |
Data and identity | Are representative data and access boundaries safe and durable? |
Architecture | Can the implementation support the agreed scope? |
Quality | Are tests, accessibility and browser or device behaviour sufficient? |
Operations | Can the team deploy, observe, support and recover it? |
Evidence | Which assumptions did the prototype actually test? |
The output is a disposition, not a defect dump
- 01
Preserve
Preserve the behaviour or artefact when it represents useful evidence that should survive the next stage.
- 02
Harden
Harden a bounded implementation slice when the product value is worth carrying forward but the implementation needs production work.
- 03
Replace
Replace the underlying approach while retaining the product evidence where the prototype proved direction but not the implementation path.
- 04
Retire
Retire the prototype after its decision job is complete.
The review also identifies dependencies, acceptance evidence and a sequence. Security, performance or specialist testing that falls outside Tcules' normal scope is named explicitly rather than implied.
Evidence from recent work
The ConnectX case records a coded demonstration built to make an AI-native product architecture and scenario flow inspectable. The Benchmark Gensuite case records coded prototypes used to test feasibility during modernisation.
These cases support the distinction between prototype evidence and production proof; neither case claims that the reviewed artefact was deployed as a production system.
The Auxentios case supports making a 0-to-1 product and its component language concrete. It does not establish prototype hardening or engineering delivery.
AI-generated prototypes make this boundary more urgent
Agents can produce persuasive working software before product rules, data controls, accessibility and operations are settled.
Tcules can inspect generated code, dependency choices, state handling and tests, but review depth depends on access and intended consequence.
Bring the real artefact and intended consequence
Provide the running prototype, source and dependencies where available, representative data, known shortcuts, intended users and the release or funding decision it must support.
Tcules will state what the review can and cannot conclude before work begins.
Clarify the prototype boundary
Bring the artefact, context and intended consequence so the review can separate useful evidence from production risk.