§ OFFER 01 — DELIVERY AUDIT · 5 DAYS · FIXED-FEE

Engineering Audit and Delivery Assessment

A structured diagnosis of your engineering and delivery state. Done in 5 days, with a deliverable, executive readout, and a 90-day plan.

Who
Led by the founder, hands-on for the duration.
Timeline
5 days

What you're seeing

Velocity dropped and every explanation you have been given is different.
Usually means Nobody has measured it. Retro answers are recollections, and recollections converge on whatever was most annoying last week rather than on where the hours went.
An enterprise prospect sent a security questionnaire and the team went quiet.
Usually means The gap is usually not the controls — it is that nobody owns evidence, so answering honestly means auditing yourselves first. That is a scoped piece of work once someone has named it.
Two of your senior engineers want to rewrite something and you cannot tell whether they are right.
Usually means The rewrite argument is almost never about the code. It is about a constraint nobody has costed — usually deploy risk or onboarding time — and it stays unresolved until somebody puts a number on both options.
You are about to sign a retainer, a rebuild or a senior hire and you are guessing.
Usually means The commitment is an order of magnitude more expensive than finding out first. This is the case an audit is built for.
The engineering answer you get depends on who you ask.
Usually means Leadership and the team are describing different systems. Both descriptions are usually sincere, and the distance between them is the finding.

What you get

Fixed scope. Everything below is in the engagement, not an upsell.

Deliverable What it means
Workshop Kickoff with founder and CTO/VP Eng (if present)
Code, CI/CD, and Architecture Review PR velocity, deployment cadence, observability, infra basics
Anonymous Engineer Interviews Surface what the team won't say in front of leadership
Hiring Pipeline & Roadmap Review Where candidates drop out, time-to-offer, attrition signal
Compliance Readiness Gap Analysis When applicable — controls, evidence pipeline, vendor review
Written Deliverable + Executive Readout 40–60-page PDF: diagnosis · prescription · 90-day plan + readout for founder + board

The capabilities behind it Architecture Review · Technical Debt Assessment · Code Security Review · Delivery Metrics

Five days, and why not more

Five days is long enough to establish what is true and short enough that the answer arrives while the question still matters. Both halves of that sentence are load-bearing.

Longer diagnostics have a failure mode we would rather avoid: by week three the engagement has started to feel like the work, and the report becomes an artefact defending the time it took. Shorter ones cannot run anonymous interviews and reconstruct delivery history from the repository, which is where the two most useful findings usually come from.

What five days does not buy is depth on any single system. If the finding is that one service is a genuine problem, the audit tells you that and estimates what it costs. It does not redesign it.

Where the answers come from

Four sources, and the value is mostly in the disagreement between them.

The repository. Pull request latency, review turnaround, deploy frequency, and how much of each sprint arrived unplanned. This is history rather than opinion, and it can be re-measured later to check whether anything actually changed.

The engineers, anonymously. Forty-five minutes each, and leadership does not see who said what. This is the source that produces the sentence nobody would say in a retro.

Leadership, on the record. The system as it is understood at the top, the roadmap, the commitments already made externally.

The systems themselves. Architecture, CI/CD, observability, dependency and security posture, and the hiring funnel if that is in scope.

Where the repository and the retro disagree, the repository wins. Where leadership and the team describe different systems, the distance between the two descriptions is itself the finding — and it is the one that most often explains everything else on the list.

What this is not

It is not a code review. We read code, but a five-day audit that spent its time in a codebase would return a list of things a competent engineer could have told you for free.

It is not an assessment of individual engineers. We will tell you if the team is under-levelled for the plan. We will not tell you which people to keep.

It is not a proposal in a report’s clothing. The prescription is written so your own team can execute it, and about a third of the time the honest top priority is something we do not sell.

Where it leads

Most audits end in one of three places, and the report says which one it thinks you are in.

The finding is narrow and already understood — one acute problem with a known shape. That is a fixed-scope engagement: CTO Consulting runs four to eight weeks against exactly one of velocity, compliance readiness or hiring.

The finding is that the technical leadership seat is the problem. That is a Fractional CTO retainer, and the audit fee comes off the first month.

Or the finding is that you already know what to do and have the people to do it. Then the ninety-day plan is the deliverable and there is nothing further to buy.

How it runs

  1. Days 1–3 · Workshop + Interviews + Code Review

    • Kickoff workshop with founder and CTO
    • Anonymous engineer interviews
    • PR velocity, CI/CD, deployment cadence audit
    • Hiring pipeline data pull and review
  2. Days 4–5 · Synthesis + Deliverable + Readout

    • Compliance readiness gap analysis (when applicable)
    • Roadmap split analysis (last 90 days)
    • Written deliverable: diagnosis · prescription · 90-day plan
    • Executive readout for founder + board

Total duration

5 days

Phases

2

Deliverables

6 items

Engagement

standalone

How this is priced

Model

Fixed scope

One fixed fee for a fixed five days, agreed before we start and unchanged by what we find. There is no hourly component and no expansion mid-engagement.

Fixed The five days, the fee, and the deliverable: a written diagnosis with a ranked ninety-day plan, plus the executive readout. The fee is credited against the first month of a retainer if you move to one within thirty days.

What moves it

  • Whether compliance readiness is in scope, which adds a controls and evidence pass
  • The number of engineers to interview — the range is a team, not a division
  • Whether the readout is for a founder or for a board, which changes the second half of the document
  • Travel, if you want the workshop and the readout in the room rather than remote

How we decide

  • Engineer interviews are anonymous, and leadership does not see the transcripts

    Costs It means we cannot attribute a finding to the person who raised it, even when that would make it more persuasive.

    The most useful sentence in an audit is one somebody would not say in front of their manager. Attribution is worth less than getting the sentence at all, and a team that suspects otherwise gives you the version they think is safe.

  • Delivery is measured from the repository, not from the retro

    Costs It takes read access to systems some companies are slow to grant, and it occasionally contradicts a story the team believes about itself.

    Pull request latency, deploy frequency and the share of work that arrived unplanned are all in the history already. They are facts rather than impressions, and they are the only part of an audit that can be re-run later to check whether anything changed.

  • Findings are ranked by what they cost, not by how bad they look

    Costs Some genuinely ugly things end up near the bottom of the list, which is uncomfortable to present.

    A ranked list is only useful if the ranking is the order you should act in. Severity ranking produces a document where the top item is the most alarming, which is rarely the most expensive, and a founder who works down it in order wastes the quarter.

  • The report separates what we measured from what we were told

    Costs It makes the document longer and admits the limits of five days in writing.

    Five days is not enough to verify everything, and a report that reads as though it were is worse than no report — it converts an assumption into a decision. Marking the unverified is what makes the verified part worth acting on.

An audit, diligence, and just asking the team

Three ways to find out what state your engineering is in. They differ by who is asking and what the answer is for.

Approach Who it is for What it produces What it misses
Engineering Audit The company being assessed, before a bigger commitment A ranked diagnosis and a ninety-day plan you can act on Depth on any single system — five days buys breadth
Technical Due Diligence An investor or acquirer, before money moves A risk-priced report and a rebuild estimate for a deal team It prices the problem rather than fixing it
An internal review The team, on its own initiative Real knowledge of the system, from people who live in it The things nobody will say to their manager, and any outside benchmark
Starting a rebuild anyway Teams confident they already know the cause Momentum, and an answer either way in a quarter The chance that the cause was somewhere else

The last row is the real comparison. Five days of diagnosis costs a fraction of a quarter spent rebuilding the wrong thing, and about a third of the audits we run end with a different top priority than the founder expected.

Is this you?

  • Founders who want an independent read before a bigger commitment
  • Teams that crossed 20 engineers and velocity is dropping
  • Companies facing a compliance gap exposed by an enterprise deal
  • Companies whose technical leadership seat is empty

What Our Clients Say

"The 5-day audit was the cheapest engagement we've run. It surfaced three blockers we'd been arguing about for months and gave us a 90-day plan our board could read in one sitting."

CTO

CTO at Series A SaaS · name available after NDA

Frequently Asked Questions

A short, structured diagnosis of how a software team actually builds and ships, run by someone from outside it. It covers architecture, delivery metrics, technical debt, hiring and — where it matters — compliance posture, and it ends in a written finding rather than a conversation. The point is to establish what is true before you commit money to changing it.
From the discovery call to a signed scope is typically five to ten business days. Kickoff is the week after that. The five days themselves do not have to be consecutive if your team's calendar makes that difficult, though the interviews work better close together.
Read-only access is ideal. Staging works if it has to, but production telemetry surfaces things staging hides — error rates under real load, the difference between deploy frequency and release frequency, the incidents nobody wrote up. Where access is refused we say so in the report rather than guessing around it.
A half-day workshop at the start, forty-five minutes each from the engineers we interview, and a couple of hours from whoever holds the systems access. Under a day per person. The rest of the work happens against the repository and the ticket history without anybody sitting with us.
A written deliverable — diagnosis, prescription and a ranked ninety-day plan — plus a readout session for the founder and, if you want it, the board. The document is written to be read by both: an executive summary that stands alone, and an engineering section detailed enough for your technical lead to act on this week.
Yes. If you move to a retainer within thirty days, the audit fee is credited against the first month. That is deliberate — it removes the incentive to write a report that manufactures a reason to hire us.
That is the most common outcome and it is the reason to run one. Roughly a third of the audits we do end with a different top priority than the founder came in with. If the honest finding is that you do not need us, that is what the report says.

Sources

Page reviewed