A prototype you built to prove a point is now being used as if it were production. Do you harden it or replace it?

Short answer

Decide on the prototype's foundations rather than its polish: if the data model and the correctness boundaries are sound, hardening is cheaper and keeps the users you have, and if they are not, no amount of testing and monitoring will make it safe to keep.

This is not an accident and it is not the customer's fault

A prototype becoming load-bearing is the normal outcome of a successful prototype, not a misunderstanding to be corrected. You built something that answered a real question, somebody found it useful, they told a colleague, and now a team's Monday morning depends on it. Nobody made a decision to promote it, which is exactly why there is no owner, no runbook and no test suite. Candidates who answer this question with irritation at the customer, or with a proposal to stop people using it until it is properly built, have misread the situation: usage is the evidence that the thing is valuable, and the correct instinct is to protect the value while removing the risk.

The first move is therefore not a technical judgement at all. It is finding out what is now depending on this. Who runs it, how often, what they do with the output, whether any downstream number is derived from it, and whether anybody outside the immediate team has seen figures that came from it. That inventory determines the urgency of everything else, and it frequently produces a surprise — the spreadsheet somebody built on top of your CSV, the weekly summary that goes to a director, the second team that started using it without telling you.

Judge the foundations, not the finish

The decision between hardening and replacing turns on one question: are the fundamentals right? Prototypes are typically untidy in ways that are cheap to fix and occasionally wrong in ways that are not, and telling those apart is the whole skill.

Prototype property	Cheap to fix later	Requires a rebuild
No tests, no error handling	Yes — add them incrementally
Hard-coded paths and credentials	Yes — externalise configuration
Runs from one person's machine	Yes — move to their scheduler
Non-idempotent writes, no reconciliation		Usually — correctness was never designed
Data model that cannot represent a real case		Yes — everything above it encodes the wrong shape
Silent failure that produced wrong numbers		Yes, and the history needs restating

The left column is a list of tasks. The right column is a list of assumptions baked into the shape of the thing, and the reason they cannot be patched is that the code, the outputs and increasingly the users' mental models all depend on them. A prototype that assumed one claim has one policy, in a business where a tenth of claims span two, is not missing a feature; every table, join and figure it has ever produced is built on a false statement.

There is a third category worth separating out, which is the prototype whose logic is right and whose interface is a lie. If the output looks like an authoritative report but is actually computed from a partial extract, the danger is not in the code at all — it is that its presentation invites more trust than it earns. That is fixable in a day by labelling it, and labelling it should happen immediately regardless of which path you take.

Do the same three things this week either way

Before the harden-or-replace decision is made, some work is unconditional, because the risk is live now and the decision may take a fortnight.

Make failure loud. The most dangerous property of an accidental production system is that when it breaks it does so silently and somebody acts on stale or partial output. A check that the run completed, that the row count is within a plausible range, and an alert to a human when it is not, is a few hours of work and removes the worst available outcome.

Label the output with its provenance. Every file, table or screen it produces should carry what it was computed from, when, and a plain statement of its status. A line reading "prototype output, covers the London book only, generated 06:15 from Tuesday's extract" prevents the specific failure where a number travels upwards and arrives in a meeting without its caveats.

Name an owner and tell the users. Even if the owner is you for the next three weeks, the absence of a name is what allowed this to become load-bearing invisibly, and the users need to know who to contact when it stops.

Hardening in place is usually right, and it needs a boundary

Where the foundations hold, hardening wins on grounds that have little to do with code quality. The users are already there, the behaviour is already understood, and a rewrite spends weeks producing something that at best matches what exists — which is the least rewarding kind of engineering to justify to a sponsor who is currently happy. Incremental hardening also lets you sequence by risk rather than by architecture, which means the dangerous parts are fixed first rather than last.

The condition is that hardening needs a defined finishing line, otherwise it becomes an indefinite drip of small improvements that never reaches a state anyone would call supported. Write down what "production" means for this specific system — it runs on their infrastructure, on a schedule, with alerting their on-call sees, with a documented recovery procedure, with a named owner on their side and a test that would catch the failure you most fear — and treat that list as the scope of a small, bounded piece of work with an end date.

Replacing while the old one keeps running

When a rebuild is genuinely required, the mistake is to treat it as a project that culminates in a switchover. The users cannot pause for six weeks and the prototype will keep being used, so the realistic shape is to build the new implementation behind the existing output. Run both against the same inputs, compare the results daily, and use the differences as your test suite — every divergence is either a bug in the new version or a bug in the old one that the business has been living with, and both are worth knowing about.

That parallel period is also how you handle the conversation with the sponsor, because it turns a rewrite request into a risk-reduction plan with visible interim results. Very few sponsors will fund "we need to rebuild the thing that works". Most will fund "we are running a corrected version alongside it and here are the seventeen cases where they disagree", which is the same work with the evidence attached.

Where engineers lose this argument

The failure is not choosing wrongly between hardening and replacing. It is making the case on the wrong basis: leading with the prototype's untidiness, its missing tests, the fact that it is a single script, the technical debt. To a sponsor those are aesthetic complaints from a contractor who wants more time, and the argument reliably loses to a system that is currently producing something people like.

What wins is a concrete failure narrated in business terms, with the mechanism attached. "If the upstream extract lands late, this produces a file that looks complete but is missing the last day, and the team will settle claims from it without knowing" is a sentence a sponsor can act on within the hour. Frame the ask around the failure you are removing, not the quality you are adding, and never open with the word rewrite when the honest scope is a bounded piece of remediation.

Harden when the data model and the correctness boundaries were right and only the engineering is missing; replace when the prototype encodes something untrue about the business. Either way, make it fail loudly and label its output before you argue about which.

---

© 2026 Preptima. Originally published at preptima.com.