Fast, Real, and Production-Ready: Prototyping at Opply
Recently, I have been reflecting on how the idea of prototyping is often interpreted in software. Too frequently, it is treated as an MVP: an intentionally imperfect product that resembles the real thing, but is never meant to truly be it. Something built quickly, used briefly, and ultimately thrown away.
That is not how I understand prototyping.
To better articulate what prototyping should mean, and to describe how we approach it at Opply, I started looking outside the usual software narratives. That search led me to the world of racing car engineering, where prototypes are not disposable sketches, but fully engineered machines designed to run, be tested, and evolve. That comparison is the lens through which I now think about product engineering prototyping at Opply.
When a racing team builds a prototype car, they don’t start with something fragile or disposable.
They build a real car: fully engineered, safe to drive at speed, and capable of running on the track today. What’s missing isn’t quality or discipline, but final optimisation, long-term tuning, and mass-production constraints.
That is how we think about prototyping at Opply.
Not a Demo, Not a Sketch But a Real Machine
In motorsport, a prototype is not a proof of concept. It is a working vehicle, built by experts, following strict engineering rules, designed to be pushed to its limits so the team can learn fast.
Our software prototypes follow the same principle.
They are not throwaway MVPs or temporary demos. They are real systems, built inside the real codebase, following the same architectural rules, conventions, and standards as any production feature.
A prototype at Opply:
- Runs in real environments
- Follows the repository’s architecture and domain boundaries
- Includes tests, logging, and guardrails
- Is safe to evolve, not something we plan to discard
The goal is learning through reality, not simulation.
What We Deliberately Leave Open
Just like a racing prototype, an Opply prototype is intentionally unbounded in certain areas.
We defer:
- Hard scalability constraints
- Performance optimisation
- Final infrastructure sizing
- Long-term operational tuning
We do not defer:
- Code quality
- Correctness
- Maintainability
- Engineering discipline
This balance allows us to move fast without creating hidden debt. The system may not be ready for mass scale, but it is always ready to be trusted.
Why We Don’t Build Throwaway MVPs
In software, MVPs are often designed to be temporary. In practice, they rarely are.
What starts as “just an experiment” frequently becomes production.
By treating prototypes as production-ready from the start, we avoid that trap.
Our prototypes are designed to:
- Evolve naturally into long-lived systems
- Be hardened and scaled when the value is proven
- Preserve clarity and ownership from day one
There is no switch from “hack mode” to “real engineering” at Opply. It is always real engineering.
Prototyping as a Team Discipline
This approach only works because it is shared.
Prototyping at Opply is not about individual speed or clever shortcuts. It is about collective discipline, trust in the codebase, and confidence that even our earliest iterations reflect the standards we stand for.
Like a racing prototype, what we build early may change: components will be upgraded, constraints will be added, and performance will be refined, but the foundation is solid from the first lap.
At Opply, prototyping is not the opposite of production.
It is simply production, allowed to move faster before the final limits are set.
