How to Audit a Software Project Before Hiring a New Agency

You're about to hand your software to a new team. Before you do, you need an honest picture of what you're handing over, because the next agency's estimate is only as good as their understanding of what already exists.

This matters more than people realise. Without an assessment, one of two things usually happens. Either a vendor quotes low, discovers the real state of the code in week three, and comes back for more money. Or they quote for a full rebuild to cover themselves, and you pay for work you didn't need.

A proper audit gives you a specification for the take-over. Here's what it should cover, and what the answers mean.

Who should run it

Not the team that wrote the code, for obvious reasons. Not the agency pitching to take it over either, ideally, though in practice many take-overs start with a paid audit from the team you're considering.

That's workable if two conditions hold: the audit is fixed-price and paid, and the written report is yours to keep, usable with any vendor. A free audit is a sales document. A report you can't take elsewhere is a hostage.

Expect $2,000–$5,000 for a proper audit depending on the size of the system, and one to two weeks. Compared with a six-figure build decision, that's cheap insurance.

The eight areas to cover

1. Access and ownership

Before anything technical: who owns what? The repository, cloud accounts, domain, app store listings, and every third-party service. If any of these are in a departed developer's name, recovering them comes before all other work. Nothing else is safe until you hold the keys.

Red flag: anything critical registered to a personal account you don't control.

2. Can it be built and deployed?

The first real test. Can a new engineer, from a clean machine, check out the code, install its dependencies, run it locally, and deploy it? Many inherited projects fail here.

What good looks like: documented setup, a working build, a repeatable deployment. Red flag: the only way to deploy is one person's laptop, or nobody knows how the live version was produced.

3. Security

The area that most often turns up something urgent, and worth fixing before anything else.

• API keys and passwords committed into the code or exposed to the browser
• Access rules that let one user read another user's data
• Endpoints that do what they're told without checking who's asking
• Admin pages hidden in the interface but reachable by URL
• Dependencies with published vulnerabilities
• Personal data stored or logged where it shouldn't be

Red flag: any of these on a live system with real customers. This is week-one work, not roadmap work.

4. Data and backups

Is the data model sensible for your business, and can you recover from disaster?

The audit should confirm backups exist, and that someone has actually restored one to a test environment. An untested backup is a hope, not a plan.

Red flag: no backups, or nobody can say when one was last restored successfully.

5. Code quality, judged usefully

Ignore opinions about style. The question that matters is whether a competent engineer can change one thing without breaking three others.

Practical signals: is the same logic duplicated in several places? Are there tests on the flows that make money? Is it consistent enough that patterns are predictable? Are dependencies current enough to still receive security updates?

Red flag: no tests anywhere near payments, authentication, or data handling.

6. What's actually finished

Map the claimed feature list against reality: working, half-built, or never started. Test the important paths yourself as a real user.

This is frequently the biggest surprise. "Ninety percent done" often means the screens exist and the logic behind them doesn't.

7. Architecture and scale

Will it hold up at the volume you expect in the next year or two? Where are the bottlenecks? Are there design decisions that would be expensive to reverse later, particularly in the data model?

Be wary of both extremes here: a system that will fall over at 500 users, and one over-engineered for a scale you'll never reach.

8. Running costs and dependencies

What does it cost to run each month, and what does it depend on? Cloud bills, third-party services, per-use fees for email, SMS, or AI. Any service that's no longer maintained or is scheduled for retirement is a future migration you should know about now.

Red flag: services paid on a former developer's card, which will lapse without warning.

What the report should contain

A useful audit report gives you:

• A part-by-part verdict, each marked keep, fix, or rebuild, with the reasoning. Not one sweeping judgment on the whole system.
• Prioritised findings, separating "fix this week" from "worth improving eventually".
• Two costed options where a rebuild is on the table: fixing versus rebuilding, so you can compare.
• Evidence you can check. "The code is bad" is an opinion. "User records can be read by any signed-in account, here's the request that proves it" is a finding a second vendor can verify.
• A realistic estimate to finish, based on the actual codebase rather than the original plan.

If a report reads as one long argument for a rebuild with no specifics, treat it as a proposal, not an assessment. Our guide to rewriting versus rescuing a codebase covers how to tell the difference.

Questions to ask the vendor doing the audit

1. What access do you need, and will you sign an NDA first? (Read-only access should be enough to start.)
2. Is the price fixed before you begin?
3. Do I keep the report, and can I use it with another vendor?
4. Will you give a verdict per component, or one overall?
5. If parts are sound, will you say so?
6. Who does the audit: the engineers who'd do the work, or a sales team?

That last question matters more than it sounds. An audit written by someone who won't touch the code tends to be generic.

What to do with the answers

Once you have the report:

1. Fix anything urgent first, especially security and anything losing customers today.
2. Recover any access still outside your control.
3. Get the remaining scope re-estimated against what actually exists.
4. Then decide on the vendor, with a clear picture on both sides. You'll get better estimates, because a vendor quoting against a known codebase doesn't need to pad for the unknown.

Getting one done

Our software project rescue service starts with exactly this: a fixed-price take-over audit, $2,000–$5,000 depending on system size, delivered in one to two weeks as a written report with a fix-or-rewrite call per component. It's yours to keep whether or not you work with us.

If your app was built with Lovable, Bolt, Replit, or another AI tool, the checks are different, with data access rules and payment handling the usual problem areas: see AI-built app rescue.

And if you're here because your developer has gone quiet, start with what to do when your software developer disappears.