MVP Technical Audit: What We Check in the First 48 Hours

Most MVP audits produce a document. A useful one produces decisions: what is on fire, what can wait, and what it costs to fix.

An MVP technical audit answers one question: can this codebase carry the next 12 months of the business, and if not, what exactly has to change? Everything else — tooling opinions, style debates, framework preferences — is noise.

This is the checklist we work through in the first 48 hours of an engagement. It is deliberately ordered by cost of being wrong: the things at the top can end a company, the things at the bottom cost you velocity.

1. Money and data integrity (highest cost of failure)

If the product moves money or holds regulated data, this comes first. Bugs here are not incidents — they are liabilities. We look for:

• Whether balances are derived from an append-only ledger, or stored as a mutable number that code can overwrite
• Idempotency on every payment and webhook path — can a retried request double-charge or double-credit?
• Use exact decimal or integer minor-unit amounts with currency rules.
• Transaction boundaries: can a partial failure leave the system in a state where money exists in two places or none
• Reconciliation: is there any process that would detect a discrepancy, or would you find out from a customer?

2. Security and access control

• Authorization checked per-request on the server, or assumed because the UI hides the button
• Secrets in environment variables and a secret manager, not in the repository history
• PII and card data: what is stored, where, and whether it should be stored at all
• Dependency vulnerabilities that are actually reachable, not just a red number in an audit report
• Multi-tenant isolation: can a crafted request read another customer's data?

3. Architecture and scaling limits

We are not looking for elegance. We are looking for the specific wall the system hits, and how far away it is.

• The single points of failure — the database, the queue, the one service everything calls
• Query patterns that are fine at 1,000 rows and fatal at 1,000,000 (N+1s, missing indexes, unbounded scans)
• Whether the system can be deployed without downtime, and whether anyone has tried
• Coupling that prevents shipping one feature without touching five modules
• Whether the architecture matches the team size — microservices with four engineers is a scaling problem, not a solution

4. Delivery and operations

Codebases do not decay on their own; process decides how fast. What we measure:

5. Technical debt: triaged, not listed

Every codebase has debt. A list of it is useless. What matters is classification, and we use three buckets:

1. Blocking — prevents shipping the roadmap or risks money/data. Fix now.
2. Compounding — makes every future change slower. Schedule deliberately.
3. Cosmetic — offends taste, costs nothing. Leave it alone.

The goal of an audit is not to find everything that is wrong. It is to find the few things that are wrong enough to matter, and to be specific about what they cost.

What you should receive at the end

A useful audit is judged by what you can do with it the next morning. The deliverable should contain:

• A prioritized list of findings with severity and business impact — not a catalogue
• For each finding: the fix, a realistic effort estimate, and what happens if you do nothing
• A sequenced roadmap: this quarter, next quarter, later
• Evidence — the actual query, the actual endpoint, the actual line — so your team can verify rather than trust

Turn the first review into a testable backlog

Time-boxed discovery produces a coverage map, not proof that every defect has been found. Make each finding independently verifiable.

1. Attach the affected journey, evidence and reproduction conditions.
2. Separate observed defects, plausible risks and inaccessible areas.
3. Give each fix an owner and a regression check.

• mvp rescue services →
• how to fix a broken mvp →