Rescue or Rewrite Existing Software: How to Decide

The short answer

If your developer disappeared and left you with a half-built or buggy app, do not start by paying someone to fix things. Start with an audit: get the source code, the accounts and the hosting under your control, then have a senior engineer spend a day or two reviewing the code. The audit gives you a written recommendation to repair, extend or rewrite, and a number you can compare.

As a rule, repair wins when the structure is sound and the faults are local. A rewrite wins when every change breaks something else, the platform is out of date beyond saving, or nobody can run the code at all. We say so plainly, even though a rewrite is the bigger job for us: some systems should be rebuilt, and some should simply be left alone.

Start with an audit, not a fix

My developer disappeared and I have half an app. What do I do?

Work through these in order. None of them costs much, and the first three stop the situation getting worse while you decide.

• Stop the bleeding. Do not give anyone new access until you know what you hold. Note which logins still work.
• Secure what you can reach. Change the passwords you control and move accounts into your own name. The list in the next section tells you which ones matter most.
• Get a copy of the code. Ask the developer once, in writing and politely. If you already have repository access, make your own full copy today.
• Gather the paper trail. Emails, chat messages, invoices, any specification or design files. They tell an auditor what the software was meant to do.
• Commission an audit. A fixed, short piece of work, before any repair or rebuild is quoted.

If the thing you lost is a website rather than an app or business system, the steps differ slightly (domain, CMS logins, plugins), and we cover them in our guide to rescuing a website when the developer disappears.

What does the audit look at?

Access first: the code, the hosting, the database and the accounts. Then a day or two of review by a senior engineer, covering how the code is organised, whether it runs from a clean copy, how it stores data, which outside services it depends on, what is tested, and what is obviously unsafe. You get a written report with a recommendation and the risks, followed by a fixed quote for the route you choose, before any work starts.

Repair or rewrite: the signs that point each way

Can my slow, buggy app be fixed or do I start again?

Usually the honest answer is neither extreme on day one. The audit tells you which of these two lists your software looks like.

Signs that repair is cheaper:

• The code runs from a clean copy on a fresh machine, and the audit can reproduce the bugs.
• The faults cluster in a few screens or features, not everywhere.
• The data model makes sense: tables and records match how your business works.
• The framework and language are still maintained and widely used, so engineers are easy to find.
• The app does most of what you need and users accept how it behaves, even if it is slow in places.

Signs that a rewrite is cheaper:

• Fixing one bug creates two more, because logic is copied and tangled across the code.
• The platform or framework is end-of-life, or key libraries are abandoned and cannot be upgraded.
• The data is stored in a way that fights your real workflows, so every new feature needs a workaround.
• There are no tests, no documentation, and nobody can say how a release is built.
• Security problems run through the design, not just a few lines.
• You want something quite different from what was originally built.

Extending sits between the two: the foundation is sound, but you want new features, new platforms or connections to other systems. Extension work is quoted as new scope on top of a stabilised base.

Many projects end up as a staged mix: stabilise the current system so the business keeps running, then replace the worst parts one at a time. That keeps your users working while the new code grows beside the old.

What to secure first

What should I secure first?

Anything that exists only in the departed developer's name is, for practical purposes, not yet yours. Check each of these and move it into an account owned by your company.

• Source code. A complete copy of the repository including its history, not just a zip of the latest files. Store it in an account you own.
• Domain name. Confirm which registrar holds it and whose email is listed as the owner. Losing the domain loses the email and the site with it.
• Hosting and servers. Cloud or server accounts, billing, and admin access. Check that renewals are paid from a card you control.
• App store accounts. The Apple developer and Google Play accounts that publish your app. If these are in someone else's name, you may be unable to ship updates, and the listing is at risk if that account lapses.
• Database backups. A recent copy of the live data, and proof that it can actually be restored. A backup nobody has tested is a hope, not a backup.
• Third-party keys and logins. Payment providers, email and SMS senders, maps, analytics and any other service the app calls. Make a list, then replace the keys once you hold the accounts.

Rule of thumb: if you cannot log in without asking the previous developer, you do not own it yet.

None of this requires an engineer. A careful owner or office manager can work down the list in an afternoon, and it makes any later repair safer and cheaper.

How a takeover works and what we need from you

How do I take over software that someone else built?

A takeover is a sequence, not a leap. We need from you:

• Access to the code, hosting, database and the accounts above, or whatever part of that list you have.
• Anything written down: specifications, designs, emails, invoices, bug lists, and a note of what users complain about.
• One person who understands how the business uses the software and can answer questions.
• A clear idea of what you want next: fix what exists, add something, or replace it.

We then review the code, report back, and give a fixed quote before work starts. Payment follows a 50/25/25 plan, and you own the code and the data. Our senior engineers in Kampala work East Africa Time (UTC+3), which overlaps the UK and European working day and the start of the US East Coast day, and a US team member joins client video calls.

Our old system works but nobody understands it. What now?

First, do not rewrite it just because it is old. A system that has run your business for years holds rules and edge cases that nobody wrote down, and a rewrite that misses them creates new problems. We usually begin by reading the code, mapping what it does, and putting tests around the critical paths so changes become safe.

From there, legacy modernisation often means wrapping the old system with clean connections so new tools can talk to it, which is the kind of work covered in API development and integration, and then replacing pieces gradually. Sometimes the right answer is to retire the old system for a ready-made product, and we will tell you if that is the case; custom versus off-the-shelf software explains how to judge it.

What it costs, and when not to hire us

The audit comes first and is quoted as a fixed piece of work. After that, each route has its own fixed quote. The table shows how the routes differ and what drives the number. Prices are starting points, and every project gets its own fixed quote before work begins.

Rescue work sits alongside our custom software development for new systems, and for projects that need a standing team after the rescue, hiring a development team keeps the same engineers on your product. We have 37 live website and app builds on our portfolio page, but a rescue is judged on your code, not on our list.

We are not the right fit if:

• The code is healthy and you need a few hours of small fixes, where a freelancer on call may suit you better.
• You want a rewrite approved without an audit. We will not quote one blind.
• Your priority is the lowest possible price. We are affordable, with senior engineers and a team that stays, but we are not the cheapest option.
• Your system sits inside a regulated or specialist product where only the original vendor can legally or technically change it.

Frequently asked questions

How long does an audit of existing software take?

Once we have access to the code, hosting and accounts, the review itself takes a day or two. Most delays come from waiting for access, which is why securing the accounts first saves time.

How much does it cost to rewrite existing software?

A custom system rewrite starts from , with a fixed quote given after the audit and before work begins. Repair is quoted separately and, when the foundation is sound, is usually the smaller job.

What if I cannot get the source code at all?

Then you have software that runs but no way to change it. We can study what is live, how it behaves and what data it holds, and use that as the specification for a rebuild. It is usually slower than a repair, which is one more reason to secure the code early.

Will I own the code after you rescue or rebuild it?

Yes. The client owns the code and data. You get the repository in your own account, so you are never locked in to us.

Does working with a team in Kampala cause time zone problems?

Our Kampala team works East Africa Time (UTC+3), which overlaps the UK and European working day and the start of the US East Coast day. A US team member also joins client video calls.