Custom software · 7 min read
You have inherited a platform. What do you fix first?
It works. Customers use it. And nobody now on the team built it, so every change feels like it might break something nobody can see. Here is the order we work in when we are handed one — and what it looked like on a real platform.
In short
When you inherit a platform someone else built, fix it in this order. First, close what could leak or be abused: who can read which data, who can call which admin function, and anything open to the whole internet that should not be. Second, add the tests that let you change things safely, because without them every later fix is a gamble. Third, fix correctness — the places where it quietly does the wrong thing. Only then turn to what users and search engines see: accessibility, findability, languages and new features. Visible work feels like progress, but on an inherited system the work that matters most is usually invisible, and it has to come first.
Key points
- Inherited systems are usually fine on the surface. The risk is underneath — in who data answers to, and whether anything proves a change is safe.
- Fix exposure first: data visible to the wrong people, admin functions that do not check who is calling, and services open to anyone.
- Write tests before changing much. A system with no tests cannot be improved safely, only altered hopefully.
- Accessibility, search visibility and new languages matter — after the foundation will not break under them.
- Count the work instead of estimating it. A list of findings, closed one by one, tells everyone exactly where things stand.
- Rewriting from scratch is rarely the answer. Most inherited systems need the twenty fixes nobody had time for, not a new system.
Why inherited systems are frightening
An inherited platform usually works. That is what makes it hard. Customers are using it, so it cannot be taken down; nobody currently on the team wrote it, so nobody is sure what each part is for; and there is often nothing — no tests, no notes — to say whether a change has broken something.
So teams stop changing it, except when they must, and then they change it nervously. The system does not get worse because anyone damages it. It gets worse because nobody dares to improve it.
The way out is not courage. It is order: deal with the things that can hurt people first, then build the safety net that makes every other change routine.
A real one: CheckUp Asia
CheckUp Asia is a platform that compares health screenings and medical packages across hospitals in Asia. It existed and it worked. In September 2026 a technical review set out what it was not yet safe to scale — 49 findings, grouped into six workstreams: security, correctness, testing, internationalisation, discoverability and the build itself — and we were brought in to close that list.
Most of the findings were the kind of thing that never shows on screen and decides everything: who a database row answers to, whether a function checks that the person calling it is staff, whether anything proves a change did not break a booking. That is typical of an inherited system, and it is why the order matters.
First: close what could leak or be abused
Before anything else, find out who can see and do what. On an inherited system this is where the serious problems tend to be, because access rules are easy to get wrong and invisible when they are wrong — the site looks exactly the same whether a table is open to everyone or properly locked.
On CheckUp Asia, that meant database access rules narrowed from public to signed-in users and scoped to the columns each role owns; admin routes guarded; sensitive identity data encrypted inside the application; rate limits put on the AI features; and three email functions that would send mail for anyone, closed. The database itself was upgraded to pick up outstanding security patches.
- Can one customer read another customer's records?
- Does every admin function check that the caller is actually staff?
- Is any service — email, AI, file storage — open to anyone who finds its address?
- Is sensitive personal data stored in a form someone could read if they got the database?
- Is the software it runs on patched?
Second: build the safety net
A system with no tests cannot really be fixed. It can only be changed and hoped about. So the second job is to write tests for the things that must never break — and on a platform holding people's health information, the first of those is that one person can never see another's records.
CheckUp Asia had no executable test suite when we arrived. It now has unit tests, policy tests that prove one patient cannot read another's records, and end-to-end tests that drive the real interface — kept behind their own settings so they can never be pointed at the live site. The first full run passed 43 of 43.
From that point on, every later fix gets cheaper and calmer, because a change that breaks something says so immediately rather than weeks later in a customer's inbox.
Third: what users and search engines see
Only once the foundation is safe does it make sense to spend time on what people can see — because that is the work a fragile foundation tends to undo.
On CheckUp Asia this was the larger share of the visible work. Accessibility went from 158 failures across 15 pages to zero, with none carried forward as exceptions. Around 970 pieces of text that had been written straight into the code were pulled out into a catalogue, and twelve languages were translated and switched on — more than the five originally planned. And the site was made findable: missing pages had been answering as if they existed, pages carried two titles each, and search was moved onto the database and rendered on the server so search engines could read the results.
Notice what came last. A redesign or a new feature is the most tempting place to start on an inherited system, and the most expensive one to have to redo.
Count it, do not estimate it
The single habit that makes inherited work manageable is treating it as a list rather than a feeling. Each finding becomes a card. Each card is closed when it is done and proven. At any moment, anyone — the client, the team, a new developer — can see exactly how much is finished.
At the time of writing, 78 of the 81 cards on the CheckUp Asia board are closed. The three that are not are honest about why: taking over ownership of the deployment, the pull-request and decision record, and the catalogue content the platform needs before it is worth showing at scale. The engagement is still open, and saying otherwise would be the easiest thing to get wrong in a post like this.
Do not rewrite it — yet
The instinct with a frightening system is to start again. Occasionally that is right. Usually it is not: a rewrite throws away everything the old system quietly gets right, takes months before it does anything useful, and tends to rebuild the old problems alongside the new ones.
Most inherited platforms need the fixes nobody had time for, done in the right order — not a new platform. A rewrite is worth recommending only when the existing system genuinely cannot carry what the business needs next, and that is a judgement to make after the foundation is understood, not before.
If you are holding one now
If you have a system you are afraid to deploy, send us the repository and the thing you are most worried about. We will tell you, honestly, whether it needs rewriting — or just the twenty fixes nobody has had time for.
Questions
Frequently asked
What should you fix first on a platform someone else built?
Anything that could expose data or be abused: who can read which records, whether admin functions check who is calling, and services left open to anyone. Then add tests, so every later change can be made safely.
Should we rewrite an inherited system from scratch?
Rarely. A rewrite takes months before it does anything useful and often rebuilds the old problems. Most inherited systems need a list of specific fixes done in the right order; a rewrite is worth it only when the existing system genuinely cannot carry what the business needs next.
Why add tests before making improvements?
Without tests, nobody can tell whether a change broke something until a customer finds it. Tests for the things that must never break turn every later fix from a gamble into a routine change.
Can you take over a system another developer built?
Yes. We audit what exists, fix or extend the parts worth keeping, and only recommend a rebuild when that is genuinely the better decision for the business.