Mandate 02 · Audit & improve

Every angle, not just the fast one.

An audit is not a performance report. We take the system apart across design structure, cybersecurity, the quality of its models and its behaviour under load, quantify each finding, and land the fixes in whatever language the code is already written in.

Audit specLive
Duration
3 weeks · fixed scope
Input needed
repo access + a load profile
Week 1
instrument & reproduce
Scope
structure · security · models · performance
Week 2
ranked findings + prototypes
Week 3
merged fixes + CI gates
Output
report · pull requests · benchmarks

No rewrite recommendation unless the numbers demand one

Process

Three weeks, four stages.

01

Reproduce

Your load, replayed on a rig we can profile.

02

Rank

Every finding carries an effect size and an effort figure.

03

Land

Fixes as small PRs, benchmarked individually.

04

Lock in

Thresholds in CI so the gain can't silently rot.

You keep everything: rig, benchmarks, traces and notes

Coverage

Six dimensions, scored before and after.

Each dimension is scored against evidence we can show you: traces, threat models, back-tests, benchmarks. Nothing in the report is an impression.

Audit coverage · anonymised engagement4387 composite
StructureSecurityModelsPerformanceDataOperability
as found after remediation
  • Structure4482

    Module boundaries, coupling, dead paths, migration risk and the seams a change actually has to cross.

  • Security3891

    Authorisation at the data layer, secret handling, dependency and supply-chain exposure, tenant isolation.

  • Models5188

    Leakage, calibration, drift monitoring and whether the reported accuracy survives an honest out-of-time split.

  • Performance4789

    Profiles under production-shaped load, query plans, contention and the cost of the tail rather than the mean.

  • Data4285

    Schema constraints, referential integrity, idempotency of writes and what happens on a partial failure.

  • Operability3587

    Tests worth trusting, deploy and rollback, observability, and whether an incident is diagnosable at 3am.

Scores are evidence-backed and rescored after remediation, so the improvement is a number rather than a claim.

Prioritisation

What gets fixed first is arithmetic.

Every finding carries a measured impact and an effort estimate. The order falls out of the ratio, so nobody argues about severity labels.

Findings map · impact against effortranked by impact per unit of effort
do firstMissing row-level authorisationTarget leakage in scoring modelN+1 query on the hot pathNon-idempotent payment writeNo calibration monitoringLock contention under peakService split along wrong seamUnpinned dependency treeremediation effortmeasured impact
remediation order
  1. 01N+1 query on the hot pathperformance5.3×
  2. 02Missing row-level authorisationcybersecurity4.4×
  3. 03Target leakage in scoring modelmodel quality2.9×
  4. 04Unpinned dependency treecybersecurity2.7×
  5. 05No calibration monitoringmodel quality2.2×
  6. 06Non-idempotent payment writedesign structure2.2×
  7. 07Lock contention under peakperformance1.5×
  8. 08Service split along wrong seamdesign structure0.8×

Anonymised engagement. The top four items carried most of the recoverable value and cleared inside week three.

Prototype rescue

From generated prototype to a real application.

AI coding tools are genuinely good at producing something that demos. What they rarely produce is authorisation that holds, data that stays consistent, models that survive a fair split, or a system anyone can operate. That gap is exactly what an audit is for.

Generated codebase · assessed then hardenedproduction readiness 24% → 90%
generated prototype after hardening
  • Authorisation and tenant isolation18% → 94%
  • Data integrity and idempotency26% → 92%
  • Meaningful test coverage21% → 84%
  • Model validation and calibration30% → 88%
  • Performance under real load34% → 90%
  • Observability and rollback12% → 89%
  1. gate 01
    Threat model and data boundary

    Who may read which row, enforced where the data lives rather than in the UI.

  2. gate 02
    Invariants in the schema

    Constraints, transactions and idempotent writes so retries cannot corrupt state.

  3. gate 03
    Honest evaluation

    Out-of-time splits, leakage checks and calibration before any model decides anything.

  4. gate 04
    Load and failure rehearsal

    Profiled at expected peak, then deliberately broken to see how it degrades.

  5. gate 05
    Operable release

    Tests, tracing, alerts and a rollback path, so the team can run it without us.

We keep the parts that work. The result stays your codebase, in your repository, with the demo still working on day one.

Comparison

Why this isn't a consultancy report.

Deliverable
Shadows
Typical review
Structure, security, models and performance in one pass
One dimension at a time
Profiling under production-shaped load
AI-generated prototype taken to production
Findings quantified with effect sizes
Severity labels only
Fixes delivered as pull requests
Recommendations document
Regression gates added to your CI
Rewrite proposed by default
Engineer who audits also implements

Book the first week.

If week one finds nothing worth fixing, we say so and stop billing.

Request an audit