As architects, something lands on our desk that is definitely not production-ready, yet it’s confidently presented as “close enough.” The assumption is usually the same: a little hardening here, a few tweaks there, and we’re good to go.
We all know how that story ends. It never works that way.
Part of our role is to slow the conversation down and agree on the language we’re using, because words like experiment, prototype, and product are not interchangeable. They represent very different levels of risk, control, and expectation.
Experiment
An experiment is exactly that — an idea in motion.
• Built fast, expected to fail early, and iterated often
• Lives entirely in the Dev environment
• Created to learn, not to last
Experiments are valuable, but dangerous when oversold. The moment we present an experiment as “nearly a product,” we create false confidence and expectations that can’t possibly be met.
Prototype (Proof of Concept)
A prototype is a step forward, but it’s still a long way from production.
• An early version used to test concepts and designs
• Shared with a small, clearly defined audience
• Built to gather feedback, not to scale
A prototype proves something can work, not that it should or will work in production. It is not hardened, supportable, or enterprise-ready — and pretending otherwise sets everyone up for pain later.
Pilot Program
Pilots often create the most confusion.
• A small-scale, pre-release implementation
• Used to identify gaps, road-test real usage
• Available to a limited, well-defined group
Despite how real a pilot may look, it is still not a product. It’s a dress rehearsal, not opening night.
Product
A product is where accountability truly begins.
• Built for enterprise use or sale
• Supportable, managed, and governed
• Tested, validated, and fit for purpose
• Designed to scale, operate, and endure
A product carries operational responsibility. It has owners, support models, security controls, and lifecycle management. Anything less is simply not Production-ready, no matter how impressive the demo looks.
The Architect’s Responsibility
When a stakeholder arrives with an experiment, prototype, or pilot and asks you to “just put it into production,” that’s your moment to add value.
Your job isn’t to block progress. It is to explain the difference between a pre-production solution and a real, supportable product.
We should also be cautious about what we show and how we frame it. Pre-production solutions can look deceptively complete, and there is often a vast chasm between what’s demonstrated and what’s required for production.
#PracticalEA. Visit PracticalEA.com
