Quick thoughts: How prototypes give us super powers and the trade-offs we must accept

This is an expanded version of an internal note I wrote last week, on how we get super powers through prototypes, and what we must give in return.

Sometimes we want to break the rules. Maybe we want to try something quickly, or explore an idea without being constrained by existing systems. Whether we build something by hand, or vibe code it, we give ourselves permission by labelling it a prototype.

By giving it the prototype label, it gives us super powers where we can:

  • Move quickly, without process overhead.
  • Get customer feedback, and iterate rapidly.
  • Experiment freely, without fear of failure.
  • Challenge existing assumptions and norms.
  • Share ideas with colleagues, and understand implementation approaches.

In return, we must accept some trade-offs:

  • Prototypes are not production-ready, and won't meet our usual standards for quality, security, or reliability.
  • Prototypes are temporary, and are designed to be discarded.
  • Prototypes are rarely documented or maintained.

Before a line of code is vibed or a package installed, we know the outcome: our prototype will be thrown in the bin. The point is to learn fast, move quickly, not to build for real customers.

Be explicit about its purpose, scope, and limitations.

The golden rule:

Prototypes are throwaway, not permanent.

After throwing them away, we'll still scavenge useful parts from them. We can salvage snippets of code that helps us with the next prototype, functions or classes that – with a few tests – are good to ship to production, or a design pattern that saves us hours in our next feature.

Now anyone can build prototypes with AI tools like Claude Code, replit, and Cursor, don't mistake prototype for production, and enjoy the super powers.

Some further reading: