That's your codebase up there with the cow
We've mapped the darkest corners of software territory so you don't have to.
Taking over software another company built is not development, it's archaeology with a release date. We have inherited codebases with no tests, no README and a single commit message that says "fix". None of it shocks us. Pull up a beach chair.
Software project takeover that starts with reading, not rewriting
We audit what exists, tell you what it's worth, then agree what happens to it.
Most agencies quote a rewrite, because a rewrite is easier to estimate and more profitable to deliver. It is also how companies lose a year and ship something that does less than what they already had. A software project takeover should begin with an audit: what works, what is dangerous, what is undocumented, and what it costs each month to keep alive.
Only after that does anyone sensibly argue about code. Sometimes the answer is stabilise and extend. Sometimes it is replace two services and keep the rest. Occasionally it really is a rebuild, and we will say so even though it is the answer that suits us least. Switching development vendors should cost you a few weeks of overlap, not a year of lost progress.
Everything a handover actually involves.
The code is the easy half.
A vendor handover is not a zip file and good luck. It is code, credentials, infrastructure, domains, licences, data and the knowledge that was never written down. We take all of it, and we write down the part that wasn't.
A codebase audit - findings by file, line and severity
The architecture, reconstructed from the source, so you know what you own
Dependency and supply-chain review
Repositories, domains and cloud accounts moved into your name
Every credential the previous team held, rotated
Infrastructure takeover on AWS, GCP or Azure
Critical-bug triage, so it stops getting worse while we plan
Security and performance remediation, in an order you approve
Documentation written from the code, not from memory
A test suite where there wasn't one
CI/CD rebuilt, so releases stop being events
Monitoring, logging and alerting you can actually read
Keep, refactor or rebuild — the legacy modernisation call, costed per component
A roadmap you can put in front of a board
And the part nobody wrote down, which is usually the part that matters
Still reading? Good. It gets better.
We start without their help
Nobody gets blamed
No feature freeze
Rewrites are the last resort
Your next exit is a handover
Get the code back under control
If you inherited it and you're now responsible for it, you're our people.
Not sure which of those you are? Send the repository. We'll tell you what you've got.
Ask us anything
Software rescue is taking over a software product that another team built and making it safe to run, change and own again. In practice it covers four things: an audit of the existing code, recovery of the repositories, infrastructure and accounts, stabilisation of whatever is actively breaking, and an honest decision about whether to keep, refactor or replace what’s there. It is the service companies look for when a vendor relationship ends badly, a founder-built MVP has outgrown itself, or an internal team has left.
Yes, that is most of what we do here. We ask for read access to the repository and a short call, run a production-readiness audit, and come back with findings, risks and a monthly maintenance figure. From that you get a fixed-scope plan. You do not have to commit to the whole takeover to get the audit – plenty of clients buy the assessment first and then decide.
More often than people expect, the position is better than it looks. Start by establishing what your contract says about ownership and what is registered in whose name – domains, cloud accounts, app store listings, third-party API keys. We can usually rebuild from whatever you do have access to: a production deployment, a partial repository, an old backup. We also rotate every secret the previous team knew, which is a step a surprising number of companies skip. If the contract genuinely leaves ownership with them, that is a conversation for your lawyer, and we can supply the technical statement they will ask for.
The audit that starts it is priced by repository size, from €890 for a Readiness Check on a small codebase up to €8,000 and above for multi-repository or regulated systems. The takeover itself is then quoted from the audit’s own findings as a fixed scope, so you see the price next to the reasons for it rather than before them. If you want supervision of your own team instead of a full takeover, that is a monthly engagement and costs considerably less.
Usually not, and we argue against it by default. A rewrite throws away years of accumulated business rules that nobody has written down, including the ugly ones that exist because a real customer complained. We rewrite a component when the audit shows it is cheaper to replace than to repair, and we say which components those are before any work starts.
We give you that date during the audit, before you sign anything, because it depends entirely on what we find – a documented codebase with tests is a different proposition from one with neither. What we will not do is start shipping features into a system we don’t yet understand, which is the single most common way a takeover turns into a second rescue.