"Nobody dares touch this system anymore. I'm wondering if we should just rebuild it from scratch." Owners who say this have usually already been convinced twice, by two different people: one who said "don't touch this, changing it will break it," and another who said "this is beyond saving, let us rebuild it for you." Both could be right, and both could just be convenient for whoever's saying it — and guessing wrong means an entire year's budget spent in the wrong direction. It's not that you can't make the decision — it's that you don't have the material to make it with. Here are the four criteria we actually check about when we look at a system.
Don't rush to ask "should we rewrite it"
"Rewrite" sounds clean, but it carries three costs that get overlooked:
- Someone still has to keep the old system running during the rebuild, so you're burning money on both at once.
- Halfway through, you discover dozens of special-case handlers in the old process that nobody remembers the reason for.
- Data has to be migrated, and only then do you find out the format isn't what you assumed.
Why the same system build gets wildly different quotes from different vendors covers how quote gaps come from how deeply requirements were actually scoped — and rebuilding a system to be "the same as now, but better" is even harder to scope clearly. So the order has to be reversed: assess the current state first, then decide whether to rewrite.
Four criteria: start with a table to spot the lean
Four questions, two directions. Start with the table to see which way it leans:
| Criterion | Leans toward saving it | Leans toward rebuilding |
|---|
| Is it still readable | Version history exists, structure follows a pattern | Just a zip file, nobody knows the technology |
| Can the data be exported | Sits in a standard database, exports cleanly | Scattered across several places, one field used for multiple purposes |
| Can the architecture hold for two more years | Requirements are just more volume, more detail | What's needed doesn't exist in the current design at all |
| Is fixing versus rebuilding the same math | Monthly maintenance cost drops clearly after fixing it | Every change still costs the same after fixing it |
If all four lean the same way, that's your answer. Two-to-two means you need to look closer.
Criteria one and two: readable, and exportable
Readable doesn't mean someone can read the programming language — it means someone can answer "what does changing this affect." We look at:
- Whether version history exists to check who changed what and when.
- Whether similar things live in the same place, and whether the naming actually means something.
- Whether the technology used is still maintained, and whether people who know it can still be found.
Exportable matters even more: a system can be rebuilt, but data can't be redone — the code is just the container. We look at:
- Whether the data sits in a standard database and can be exported cleanly.
- Whether the same type of data is scattered across a database, spreadsheets, and an external service all at once.
- Whether any field can only be interpreted using rules buried in the code.
If an engineer just left and you haven't gathered everything yet, first go through the 12 things to get back first after an engineer leaves — without that material, this assessment can't be done.
Criteria three and four: can it hold, and is it really the same math
Architecture is the system's skeleton — how many users and how much data it was designed for. Only the owner can answer this one, because only you know where the company is headed over the next two years:
- Can hold: what's coming is just more volume — more fields, more reports, one more payment method.
- Can't hold: what's needed is something the current design has never done, like going from internal use to opening up to customers.
- Once the direction diverges, every feature forced on top costs more than it should, and gets more fragile with each addition.
The fourth criterion is the one most often miscalculated. The common math is "fixing costs X, rebuilding costs Y, Y is bigger so let's fix it" — and that math leaves out four things:
- The monthly maintenance cost after the fix. A system nobody can read still costs the same to change every time, even after it's "fixed."
- How many more uncounted problems surface during the fix — estimates for an old system are almost always too low.
- The dual-track cost during a rebuild: the old system still has to run, the new one has to be built, and both need someone staffed.
- A rebuild isn't from zero: data, processes, and business logic that's already been validated can carry over.
Put those back in, then compare. Why one-off outsourcing fails covers this: what's actually expensive isn't any single quote, it's starting from scratch every single time.
A health check only ends in one of three conclusions
Once the four criteria are checked, the outcome usually lands on one of three conclusions in the health check report:
- Ready to take over as-is: the most common outcome. "Nobody dares touch it" usually just means nobody's actually looked at it.
- Needs cleanup first, then takeover: the code is workable, but backups, deployment, or documentation are missing and need fixing first — quoted separately based on condition.
- Rebuilding is recommended: we'll tell you directly, and tell you exactly what has to be preserved if you rebuild.
The health check is a 60-minute online meeting — we only need to see the code — and within 3–5 business days you get a one-page report, priced based on system size, with no contract required. What is Helper CTO covers who should actually be the one making this call.
Three principles we follow when making this call
- No assumed answer: we take on long-term relationships, not one-off rebuild projects, so we have no incentive to push you toward rewriting.
- Look first, talk later: we don't take on anyone who wants a quote without a health check first — we're only qualified to discuss cost after we've actually looked.
- The report is yours: no contract required, and you can take it and ask someone else. When the engagement ends, the documentation and records are yours too.
Getting this call right once saves you years of money down the line.
Whether to save it or rebuild it is the first question we're most often asked as Helper CTO — like an in-house tech lead, just not on your payroll, with the same team taking over or cleaning up once the call is made. The first step is a 60-minute system health check: we only need to see the code, no credentials to your production environment required, and within 3–5 business days you'll get a one-page report stating which of the three conclusions applies. If you have a system right now that nobody dares touch and nobody dares rebuild either, you can start here: Helper CTO: System Maintenance Plan.
Technical Sharing
