The 30-Day Architecture Audit (And What It Costs)
What I deliver, who it's for, and what you should expect to find.
I run architecture audits for funded startups and growth-stage companies. This is the public version of the engagement: scope, deliverables, price, and the kind of findings that come out of a typical audit.
Half my engagements start with an architecture audit. It's the most useful first step, both for me and for the client, because it produces a written artifact we can both refer to. Here's the public version of what's in it.
Who this is for
The audit is right for you if any of the following are true:
- You raised in the last six months and want to make sure your architecture supports the next 18 months.
- You inherited a codebase from a founder or previous CTO and want a second opinion.
- Your team has been "fighting fires" for more than a quarter and you suspect structural issues.
- You're considering a major decision (rewrite, migration, big hire) and want a calibration.
It's not right for you if:
- You're pre-product. Audit nothing. Ship something.
- You want validation, not assessment. I will tell you the truth, and the truth might be uncomfortable.
- You can't free up your senior engineers for one or two interview hours each.
The scope, week by week
Week 1: Discovery. I get repo access, infrastructure access, observability access. I run a 90-minute kickoff with the founders or engineering leadership. I map out the system in my own notes.
Week 2: Deep reading. I read the codebase. I look at the deploy pipeline, the monitoring dashboards, the on-call playbooks (or lack of), the database schema, the auth system. I run interviews with two or three engineers, separately.
Week 3: Synthesis. I write the report. This is the bulk of my time. The report is 20-30 pages, structured as: current state, risks ranked by severity, recommendations with effort and impact estimates, and a 12-month suggested roadmap.
Week 4: Walkthrough and follow-up. I do a 90-minute video walkthrough of the report with the leadership team. We schedule a 60-minute follow-up two weeks later to answer questions as they implement.
The deliverable
The report has three sections:
- State of the system. A neutral architectural description, suitable to share with a new senior hire or a board member.
- Risks. Ranked by severity. Each risk includes a description, a worst-case failure mode, the rough cost of remediation, and a recommended action.
- Roadmap. A 12-month sequence of changes, ordered for compounding value, with rough effort estimates.
The roadmap is the part most clients value most. It turns the audit from a critique into a plan.
What it costs
$8,500, fixed price, four weeks. No retainer, no hourly billing. If I run over four weeks, that's on me. If I run under, you don't get a refund. The fixed price aligns my incentives with delivering value, not with billing hours.
For a fractional CTO arrangement, the audit is included in the first month at no additional cost.
What I typically find
After 40+ audits, the patterns repeat:
- One critical observability gap. Almost every team has a part of the system they're effectively flying blind on. Naming it is half the battle.
- One database bottleneck waiting to happen. Usually a missing index, an aggressive write pattern, or a long-running transaction.
- One auth or security antipattern. JWT-as-session, unencrypted secrets, or unvalidated webhooks.
- One organizational issue. A bus factor, a knowledge silo, or a process gap. I include this when I see it because architecture is half about people.
The exact issues vary, but the count is consistent. About 80% of audits surface 5-8 actionable findings.
What clients do with it
Three patterns, roughly equal frequency:
- Implement themselves. They use the report as a roadmap and execute. I'm available for follow-up questions but don't lead the work.
- Hire me to lead the top 1-2 findings. Common when the issues are deep enough that an outside perspective is valuable.
- Use it for hiring. They take the roadmap, write a senior engineer JD around it, and hire for the work.
I prefer option 1 because it leaves the client's team stronger. Option 2 is the most lucrative for me. Option 3 is the most strategic for them.
What the audit isn't
It's not:
- A code review. I won't tell you whether your function names are good. That's a different exercise.
- A security pen-test. I'll surface obvious security issues but a real pen-test is its own engagement.
- A business strategy review. I'll comment on technical risk to the business, not on whether your product is the right one.
- A vendor evaluation. I won't tell you to buy or sell software you're using. I'll comment on architectural fit.
How to know it's worth it
The audit pays for itself if it surfaces a single major mistake before it ships. The cost of the audit is a fraction of one engineer-month. Most audits have surfaced findings worth several engineer-months of avoided pain.
If you suspect there are architectural issues, the audit is the cheapest way to know. If you've already invested heavily in a direction, the audit will tell you how to course-correct without a full rewrite.
The sharper insight
Most teams overestimate how unique their architectural problems are. When I do an audit, I'm pattern-matching against forty others. The problems your team thinks are special are usually the same three or four problems every team at your stage has. That's actually the good news. The solutions are also well understood. The audit is mostly about recognizing the pattern and naming it, then sequencing the fix.
To start a conversation about an audit for your team, the contact page is the fastest way. Or you can start a project formally here.