System map
Architecture, data flow, dependencies, environments, and operating ownership.
Independent technical review
Find the technical risk before it becomes the roadmap.
I review the product, architecture, codebase, delivery path, and operating assumptions behind a specific decision. The result is a concise evidence pack: what is sound, what is risky, and what to do next.
Direct answer
What should a technical audit include?
A useful technical audit answers a decision, not merely a checklist. It examines architecture, code quality, data, security, dependencies, deployment, observability, delivery habits, and ownership only as far as they affect the question in scope. Each finding should cite evidence, explain consequence and uncertainty, and end with a proportionate recommendation.
When this helps
Audit before a rewrite, investment, critical release, handover, or senior hire.
- A founder cannot tell whether delivery problems come from scope, architecture, code, or ownership.
- A buyer or investor needs an independent view of technical risk.
- A team is considering a rewrite, migration, or major vendor commitment.
- A critical launch exposes reliability, security, or operating concerns.
- A product is changing hands and the new owner needs a trustworthy baseline.
What the work covers
The depth follows the decision and access available.
A focused audit states what was reviewed, what could not be verified, and which conclusions remain conditional.
Code and delivery
Representative code, tests, CI/CD, release process, and change risk.
Risk review
Security, privacy, resilience, lock-in, cost, and single points of failure.
Action plan
Ranked findings, quick stabilisation, deeper work, owners, and decision gates.
Compare the options
An audit should reduce uncertainty, not automatically sell a rebuild.
| Engagement | Question answered | Output |
|---|---|---|
| Technical audit | What is true and what should happen next? | Evidence, risk, and priorities. |
| Discovery | What product should be built and for whom? | Scope, users, flows, and delivery plan. |
| Penetration test | Can defined security boundaries be exploited? | Security findings from specialist testing. |
| Implementation | How will the chosen change be delivered? | Working software and operating handover. |
How the work runs
Scope the question, collect evidence, test findings, decide.
Define the decision
Agree on the event, concern, access, constraints, and stakeholders.
Inspect evidence
Read documentation, code, infrastructure, data paths, and delivery history.
Challenge conclusions
Separate verified facts, reasonable inference, unknowns, and urgent risk.
Review the plan
Walk through priorities, trade-offs, owners, and what needs deeper specialist work.
Relevant work
Reviews informed by years of hands-on delivery.
I have worked across Rails systems, full-stack products, AI workflows, smart contracts, launch infrastructure, and operational handovers. The audit stays grounded in what teams can actually change.
FAQ
Questions about a technical audit.
How long does an audit take?
A focused product or decision audit can often be completed in one to three weeks. The timeline depends on system size, access, interviews, and whether specialist security testing is required.
Do you need full repository access?
Not always. The access must match the question. Any limit is recorded so a reader can distinguish verified findings from conditional conclusions.
Is this a security audit?
It can review security posture and obvious risks, but it is not a substitute for a specialist penetration test, compliance assessment, or formal smart-contract audit when those are required.
Will you recommend a rewrite?
Only when evidence shows staged repair or replacement is less responsible. Rewrites carry product, migration, and delivery risk and should not be the default.
Can you help implement the recommendations?
Yes, if the work fits, but implementation is a separate decision. The audit remains usable by your current team or another provider.
One decision in scope
Tell me what changed, what worries you, and which decision depends on the answer.
I will propose an audit boundary that is small enough to finish and broad enough to be useful.
Scope the audit