Shipping iterations: knowing when toy → real

Why this matters

The toy stops being useful when you've extracted everything it can teach. The signal isn't 'I added all the features' — it's 'the next improvement requires a real environment'. At that point the toy has served its purpose; you graduate to production scaffolding (audits, formal verification, mainnet deployment) but you do not extend the toy further. Extending the toy beyond its useful range is one of the most common ways protocol projects die before reaching ship.

Demo

Concrete signals it's time to graduate: (1) the next failure mode you want to find requires mainnet conditions you can't simulate; (2) the toy is more complex than the real protocol's first commit; (3) the next change is incremental rather than mechanism-level. When any of these fires, archive the toy and start the real implementation in a fresh repo with real audits and a real deployment plan.

Try it yourself

1. Look at a protocol's first mainnet commit on GitHub. Compare its complexity to a published toy. The real version is usually 3–5× the toy — never 50×.
2. Identify a protocol that shipped too late (a toy that kept being extended past its useful range). Note what feature additions weren't actually load-bearing.
3. For your next protocol, write down before you start: 'I will stop extending the toy when X happens'. The condition has to be concrete enough to recognise.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, describe the signals that a toy has done its job.

2. Why it works (the mechanism)

Walk me through the transition from toy to real implementation. What scaffolding changes? What stays?

3. Advanced — application & what's next

Some protocols never had a clean 'toy first' phase — they grew organically from a working implementation. What can be reverse-engineered from those, and what's lost?

References

• Uniswap V1 — first commit
• Lido — first deployment retrospective