kemiljk Prototype to Production
Prototypes prove possibility. Production earns trust. Do not confuse a working happy path with a shippable system.
Defaults
- Keep the prototype's learning; replace its shortcuts.
- Enumerate edge cases before polishing visuals.
- Accessibility, auth, empty states, and failure paths are release requirements.
- Prefer boring, clear state models over clever demos.
- Measure what breaks under slow networks, large data, and repeat use.
Hardening map
| Prototype shortcut | Production replacement |
|---|---|
| Mock data only | Real loading/error/empty states |
| Client-only auth theatre | Real session/permission checks |
| Happy-path forms | Validation, constraints, recoverable errors |
| Index keys / remounting tricks | Stable identities |
| Hardcoded values | Tokens and configuration |
| Desktop-only interaction | Keyboard, touch, reduced-motion paths |
Prefer / Reject
| Prefer | Reject |
|---|---|
| Explicit state machines or clear state transitions | Hidden flags that only work in the demo script |
| Progressive enhancement | Single-path demos with no fallback |
| Observability and basic tests around critical flows | "We'll notice if it breaks" |
| Deleting demo-only code | Shipping scaffolding because it already exists |
Review checklist
- What happens with zero items, huge lists, and partial failure?
- Are permissions enforced on the server, not only hidden in the UI?
- Do forms recover from invalid input and network failure?
- Is focus management correct for dialogs/menus?
- Does reduced motion still complete the task?
- Are secrets, keys, and debug hooks gone?
- Can another engineer maintain this without the prototype narration?
Source essays
- On vibe coding vs shipping to production
- On the complexity of production codebases
- Design engineering handshake writing