2-week audit. Priority-sorted P0-P3 fixes. Rewrite-or-refactor call.
Fixed-scope architecture review covering code, infra, data, team, velocity. Actionable, not ceremonial. From $4,500/mo.
Who this is for
Founder 6–12 months post-seed feeling velocity slow, unclear what's actually wrong, and needing an outside assessment to inform the next quarter's engineering plan.
The pain today
- Velocity declining but team cannot articulate what's wrong
- MVP tech debt compounding — unsure what's load-bearing vs disposable
- Board asking about scale readiness with no clear answer
- Team split between 'refactor' and 'rewrite' with no decisive input
- Hiring more engineers hasn't helped — maybe even slowed things down
The outcome you get
- Executive brief of architecture state — what's working, what's not
- P0-P3 prioritized fix list with business-impact scoring
- Clear rewrite-or-refactor recommendation, defended with evidence
- Technical roadmap for the next 6 months
- Team-directed plan — what senior engineers should own vs hire
What I examine
Five layers, each contributing to the final assessment. Code: coupling, test coverage, abstraction quality, documentation. I read through 3–5 key modules, not every file. Infrastructure: deployment pipeline, monitoring, logging, alerting, incident history. Data: schema health, query performance, data integrity patterns, backup and recovery. Team: size, seniority mix, engineering practices (standup, PRs, code review), velocity over time. Velocity: story points over time, deployment frequency, mean time to recovery from incidents. The audit is data-driven; opinions come after the numbers. Each layer gets a 1–5 score with evidence.
P0-P3 prioritization framework
P0: critical issues affecting production stability or security (fix immediately). P1: significant drag on velocity or scale readiness (fix within 1 quarter). P2: moderate issues that compound if ignored (fix within 2 quarters). P3: improvements worth tracking but not urgent. Each issue includes: description, business impact, effort estimate, dependencies, recommended owner. Scoring is deliberately conservative — calling something P0 costs your team's time, so the bar is high. Founders get a ranked list they can prioritize against business context (e.g., 'don't fix P1 infra this month because we're launching in 4 weeks').
Deliverable format
Two outputs. Executive brief (5–10 pages): summary of state, top findings, rewrite-or-refactor recommendation, 6-month roadmap. Written for the founder, board, and lead investor. Engineering roadmap (15–30 pages): detailed findings per layer with evidence, P0-P3 list, technical context for each fix, suggested implementation approaches. Written for the engineering team to execute against. Both delivered by end of week 2. Presentation meeting with founder + senior engineering lead to walk through findings, answer questions, and commit to the first month of priorities.
Case studies: Cuez, Imohub
Cuez: post-funding-ready state — the core API was 3 seconds when the team believed it was 'a bit slow.' Audit identified the specific query patterns and caching gaps driving the issue, plus the architectural patterns letting bad queries proliferate. Fix dropped API to 300ms (10x faster) and cut infra cost ~40%. Imohub: legacy stack with 120k+ property records, team unclear on rewrite vs refactor. Audit recommended rebuild (Next.js + Laravel + Meilisearch + MongoDB) with clear evidence; post-rebuild query response under 0.5s and infra cost down 70%. Both audits were the beginning of a fractional engagement, not one-off deliverables.
Fixed-scope pricing
Architecture audits fit the Fractional CTO service at $4,500/mo, delivered as a 2-week fixed-scope first engagement. If findings warrant follow-up work, the monthly retainer continues (Advisory $4,500 or Fractional $8,500 depending on engagement depth). Most founders do the audit first, then decide on ongoing engagement based on what was found. 14-day money-back on the audit if the findings don't justify their cost. Work Made for Hire on the written deliverables. If you take the audit and decide to act on it with your internal team only, that's completely acceptable — the audit was the deliverable.
Rewrite vs refactor call
The hardest question post-seed is often whether to burn down the current codebase or iterate. Factors I weigh: codebase age, test coverage, team's relationship with the code (love vs hate), architectural clarity, business velocity pressure, technology freshness, cost of being wrong. Rewrite: right when architectural foundations are fundamentally wrong for scale, when the team can't make predictable changes, or when the tech stack itself blocks velocity. Refactor: right when the foundation is sound but specific hot spots need repair, when business pressure can't accommodate 6 months of no-feature-shipping, or when the team's tacit knowledge would be lost in rewrite. I give a decisive recommendation with evidence, not a both-sides 'it depends.'
Recent proof
A comparable engagement, delivered and documented.
Rescued a slow API that was blocking user growth
Refactored the backend architecture, making the system far more responsive and scalable for the growing user base.
Frequently asked questions
The questions prospects ask before they book.
- What does the 2-week audit actually include?
- Week 1: access to codebase, infrastructure, monitoring, team interviews (3–5 engineers), incident history review. Week 2: synthesis, deliverable drafting, presentation meeting. Deliverables: executive brief, engineering roadmap, priority fix list. You see draft deliverables by end of week 2 with a 30-minute walkthrough.
- Do I need to keep you on retainer after the audit?
- No. Audit is a fixed-scope deliverable. Many founders act on audit findings with their internal team only. Some continue on retainer for implementation oversight or ongoing CTO work. Your call based on what the audit reveals — no pressure either way.
- What if the audit reveals the codebase needs rewrite?
- Then I say so, with evidence. Rewrite recommendations are rare (incremental refactor handles most cases) but I don't soften the call when rewrite is genuinely right. The evidence-based approach keeps the recommendation defensible to your board and investors.
- Will the engineering team be defensive?
- Sometimes. I position the audit as tool for the team, not judgment on them. Interviews are collaborative — engineers usually know exactly where the problems are. Finding are framed as 'here's what needs attention' not 'here's what's wrong with the team.' Done well, audits increase team confidence by externalizing the anxiety.
- How recent does the codebase need to be?
- Any age. I've audited codebases from 6 months old to 7 years old. Older codebases reveal more historical context; newer ones are faster to understand but have fewer patterns to assess. Findings scale accordingly; the framework works regardless of age.
Ready to start?
Tell me what you need in 60 seconds. Tailored proposal in your inbox within 6 hours.