Why Independence Matters
Engineering teams are usually the wrong people to assess their own codebase. Not because they aren't competent (they're often the most competent), but because they're inside the system. They know which parts they trust, which parts they avoid, which warnings they've decided are safe to ignore, and which shortcuts were taken under pressure. An outside reviewer sees the codebase as it actually is, not as it looks from inside.
For audit, rescue, and due diligence work the buyer is hiring judgement, and the credentials are part of the deliverable. A board hearing “the codebase is sound” from a former CTO with 20+ years in regulated systems carries different weight than the same sentence from the team that wrote the code. That asymmetry is the work.
Four Situations We're Built For
You just inherited a codebase you didn't build
You took a CTO or VP Engineering role 0–6 months ago. You suspect the codebase is worse than you were told, and you're being asked to commit to a roadmap before you can defend the engineering you'll need to ship it. We perform an independent assessment of what you actually own (architecture, code quality, security posture, operational maturity, dependency risk, engineering process) and produce a prioritised remediation plan with effort estimates you can take to a CEO or board.
Why this lands: the assessment is independent. A remediation budget defended on the back of an outside report is much easier to win than one defended on the new CTO's gut feeling.
You're heading into a funding round or acquisition
Series B+, late-stage, or acquisition talks. Investors and acquirers will run technical due diligence on you whether you're ready or not. The diligence report is going to land on a partner's desk and shape the term sheet, the valuation, or whether the deal happens at all. Commissioning your own audit 8–16 weeks before the diligence window means you find the issues first, fix the easy ones, and have honest, prepared answers for the rest.
The deliverable is two-tiered: an engineering-facing report your team can act on, and an executive-facing summary you can hand to investors as part of the data room. A clean diligence report is one of the cheapest ways to de-risk a deal.
You're acquiring or investing in a technology company
You're a PE firm, strategic acquirer, VC, or corporate development team. The deal is moving inside a 2–4 week diligence window and you need a credentialed independent engineer to assess the target: the code, the architecture, the operational posture, the team, and the risks behind the deal. Reports are tailored to the audience, with executive-facing summaries that an investment committee can actually use, and engineering-facing detail where the deal needs it.
Common findings that change deal terms: hidden technical debt that materially affects the post-close roadmap, single-points-of-failure (a key engineer, a key vendor, an undocumented system), security and compliance gaps in regulated industries, and architectural decisions that constrain the integration thesis.
Production is unstable and the team is stretched
Performance regressions that have crept up over months, mysterious bugs that have resisted internal effort, systems falling over under load, the long shadow of team turnover where the people who built the load-bearing parts have left. We engage on a triage basis: stabilise the immediate problem first, then circle back to fix the underlying cause properly.
Most hard bugs become tractable once someone experienced stops trusting the team's mental model and looks at what the system is actually doing: logs, metrics, traces, and the code itself. The skill is knowing which evidence to gather and what it really tells you.
What an Audit Covers
- Code quality and maintainability. Readability, structure, test coverage, documentation, the things that determine whether the next ten years of changes are easy or expensive.
- Architecture and design. Does the system as built make sense? What is load-bearing? What is at risk? What would a re-platforming actually involve?
- Security posture. Common vulnerability classes, secrets management, authentication and authorisation, dependency hygiene, the OWASP-relevant categories that show up in code review.
- Operational characteristics. Observability, deployment, incident response readiness, recovery posture, how the team would know if something was wrong.
- Vendor and dependency risk. Third-party services, open-source dependencies, and the single-points-of-failure that nobody has thought about lately.
- Engineering process. Version control discipline, code review, CI/CD, testing practice, on-call structure. Process gaps show up as production incidents later.
- Team and knowledge concentration. Where the load-bearing knowledge sits, what happens if a key engineer leaves, what's documented and what's only in someone's head.
Note on security scope. We perform security-focused review as part of an audit, but we are not a dedicated penetration-testing firm. Where the engagement requires formal security assessment with controlled exploitation, we recommend partnering with a specialist firm and we're happy to scope and oversee that engagement.
How Engagements Run
Codebase Audit (1–4 weeks)
A focused code review on a small codebase runs about a week. A full technical audit covering architecture, code, operations, security, and process is two to four weeks depending on system size. Output is a written report: executive summary up front, detailed findings and remediation guidance behind. Optional live presentation to the leadership team or board.
Codebase Rescue (variable, triage first)
Most rescues start with a small triage block (typically eight hours) to understand the problem before committing to scope. By the end of triage you have either a fix, a clear remediation plan with effort estimate, or a recommendation that this isn't the right shape of engagement. All three are useful outcomes. Out-of-hours work uses the published rate multipliers, which matters when production decides to fail at midnight on a Saturday.
Technical Due Diligence (2–4 weeks, time-bound to the deal)
Compressed timelines, two-audience reports, and full coordination with deal counsel and the rest of the diligence stream. Engagements run on a fixed scope and fixed timeline. Where the deal calls for a follow-up read on a specific concern flagged during diligence, that runs as a separate short engagement.
Pricing
All audit, rescue, and due diligence engagements use the standard $250/hr base rate, billed in 15-minute increments. Prepaid blocks of 8, 20, and 40 hours are available at increasing discounts and never expire. Out-of-hours work uses the published rate multipliers. There are no surprise line items at the end of an engagement.
Indicative engagement sizes:
- Focused code review: one week, ~$8–15k
- Full technical audit: two to four weeks, ~$20–60k
- Pre-acquisition technical due diligence: two to four weeks, ~$15–40k
- Codebase rescue: varies; triage first, then scoped against the diagnosis
For ongoing oversight (a recurring quarterly audit, sustained involvement during a high-stakes build, or senior cover during a CTO transition) this often combines well with fractional technical leadership.
Frequently Asked Questions
How long does a codebase audit take?
A focused code review on a small codebase typically runs one week. A full technical audit covering architecture, code, security, operations, and engineering process is usually two to four weeks depending on system size. Pre-acquisition technical due diligence is often compressed to two to three weeks to fit the deal window.
What does the deliverable look like?
A written report tailored to the audience. Executive-facing audits include a top-line summary, key risks, and prioritised recommendations. Engineering-facing reports include detailed findings, code-level evidence, and remediation guidance. We can also present findings live to a board or investment committee where useful.
Can you do this in an emergency?
Yes. Urgent rescue engagements start with a short triage: typically a half-hour call and an eight-hour triage block to understand what is actually breaking before scope is committed. Out-of-hours work uses the published rate multipliers.
Do you do pre-diligence audits and acquirer-side due diligence?
Both, but never both sides of the same deal. Pre-diligence audits help a founder or CTO surface and fix issues before investors find them. Technical due diligence on behalf of an acquirer or investor produces an independent assessment of a target. The engagements are similar in shape but the audience and emphasis differ.
What kinds of systems can you audit?
Web platforms, APIs, data pipelines, cloud infrastructure, mobile applications, firmware on microcontrollers, embedded device software, and end-to-end IoT systems where the codebase spans device firmware and the cloud platform that manages it. Healthcare and HIPAA-regulated systems are a particular fit given the founder's background.