A read-only look at your codebase, ranked by severity.
We read the code. We don't touch it. What you get is a severity-ranked report, every finding reproducible, and a roadmap whoever fixes it can follow.
The deliverable is a document, not a pull request.
People commission an audit at moments of exposure. An acquisition is about to close, a new CTO inherited a repo nobody can explain, or a build keeps failing in ways the team can't name. In all three, the expensive mistake is spending money before you know what you hold.
So this is a read-only review with a fixed scope agreed up front. We take repository access, run static analysis, then read the code by hand where the tooling is blind: architecture, data model, security posture, performance and accessibility. Nothing we find gets changed.
The output is a severity-ranked report with reproduction notes, a risk register, and a remediation roadmap written so any competent team can execute it. Including one that isn't us. That's the point of a fixed-scope engagement — the findings have to survive being read by somebody with no reason to hire us.
We're buying a company and can't judge the code.
Technical due diligence written for a deal room: what's solid, what's debt, what's a liability, and the cost shape of each. Ranked, so your lawyers can read it too.
Our new CTO inherited a repo nobody can explain.
An architecture review that maps what exists before anyone argues about what's next. Modules, data flow, dependencies and the decisions that got quietly baked in.
The site fails audits and nobody knows why.
One pass across performance, accessibility and security, with each finding reproducible on your own machine. No vague scores, no plugin recommendations.
We don't want a vendor grading their own homework.
We're read-only here by design. The report names problems, not our next invoice, and the roadmap is written so a different team can execute it.
Scope, spelled out.
Architecture review
Modules, boundaries, data model and coupling, mapped against what the system is actually asked to do today.
Security posture pass
Authentication, input handling, secrets, dependency versions and server configuration, read against what the logs already tell us.
Performance and Vitals
Query counts, render cost, payload weight and caching, measured rather than guessed, with the slowest paths named.
Accessibility audit
Keyboard paths, semantics, contrast and labelling, checked by hand where automated tooling reports a clean pass it hasn't earned.
Severity-ranked report
Every finding with impact, effort, evidence and reproduction notes, ordered so the first ten items are the ones worth arguing about.
Risk register
The things that will hurt you later, with likelihood and blast radius, in a table you can hand to a board or an investor.
Remediation roadmap
Sequenced work with dependencies, so whoever picks it up knows what to fix first and what safely waits a quarter.
What actually happens, week by week.
Scope and access
What's in, what's out, and what we get to see. Read-only credentials, agreed in writing before we start.
Static pass
Tooling first: linters, analysers, dependency scans, and whatever the error logs have been saying.
Manual pass
Then we read it. Architecture, data model and the paths the tooling can't see, by hand, module by module.
Rank and evidence
Each finding gets impact, effort and steps to reproduce, then a severity order we can defend line by line.
Walkthrough
A call on the findings, then the roadmap: sequenced, dependency-aware, and executable by a team that isn't us.
The tools we actually use here.
We audit in the stacks we've shipped in, because a reviewer who's never maintained the thing writes findings nobody can act on. Outside this list we'll say so before you pay.
Deliverables, outcomes and who this is for.
- Fixed scope and access agreement
- Severity-ranked findings report
- Reproduction notes per finding
- Risk register for the board
- Sequenced remediation roadmap
- Findings walkthrough call
- You know what you're holding
- A ranked list, not a wall of text
- A roadmap any team can execute
- Nothing in your repo was changed
Investors, acquirers and incoming CTOs who need the state of a codebase on paper before they spend on it.
What we've read, and what a report can't tell you.
RF MAX: a production Shopify theme
We audited the live rfmax.com theme across architecture, CSS, accessibility and performance — a live store selling through the theme we were reading, not a checklist over a staging copy. The findings covered template structure, stylesheet debt, keyboard and semantic gaps, and where the theme spent its time.
Filestack: reading the error logs
Before anyone patches a plugin, read what the server already knows. For Filestack we worked through Apache error logs to find what was actually failing in production. That trail turned an intermittent, unexplained failure into named security problems with evidence attached.
Architecture and documentation planning
Architecture and documentation planning is part of the same offer: mapping an existing architecture, writing the documentation nobody wrote, and sequencing a refactoring roadmap your own developers can execute. Same discipline, same artifact. A document that outlives the conversation.
What an audit can't tell you
A read-only pass can't price your roadmap to the dollar, and it can't find a fault that only appears under load we never generate. We mark those as unknowns with the test that would settle them, rather than dressing a guess as a finding. The register says what we checked and what we didn't.
Questions we get on the first call.
We scope and price it per codebase, because a single plugin and a decade-old platform aren't the same read. What you receive is fixed: a severity-ranked report with reproduction notes, a risk register, a sequenced roadmap and a call to walk through all of it. The scope is agreed before you pay.
No. You paid for the answer, and 'healthier than you feared' is a valuable answer, especially in a deal room. There is also always a ranked list — the interesting question is whether the top item is boring, not whether the list exists. If we can't fill a risk register, we'll write that down and you can quote us on it.
The repository is the floor. Read-only production access, or a staging clone plus recent error logs, is what turns a code opinion into evidence — you can't measure query counts or render cost from a git checkout. If access is impossible, we scope narrower and mark the untested parts as untested.
Not inside this engagement. The audit is read-only, and a reviewer who is also quoting for the repair has a quiet incentive to find more. The roadmap is written so your team, or another vendor, can execute it. Hire us afterwards if you want, on a separate scope and a separate price.
Yes, that's what the format is for. Findings carry impact, effort and evidence, the register reads like a register, and nothing depends on having sat in our call. Tell us before we start if it's going into a deal room, and we'll keep the language plain enough for the non-engineers reading it.
More in Agency / White-Label.
Find out what you're holding, before you spend.
Thirty minutes to agree scope and access. Bring the repo size, the stack, and the decision the report has to support.