An abandoned software project: take it over or rewrite it?
The agency walked away and the project is yours. The first instinct is "let us rewrite it" and it is usually the most expensive call. The handover inventory, the technical review, and the test that actually decides.
The agency left, communication broke down, or the contract ended badly. The project is half-built and all you hold is a repository address and a server you are not sure is running.
The sentence you will hear most at this point is: “Rewriting it is cheaper than taking it over.” Sometimes that is true. More often it is the shortcut of a team that does not want to read someone else’s code — and it makes you pay twice.
Collect access first: this is a legal job, not a technical one
The thing to do before any code handover has nothing to do with code. Verify that all of the following are in your name:
- The repository and its full commit history
- Domain and DNS control
- Servers, cloud accounts, databases
- Environment variables and secrets
- Third-party accounts: payments, email, SMS, maps
- The most recent database backup
Ask for this list before the relationship sours. Collecting access after a bad ending stops being an engineering problem and becomes a legal one. With your next agency, insist that everything is opened in your name from day one; skipping that clause is the most expensive mistake to fix later.
The technical review: one week, six questions
A takeover decision is not made by guesswork. A week-long review answers:
- How old are the dependencies? A framework two major versions behind can push the upgrade cost to half the project.
- Are there tests? In untested code no change is safe; every edit is a gamble.
- How does deployment work? If files go up by hand over FTP, there is no such thing as a rollback.
- Is the database schema coherent? Code can be fixed; a broken data model cannot — it has to be migrated.
- Any security holes? Known-vulnerable dependencies, exposed keys, missing authorisation checks. Covered in website security.
- Can the code be read? “It works” and “it can be maintained” are not the same thing. This is where the real cost sits.
The review should produce a single sentence: taking it over costs this, rewriting costs that.
The test that actually decides
Not the technology choice — the value of the business logic.
If a system has been in use for years, it holds hundreds of edge cases nobody remembers: this customer type gets a different discount, that document calculates tax separately. None of it is written down anywhere. It lives only in the code.
Rewriting means resetting that knowledge to zero. The new system then spends six months absorbing “the old one used to do this”. Ugly code can still carry something that was learned.
A rewrite is the right call when the framework no longer receives security patches, when the data model cannot carry what the business does today, or when the system was never really used — that is, when there is no learning to preserve.
The transition
The incoming team’s first job should not be building features. In order: set up the deployment pipeline, prove the backup can actually be restored, write tests for the critical flows. Adding features before that is building another floor onto a burning house.
Those three steps usually take two to three weeks and produce nothing visible. A project that does not budget for them runs over a second time.
If you want us to spend a week on your project and put the two costs side by side, let’s set up a call. If you are starting fresh with a new team, set the timeline expectation correctly from the beginning.
