Taking over an existing software project

The agency stopped answering. The developer who built it has left. The product works, but nobody is willing to change anything in case it breaks.

This is a normal week for us. Picking up software other people wrote is a large part of what we have done for years, often on systems with no documentation, no tests and no one left to ask.

We start with an audit, always, before anyone commits to anything. You get a written picture of what you actually own — what is sound, what is fragile, what is a genuine risk — and an honest view of what it would take to maintain it, improve it, or in rare cases replace it. If the right answer is that you should keep your current arrangement, we will tell you that too.

What We Do

Not every situation needs all of this. The audit decides which of it applies.

  • Codebase audit and risk report

    A structured assessment, not an opinion. Dependency and licence state, how far behind the platform and framework versions are, where the security exposure is, what test coverage exists, how the data is modelled, and which parts of the system are genuinely understood versus which parts everyone avoids. You get it in writing, with risks ranked by what they would actually cost you.

  • Handover and knowledge capture

    Where the previous team is still reachable, there is a narrow window to extract what is in their heads. We run that handover properly — architecture, deployment, credentials, the undocumented decisions and the known workarounds — and write it down while it is still available.

  • Getting it buildable and deployable

    More often than people expect, the first real problem is that nobody can run the thing. Environment, build, deployment and secrets, reconstructed and documented, so that a change can be made safely at all.

  • Stabilisation

    Before improving anything, stop the bleeding. The crashes, the data integrity issues, the job that silently fails every Tuesday. This is usually where the first month goes and it is where the relief comes from.

  • Dependency and platform upgrades

    Framework versions, language runtimes, libraries that are years out of support. Done incrementally, with the system running, rather than as one large upgrade that holds the product hostage for a quarter.

  • Refactoring with a reason

    We do not rewrite code because we would have written it differently. We refactor where it is blocking something — a feature you cannot ship, a bug that keeps returning, a part nobody can touch safely. Everything else stays as it is.

  • Re-platforming and phased rewrite

    Sometimes the honest answer is that part of the system has to be replaced. When that is true we do it in phases, with the old system running alongside, and with a route back at every step. A single-switch rewrite is the most expensive and most dangerous option available, and it is right far less often than it is proposed.

  • Inherited AI-generated code

    A newer version of a familiar problem. A product was built fast with AI assistance, it demonstrated well, and then it met real users. What we typically find is that the visible layer is fine and the parts underneath were never designed — authentication and session handling, the data layer, anything concurrent, error handling, and behaviour on a poor connection. The audit covers this the same way it covers any other inherited codebase: find out what is really there before deciding what to do about it.

When Teams
Come to Us

  • The agency has gone quiet

    Slow replies, then no replies. You may not have the code, the credentials or the deployment access. We have done this recovery before, including the awkward parts.

  • The only person who understood it has left

    One developer, no documentation, and a product the business depends on. The first job is making it safe to change at all.

  • It works but it cannot be changed

    Every release is frightening. Small features take weeks. The team has started routing around the code rather than through it. That is compounding cost, and it has a fixable cause.

  • It was built fast and now it has users

    An MVP, a prototype, or something assembled quickly with AI assistance, now carrying real traffic and real data. The question is which parts to keep.

  • Due diligence before you buy

    You are acquiring a company or a product and want to know what the software is actually worth before you sign. The audit works the same way and the report is written to be read by people who are not engineers.

Agency Gone Quiet?

Send us what you have — a repository, a login, or just a URL. We will tell you what we find and what we think it would take, before anyone signs anything.

Let's discuss

How We Work

Code, environments, credentials, deployment, third-party accounts. Often the hardest stage, and we help you reclaim what is missing.

Structured review of the codebase, dependencies, data and infrastructure. The output is a written risk report, ranked by cost to you.

We walk you through what we found and what the options are, including the option of changing nothing. You decide before we commit to a plan.

The urgent things first — crashes, security exposure, data integrity, anything actively losing you money.

Upgrades, refactoring and new work, in the order that unblocks the most.

Moves onto a support retainer once the system is somewhere sensible. See application support.

What We Work With

Taking over a codebase means working in whatever it was written in, not whatever we prefer.

  • PHP, including Laravel and older framework-free codebases
  • Node.js and TypeScript, including NestJS
  • Python, including Django
  • WordPress, from custom themes to heavily modified installs
  • React and React Native on the client side
  • Relational databases, including schemas that grew rather than were designed
  • Deployment and infrastructure as we find it, documented as we go

If a system is in something we do not work with, we will say so at the audit stage rather than after you have paid for one.

What the Audit Gives You

The audit is a deliverable in its own right, and it is yours whether or not you go further with us.

  • A written risk report, with issues ranked by business impact rather than by how much they annoy an engineer
  • An honest assessment of what is sound and worth keeping
  • The security and dependency exposure, stated plainly
  • What it would cost to maintain the system as it is
  • What it would cost to get it to where you want it, broken into phases you can start and stop
  • A recommendation, including when that recommendation is to leave it alone

Industries We Work In

Inherited systems turn up everywhere. The ones we see most are construction and the built environment, healthcare platforms, booking and scheduling systems, and travel and mobility.

How We
Work Together

  • Audit only

    A fixed engagement ending in the written report. No obligation to continue, and the report is useful to whoever does the work.

  • Stabilisation project

    A defined piece of work with a scope that comes out of the audit, priced per module.

  • Ongoing team

    Developers and QA taking ownership of the system and working to your roadmap.

  • Support retainer

    For systems that mainly need keeping healthy rather than extending. Starting from five hours per month. See
    We price every engagement individually. There are no packages, because inherited systems never arrive in the same condition twice.

Questions We
Get Asked

  • No, and that is for your protection more than ours. Anyone willing to quote a takeover without looking at the code is guessing, and the price they give you is a number they will have to revisit. The audit is what makes the estimate real.

  • That is a useful answer, not a failure. Bad is also not one thing — a messy codebase that works and can be changed safely is in better shape than a tidy one with no tests and a data model that will not hold. The report tells you which kind you have and what each path costs.

  • Often yes. Recovering access from a previous agency is part of this work and we have done it before. What is recoverable depends on where things are hosted and what is in your contract, and that is one of the first things the audit establishes.

  • No. A full rewrite is the most expensive and most dangerous option available and it is right far less often than it is proposed. We refactor where something is blocking you and leave the rest alone. Where a rewrite is genuinely the answer, it happens in phases with the old system still running.

  • Yes. That adds store access, signing certificates and release management to the handover, and those are the pieces most often missing. See mobile app development.

  • Same process. We audit it like any other inherited codebase rather than treating it as a special category. In practice the pattern is consistent enough to know where to look first: authentication, the data layer, concurrency, error handling, and what happens on a bad connection.

  • The audit is the first deliverable and it is quick. Stabilisation follows it, and that is usually where the visible relief comes from. We will not give you a timeline for the whole thing before the audit, because that number would be invented.

Related Services

Let’s talk about your project

welcome@ideus.biz