Backend Health Check Before a Series B:
What VCs Actually Probe

The email lands with a partner cc'd and a name you don't recognise in the signature — the fund's technical partner, or an independent diligence firm they retain. Attached is a data-room request: an architecture diagram, a dependency list with licences, your last two incident post-mortems, six months of deploy history, and read access to a representative repository.

Half of that you can produce this afternoon. The rest you'd have to build, and building it is where you start finding things — which is the argument for running a backend health check before a Series B yourself, rather than discovering the findings alongside the investment committee.

One reframe makes the process legible: the reviewer isn't grading your code. They're testing whether the system supports the number the fund is underwriting. Can it carry the growth in the model, keep the data it holds, survive its authors leaving, and absorb the engineers the round will pay for? Findings that miss those four questions get noted and forgotten. Findings that hit them move terms.

This is the fundraising cut of a general assessment: our CTO's guide to backend architecture reviews ranks seven areas by cost of being wrong, and diligence consolidates them into four — plus one that only matters when someone is buying equity in your team as well as your software.

The Five Areas a Backend Health Check Before a Series B Has to Cover

Ranked by cost of being wrong — the blast radius if the area is broken — not by ease of fixing. Those orderings run opposite, which is why teams preparing on instinct polish the cheap, visible things and leave the expensive ones where a reviewer will find them.

Data integrity

They trace a number. Pick the ARR figure from your deck, ask which system produces it, and run that query against the system of record. If they disagree — or the query turns out to be a hand-maintained spreadsheet — the conversation stops being technical. In a regulated platform they also ask what happens when a payment message is delivered twice, and whether a correction is an appended entry or an edit. A ledger you can edit is a ledger you can't prove, and that finding doesn't say your software is weak — it says the number the term sheet was priced from might be wrong.

Security boundary

Nobody expects a mature security programme at Series B. They expect a boundary you can describe and an incident history you disclose. The checks are cheap and mostly automated: git history rather than current HEAD scanned for committed credentials, a dependency scan for known vulnerabilities, an enumeration of what's reachable from the public internet, and the production access list — where former employees turn up more often than anyone expects. OWASP's Application Security Verification Standard is the benchmark a competent reviewer works from. Findings here rarely kill a deal alone; an undisclosed one does, because it reprices everything else you said.

Team dependency

This has no equivalent in a normal architecture review: the fund is underwriting a team as much as a system. The check is mechanical — commit distribution, service by service. If one name owns most of the payments service, that isn't a code-quality finding, it's a valuation input, because the fund now knows which resignation stalls the roadmap. The follow-up is behavioural: can anyone else deploy it, is there a runbook, has a second engineer actually operated it. Concentration seldom blocks a round; it surfaces in the paperwork — retention packages, extended vesting, key-person provisions.

Scaling headroom

The probe is not "can you handle 10x." Almost nothing at Series B handles 10x and reviewers know it. The probe is whether you know where the first wall is and what moving it costs. We've load-tested to four times current peak, the first constraint is the single-writer path on the ledger table, and the fix is a partition-key change scoped at three weeks describes command of a system. We're on Kubernetes, we'll scale out describes a hope — worse than admitting a hard limit, because it says a limit exists and hasn't been looked for.

The strongest version is a constraint you removed rather than bought more of. In our cloud robotics test infrastructure engagement, test throughput was bounded by physical rigs — more testing meant more hardware, and multi-robot scenarios weren't solvable by buying more units at all. A cloud-hosted parallel simulation harness took parallelism off the hardware budget entirely: no physical rigs, scenario spin-up from hours to minutes.

Deployability

Release risk shows up in history, not in tooling. Four delivery measures — deployment frequency, lead time from merge to production, change failure rate, time to restore service — are the set popularised by Forsgren, Humble & Kim in Accelerate (2018), and still the shorthand most reviewers reach for. One who knows them reconstructs yours from your deploy history whether or not you volunteer them. The revealing question is rollback: does one exist, and has it been used in anger. A team that has never rolled back either has an exceptional record or has no rollback.

What They Ask vs What They're Actually Probing

The questionnaire is not the finding. Diligence questions stay deliberately open, because a broad question surfaces how you think about the system.

"Walk us through your deployment process."

The probe: tribal-knowledge dependency, not your CI tool. They are listening for whether the sentence contains a person's name — Marek usually runs it, and he checks the queue depth after is a bus-factor finding delivered voluntarily. A good answer: any engineer can deploy, the pipeline gates on these checks, rollback is one command and we used it twice last quarter.

"Can you send us your architecture diagram?"

The probe: whether anyone holds an accurate model of the whole system. They check the diagram against the repository list and, if they can see it, the cloud bill — services in the bill that aren't on the diagram are the finding, as is a diagram whose last edit predates your last refactor. A good answer: a current diagram, plus an unprompted note on which parts are provisional.

"What's your test coverage?"

The probe: whether the system can be changed safely, because the next eighteen months are nothing but change. The percentage is close to meaningless; the real question is the follow-up — what runs on a pull request, what's the last change that broke production, and how did you find out. A good answer: the safety net around payments, auth and the data path, and honesty that coverage elsewhere is thin.

"What would you do with five more engineers?"

The probe: whether the architecture can absorb people. Headcount converts into velocity only if new engineers can ship without serialising through one service, one repository, or one reviewer. A good answer: the two or three areas where a new team could work independently by week three, and the one place that would still be a bottleneck.

The 30-Day Pre-Fundraise Prep Playbook

Sequenced by cost of being wrong, not by ease — which is why the visible work is last.

• Days 1–5 — Make the numbers tie out. Take every metric in the deck, find the query or job that produces it, and run it against the system of record. Reconcile any gap while it's still an internal discrepancy. In the same pass, list every place a financial or usage record can be modified in place rather than corrected by an appended entry. This goes first because it's the only area where a finding ends a process outright, and the only one whose remedy might outlast the window.
• Days 6–12 — Close the cheap security gaps. Scan git history for credentials and rotate anything you find. Run a dependency vulnerability scan and triage the criticals. Enumerate what's publicly reachable and confirm authorisation is enforced at each entry point rather than assumed at the gateway. Pull the production access list and remove everyone who has left. Days of work against deal-level cost — the best return in the window.
• Days 13–20 — Convert bus factor into documentation. Run commit distribution per critical service. Wherever one person owns the knowledge, have a second engineer perform the next deploy and write the runbook while doing it. You cannot fix key-person risk in a month. You can turn only Marek can deploy this into Marek wrote it down and Priya has done it once — a materially different sentence in a diligence report.
• Days 21–26 — Find the wall; don't move it. Load-test to three to five times current peak and identify the first thing that breaks. Write one page: the constraint, the evidence, the fix, a rough cost. That page beats a month of optimisation, because it answers the scaling question with measurement instead of assertion — and the fix itself is the work the round is meant to fund.
• Days 27–30 — Assemble the pack, and bring your own risk register. Regenerate the architecture diagram from reality. Collect the dependency and licence list, the incident log, the access matrix, the capacity page. Then add what most teams omit: a ranked list of your known technical debt, each item with a scope, a cost, and an owner. A weakness handed over with a plan demonstrates control; found by the reviewer, it's a blind spot — and blind spots get priced, because they imply the ones nobody found.

What's Not Worth Fixing Before Diligence

Spending the window on the wrong work is the common failure, and it's a good-faith mistake: the wrong work is more visible, more satisfying, and finishes inside the deadline.

• Don't start a rewrite. Nothing that can't finish in the window should begin in it. A half-migrated system is strictly worse in diligence than a coherent old one — it doubles the surface a reviewer must assess and reads as instability rather than progress. If a component genuinely needs replacing, that belongs in your risk register with a cost attached; the rebuild-or-refactor decision deserves its own evidence, not a fundraising deadline.
• Don't chase a coverage number. Going from 40% to 70% in a month produces tests written to move a number, plus a burst of commit activity in the weeks before diligence that a reviewer can see in the history. It reads exactly like what it is.
• Don't buy headroom you haven't proven you need. Scaling is the most over-prepared area and one of the least often deal-blocking. Knowing where the wall is beats having moved it, and the money to move it is the money you're raising.
• Don't hire to fix key-person risk, and don't polish cosmetics. A senior engineer three weeks in is not a second owner of anything — documentation and a witnessed handover are. And naming, formatting and folder structure are the cheapest, most visible category, which is precisely the trap.

Which leaves the honest breakdown. Data integrity and an undisclosed security incident are the two findings that genuinely stop processes — cheap to check, expensive to discover late. Team dependency almost never blocks a deal but frequently changes its structure, a cost paid in paper rather than price. Scaling headroom and deployability get noted, priced, and converted into a post-close plan: real, survivable, and not where a scarce month should go.

What does technical due diligence actually look like?

For a Series B the technical workstream typically runs two to six weeks alongside commercial diligence — a rule of thumb, not a rule, and shorter than the term-sheet-to-close timeline it sits inside. It opens with a questionnaire and a data-room request, moves to interviews with the CTO and one or two senior engineers, then a reading period across the repository, deployment configuration and automated scans. The reviewer is usually an independent firm or an operating partner with an engineering background, not the deal partner. The report goes to the investment committee and you may never see it — but you will see its consequences: sharper follow-ups, conditions attached to closing, or a 100-day plan you inherit after it.

Do VCs read code?

The partner almost never does. The technical reviewer does, but selectively — nobody audits a Series B codebase line by line. They read closely where being wrong is expensive: the service that moves money, the path that handles personal data, the authorisation checks, and the write path behind whatever metric the deal is priced on. Everything else is scanned by tooling — secret scanners, dependency and licence checks, static analysis — so the whole repository is examined even though only a fraction is read. Git history matters as much as current state: it shows how the team works, and whether anything was committed that shouldn't have been.

How do we explain technical debt without scaring them?

By getting there first, with numbers attached. Every system at this stage carries debt and no experienced reviewer expects otherwise — what they're assessing is whether you know where yours is. Debt described as a named item with a scope, a cost, and a place in a sequence reads as command of the system. Discovered independently, the same debt reads as a blind spot, and blind spots get priced conservatively because they imply others nobody found. Avoid two moves: minimising something you'll be asked about again in a month, and offering a rewrite as the fix, which converts a known cost into an unbounded one.

What if our system can't handle 10x?

Then you're where nearly every company raising a Series B is, and it isn't the finding you think it is. Almost no system carries an order of magnitude without change, and reviewers price the answer rather than the headroom. What separates a good answer from a bad one is evidence: the constraint named, the load test that found it, the remediation scoped, a rough cost. "We think it'll be fine" reads as a team that hasn't looked — a worse position than a documented hard limit, because it leaves the reviewer to assume the worst case.

Where This Leaves You

Fix what's cheap and dangerous, document what's expensive and known, and walk into diligence holding the same list the reviewer is about to build. The goal isn't a clean report — it's that nothing in theirs is news to you.

If your backend shows any of the patterns above, our Discovery Sprint is a two-week diagnostic that tells you exactly what to fix and in what order — a written, ranked risk register tied to your actual code and configuration, plus the remediation sequence. Teams use it as pre-fundraise prep for exactly this reason: it produces the document you'd want to hand a diligence reviewer, four weeks before they ask for it. If a round is starting and you want a read on where you stand, reach out — no pitch, just a conversation.

Back to Insights