What taking a prototype into production taught me
What the Arbitr build taught me about preserving product learning, changing implementations and checking production readiness.
In April 2026, we had an interactive prototype for Arbitr. You could see the intended product experience, but much of the frontend still used hardcoded data. It was useful for discussing what we wanted to build. There was more work to do before customers could depend on it.
I led the engineering delivery and contributed to the platform foundations. Product, Operations, Infrastructure and other engineers were involved throughout. Early on, I argued for significant frontend refactoring before production deployment.
The useful lesson for me was how much judgement sits between a working demonstration and an operational product. Some parts should be preserved. Others need changing. Some need replacing before adding more features makes that replacement harder.
Preserve the understanding the prototype has created
A prototype helps people make decisions. They can try a workflow, challenge assumptions and point to something specific when they disagree. That understanding has value even when the implementation needs substantial work.
I want to carry those product decisions forward. Otherwise, a technical rebuild can quietly reopen questions that the team has already answered. A screen may look similar while changing an important behaviour. Or a cleaner implementation may drop an awkward requirement that exists for a good business reason.
With Arbitr, we asked colleagues to check parity as the frontend changed. That was an important part of the work. The existing experience gave us something concrete to compare against, while Product could clarify which behaviours mattered.
Parity also needs judgement. Preserving an intended workflow does not mean preserving every limitation of a demonstration. We need to know which details express a real requirement and which exist because the prototype took a shortcut.
Be specific about what needs to change
Our frontend audit raised concerns around security, testing, architecture, accessibility and observability. That gave the refactoring discussion substance. We could talk about the work needed to support the product, alongside the visible features.
We replaced the initial React scaffold with a Nuxt implementation. That was a decision in the context of our team and this application. The framework choice still needed to be supported by sensible architecture, useful checks and people who understood the system.
I find three questions helpful when deciding what to do with a prototype:
- Which customer behaviours have we learned enough about to preserve?
- Which implementation choices will make the next stage difficult or risky?
- Which existing capabilities can we integrate without rebuilding them?
Those questions describe three different kinds of work in the Arbitr build:
| Decision | Example from the build | What still needed checking |
|---|---|---|
| Preserve | The intended product workflow, with parity feedback requested as the frontend changed | Which behaviours expressed a real requirement and which reflected a prototype shortcut |
| Replace or refactor | The frontend implementation after the audit raised production concerns | Behaviour parity and the engineering requirements behind the refactor |
| Integrate | Existing translation and file-handling capabilities | Data contracts, deployment ownership, latency and failure behaviour across the boundary |
The last column describes the work needed to support each decision. It is not a claim that the first release resolved every concern.
Reusing an existing service can save rebuilding a capability. It still leaves an integration to understand. Replacing a frontend can create a cleaner baseline while introducing a risk of lost behaviour. The work needs to be assessed on both sides.
A practical decision note would state what we are keeping, what we are changing, why the change is needed and how we will check the result. That gives Product and engineering something specific to challenge before the implementation grows.
Follow the work across the boundaries
A customer sees one journey. Inside the platform, that journey can cross several services and teams. Each part can look reasonably complete while the overall flow still has gaps.
Our rollout included integration dependencies and operational questions alongside feature delivery. Late in June, end-to-end testing still needed attention, an invoicing integration depended on an older data shape, and deployment ownership needed clarification.
Those are different problems. More frontend work would not settle a data contract. A service being ready would not establish who was responsible for deploying it. Bringing them into the readiness discussion made the remaining work more explicit.
Later testing also exposed scaling, configuration, queue and progress-reporting issues. That was useful evidence about the system we were building. A convincing demonstration with a small workload could not answer those questions for us.
This changes how I think about readiness. I want to trace a customer action through to a useful result, including the places where it might stop. I also want someone to be able to tell what happened without having to reconstruct it from several disconnected systems.
A visible failure with a clear recovery path is easier to deal with than a workflow that looks successful while work remains unfinished.
Keep release milestones separate
Arbitr reached an early production deployment in May, followed by a broader release at the end of June. The human-review workflows, customer migration and continued operational improvements had their own work around those milestones.
That distinction matters when describing progress. Deploying an application, completing an end-to-end workflow and moving a customer onto it are different achievements. Each needs its own evidence and owners.
Our end-of-June production announcement still included an integration issue needing attention. Customer migration continued after the technical release. Those details belong in the story because they explain the actual work of bringing a platform into use.
I would rather have a release discussion that identifies the remaining dependency clearly than one where a single green status hides several different meanings of complete.
Make the next decision easier
Taking a prototype into production taught me to protect what we have learned while being willing to change how it is implemented. That means making the reasoning visible to the people doing the work.
A frontend replacement needs a reason. Reusing a service needs an understanding of its behaviour. A release date needs a clear description of what will be ready and what will follow.
For the next prototype, I would start those conversations early and keep the decisions small enough to verify. What are we keeping? What are we changing? Who needs to check the result before another layer of work depends on it?