What to check before you inherit a custom app

If a developer has left and the software still runs, don't assume it can still be changed. Here's what to check before you inherit a custom app: who controls the code and deploy keys, whether it builds and tests itself, how old its dependencies are, and whether anyone could ship a fix tomorrow. Get evidence on each before you decide between looking after it and rebuilding it.

Working is not the same as changeable

A bespoke quoting tool or customer portal can run happily for years after the person who built it moves on. Customers log in. Invoices go out. Nothing looks wrong.

The problem shows up the day you need a change. A VAT rule moves, a supplier changes their API, or a security notice lands for a library the app uses. Suddenly the question isn't whether the software works. It's whether anyone can safely touch it.

That's a different question from a full rescue, which we cover in rescue a SaaS someone else built. This piece is about the evidence you gather first.

Who holds the repository and the deploy keys

Start with control. Where does the code live, and whose account is it in? If the repository sits in the old developer's personal GitHub or GitLab account, you're relying on goodwill.

Then look past the code. Deploy keys, hosting logins, cloud accounts, the domain and any third-party API keys all need to be reachable by the business. A missing deploy key is enough to stop a release. If the cloud account is the gap, leaving a freelancer with your AWS root login goes through that one. What you agreed about rights to the code in the first place is a contract question, and who owns the code when you hire a software consultancy is a better starting point than anything we'd say here. Take legal advice if it's disputed.

It's the same pattern as the agency that built your website disappearing, just with more moving parts.

Tests and CI, in plain terms

Tests are small automatic checks that confirm the software still does what it should after a change. CI, short for continuous integration, is the service that runs those checks every time someone changes the code, and usually builds the app too.

So ask two things. Can a new engineer build the app from the repository using written steps? And when they change something, does anything tell them they broke it? If the answer is no, every fix carries more risk than it should. That's a gap to close, though, not a verdict on the whole system.

Dependency patches

Custom software leans on open-source libraries and frameworks. They get security fixes and new versions. When nobody updates them for a long stretch, the jump to a current version gets bigger and riskier.

Ask for a list of what the app depends on and when it was last updated. You don't need to read it yourself. You need someone who can tell you whether it's a routine catch-up or a major upgrade project.

Could someone ship a fix tomorrow

Of everything on the list of what to check before you inherit a custom app, this question ties the rest together. Pick a small, real change, such as a wording fix or a field on a form. Could an engineer who has never seen the code make it, test it and release it without the original developer?

If only one person ever knew the release steps, read one person knows how to deploy it. If nobody knows them any more, that's the first thing to recover. A safe first change proves the whole path works.

Look after it or rebuild it

Most of the time the evidence points towards looking after what you have. If the software still fits how the business works, gaps like thin tests, a manual release or old dependencies can be fixed in place. That's cheaper and less disruptive than replacing something your team relies on.

A rebuild makes sense when the software no longer fits the business, or when every change stays slow and risky even after those gaps are addressed. Missing tests on their own are a reason to add tests. They aren't a reason to start again.

How Eight Mile takes on inherited software

Our software development work includes taking over existing codebases after a short review and a written plan. That can mean recovering an undocumented codebase, restoring its build and making the first change safely. You keep the repository and accounts. Scoped work is priced in writing before billing starts, and larger projects are quoted release by release. After that, ongoing support is a separately agreed retainer, or you take the documentation and run it yourselves.

If you've inherited a custom app and aren't sure whether it can still be changed, Talk to an engineer. Send a few sentences on what it does and who built it.