Someone Else Started It. We Can Finish It.
Stalled builds, absent developers, code nobody can explain. We start with a fixed-price audit and an honest verdict — including the verdict that a rewrite would be the wrong move — before anyone touches a line.
- Fixed-price audit, no open-ended diagnosis
- Written verdict whether or not you hire us
- Accounts moved back into your name
The Situations We Get Called Into
None of these are unusual. Most of them are recoverable, and the recoverable ones cost less to recover than you are probably fearing.
Diagnose, Decide, Stabilise, Then Build
Taking over someone else's code in the wrong order is how a rescue becomes a second failure. This is the order we use, and we do not skip a step because a deadline is close.
1. Access and inventory, before anything technical
The first blocker is almost never the code. It is a Google Play account registered to a freelancer, a domain renewing on somebody's personal card, or a cloud root login nobody has. We list every account, repository, service and credential the product depends on, mark which ones you control, and start recovery on the ones you do not. This stage often takes longer than the audit itself, so it begins on day one rather than surfacing in week three.
2. Fixed-price code audit
A senior engineer reads the codebase, builds it, runs it, and inspects the infrastructure behind it. The fee is agreed before we start and does not move. You get a written report rather than a verbal impression, plus a call to walk through it. Typical turnaround is five to ten business days.
3. The verdict, in writing
Continue, partially replace, or rewrite — with the reasoning, the cost of each route, and what you give up by taking it. If the honest answer is that the code is fine and the previous developer simply ran out of runway, we say that, and the recommendation is far cheaper than you expected.
4. Stabilisation
Before any new feature: stop the crashes, restore a repeatable build, get the app deploying from a pipeline rather than one person's machine, patch anything with a known vulnerability, and add error tracking so the next problem is visible in minutes instead of discovered in a store review. This is a defined, separately priced stage, and you are allowed to stop at the end of it.
5. Forward work
Only now does the roadmap restart. Two-week sprints, a working demo build at the end of each, and modernisation folded into feature work rather than run as a separate project nobody can see the value of. From here it looks like any other engagement — fixed price if the scope is clear, a dedicated team if the work is ongoing.
What the Audit Actually Inspects
Every finding is sorted into one of four buckets, because a list of two hundred undifferentiated problems helps nobody decide anything.
Stops You Shipping Today
The build fails, signing certificates have expired, a dependency has been pulled from its registry, credentials are sitting in the repository, or the app crashes on the current OS release. Nothing else matters until these are cleared — and they are usually among the cheapest things on the list to fix.
Will Cost You Later
A data model that will not survive growth, business rules duplicated across five screens, no separation between the app and the service it talks to, an authentication scheme that cannot express the roles you need next. Real problems, expensive to ignore, and none of them need fixing all at once.
Genuine, Not Urgent
Inconsistent naming, missing tests on code that has been stable for a year, dated libraries that still work, screens that drifted from the design. We list them so nothing is a surprise later, then recommend leaving most of them alone until you are in that file for another reason.
Keep It
The section nobody else writes. Most inherited codebases contain work that is perfectly good, and we name it explicitly so it does not get thrown out in a burst of enthusiasm for starting clean. This is the single biggest reason our verdicts come in cheaper than rewrite quotes.
Code & Architecture
- Does it build from a clean checkout on a clean machine
- Dependency health, licences and abandoned packages
- Data model, migrations, and behaviour at ten times the load
- Where the business logic actually lives
- Test coverage on anything touching money or personal data
Security & Data
- Secrets, API keys and tokens committed to the repository
- Authentication, session handling and password storage
- Whether one user can read another user's records
- Transport security and certificate expiry dates
- Backups: whether they exist, and whether they restore
Operations & Ownership
- Who legally holds each account and store listing
- Deployment: a pipeline, or one laptop with the right setup
- Monitoring, logging and crash reporting, if any
- Cloud spend, and anything running that nobody uses
- Documentation a new engineer could genuinely start from
Rewriting Is Usually the Wrong Answer
It is also the answer most developers give an inherited codebase. It is worth understanding why before you accept it.
Why “rewrite it” is the default you hear
- Reading someone else's code is slow and unglamorous; writing new code is fast and enjoyable
- A rewrite is a far bigger invoice than a remediation plan
- Estimating a rewrite is easy, because there is no existing behaviour to account for
- If the rewrite overruns, the old codebase gets the blame
- Nobody has to admit they could not follow what was already there
What a rewrite actually costs you
- You pay a second time for every feature you already bought, including undocumented edge cases users rely on
- You ship nothing at all until the new version reaches parity, which is usually months
- The old system still needs maintaining during the rebuild, so you fund both
- Years of accumulated bug fixes, each written because a real user hit a real problem, are quietly discarded
- The replacement is designed by people who do not yet understand the domain
When we recommend continuing
It builds, or can be made to build. The data model is sane even if the code around it is not. The framework still receives security updates. The problems are concentrated in a handful of files rather than smeared across everything. That describes the clear majority of what we audit, including codebases that look alarming from the outside.
When a rewrite is genuinely right
The platform underneath no longer receives security updates and cannot be upgraded in place. The source is incomplete or partly lost. There is a licence or vendor lock-in you cannot live with. Or what you need next is so different from what exists that you would be replacing nearly all of it anyway. We do say this when it is true. We just do not say it by default.
What We'll Tell You Even If You Don't Hire Us
The audit report is yours. It is written so another developer can act on it without us, because the entire point of paying for a diagnosis is that the diagnosis is independent of who performs the treatment.
- If the existing code is fine and someone quoted you a rewrite, we tell you it is fine
- If the remaining work is too small to justify an agency, we say hire one contractor
- If you are close enough to done that finishing it in-house is realistic, we say that
- Security findings are written up in full, immediately, whatever you decide next
- The account and credential recovery map is yours regardless of who does the work
There is a commercial reason for this as well as an honest one. A report that only makes sense as a sales document is not a report, and a founder who has already been burned once can tell the difference in about a page.
Getting Your Accounts and Code Back
Recovering access is an administrative and legal job more than a technical one, and it runs in parallel with everything else.
List every account
Source control, cloud hosting, database, app stores, payment processor, email sender, analytics, error tracking, domain registrar, DNS, push certificates, and every third-party API with its own billing.
Ask plainly first
Most handovers are uncooperative rather than hostile. A short, specific, unemotional written request listing exactly what is needed settles more of these than founders expect. We draft it if you want.
Use the platform routes
Where that fails, each platform has an owner-verification path. They typically want incorporation documents, the payment method on file, proof of domain control or a matching business address. We tell you which evidence each one asks for.
Rebuild what is truly lost
Occasionally something is unrecoverable — a store listing under a personal developer account, for instance. We price re-registering and republishing it honestly, including what you lose, such as existing ratings.
Once recovered, everything moves into accounts you own, with us added as a collaborator rather than the owner. That is how we set up every new project as well — see ownership and IP.
Replace the Engine Without Stopping the Car
Legacy work goes wrong when it is run as a separate, invisible project. We do it in slices, alongside work you can see.
One boundary at a time
Pick a single seam — authentication, payments, one screen, one service — and replace only what sits behind it, leaving everything else calling the same interface. Each slice ships on its own and can be reverted on its own if it misbehaves in production.
Old and new run side by side
The replacement sits behind a switch alongside the original until it has proven itself on real traffic. If the new path misbehaves you flip back the same afternoon, rather than scheduling an emergency rollback weekend.
Paid for by the work around it
Modernisation gets attached to features you actually want. Rewriting the billing module because you need a new plan type is a business decision anyone can approve. Rewriting it because it is untidy is a budget line that gets cut in month two, and rightly so.
Where It Goes From Here
How the work continues is a separate decision from the rescue itself. Compare the options on how we work.
Maintenance & Support
Stabilised and handed back, but somebody still needs to watch it. A monthly retainer covers patching, monitoring and small fixes.
Learn moreDedicated Team
A long backlog and a roadmap that keeps moving. Named engineers on a monthly basis rather than a fixed scope.
Learn moreFractional CTO
You have developers but no way to judge their work. We review, oversee and keep the technical decisions honest.
Learn moreRescue and Takeover Questions
Do we have to hand over the code before you will quote the audit?
No. We can scope an audit from a read-only repository invite, a zip of the source, or a screen share if that is genuinely all you have left. We cannot give you a verdict without reading the code, but we do not need ownership of anything in order to read it, and a mutual NDA can be in place first.
How long does a code audit take?
Five to ten business days for a typical single mobile app or web application. A system with several services, a large database and an existing user base takes longer, and we tell you which it is before you pay. You get the written report and a walkthrough call at the end either way.
Is a rewrite cheaper than fixing what already exists?
Almost never, and that is the honest answer even though a rewrite is the more profitable job for us. A rewrite restarts every feature you have already paid for, including the small behaviours nobody wrote down, and produces nothing you can ship until it is finished. We recommend one only when the code cannot be made safe, cannot be built and deployed at all, or sits on a platform that no longer receives security updates.
What if the previous developer will not hand over the accounts?
Most platforms have a documented recovery route for the legal owner of the business. Apple, Google Play, Stripe, the major cloud providers and the domain registrars all do, and each wants a different combination of incorporation documents, payment records and domain control. We tell you exactly what each one needs. Where something is a genuine dead end we say so, and price what rebuilding that piece costs.
Can you just stop the crashes and leave the rest alone?
Yes. Stabilization is a separate stage precisely so it can be the last stage. Plenty of owners want the crashes stopped, the build pipeline working again and the documentation written, and then want to stop spending. We are happy to hand it back at that point with everything written down.
What does the audit cost?
For most single applications the audit is a fixed fee in the region of $1,500 to $4,000, set once we know how large the codebase is and how many moving parts it has. It is agreed before we start, so the diagnosis never turns into an open-ended bill. If you go on to hire us for the remediation work, we credit the audit fee against the first invoice.
Send Us Whatever You Have Left
A repository link, a zip file, or just the story so far. We will tell you whether it is worth saving — and we will tell you if it is not.