Presenting your architecture to investors

Presenting your architecture to investors is the part of a technical review where founders most often lose trust they did not need to lose, because the slide shows the system they are building toward and the repository shows the system they have. This page is about presenting the one you have, in a form the reviewer can verify, with the decisions behind it and an honest note on what you would change. The investor's side of the same conversation is on assessing architecture and scalability, and the pillar page on preparing for technical due diligence puts this page in sequence.

Matt Van Itallie's checklist of 26 October 2022 asks for an "architecture description and architectural diagrams" as the last item under code quality [1]. It does not say how many diagrams or at what level, and that is the gap this page fills. Reveneau's own builds keep the architecture at three levels of zoom with a decision record for every choice a reviewer might question, because a reviewer who can read the reasoning does not have to reconstruct it from the code, and reconstruction is where a reviewer and a founder end up describing two different systems.

What are the three levels of zoom?

The three levels are the top three abstractions of the C4 model, Simon Brown's approach to software architecture diagramming, which the model's site describes as "an easy to learn, developer friendly approach" [13]. C4 has four abstractions: software system, container, component and code [13]. A container in this vocabulary is an application or a data store, and a component is a grouping of code inside a container. For a technical review, draw the first three and leave the fourth to the repository.

Level one, the system in context. One box for your system, one box for each type of user, one box for each external system it talks to (payment provider, email service, identity provider, the customer's own systems if you integrate). Arrows labelled with what flows. This diagram answers the reviewer's first question, which is what the product is from the outside, and it should match the deck's description word for word.

Level two, the containers. Every deployable unit and every data store: the web application, the API, the background workers, the databases, the queue, the cache, the object store. Each box carries its technology (the language and framework, the database engine) and each arrow carries the protocol. This is the diagram the reviewer will check against your infrastructure account and your deployment configuration, so draw it from those rather than from memory.

Level three, the components that matter. Not every container needs a component diagram. Draw one for the container where the deal's risk sits: the billing service if revenue depends on it, the data pipeline if the product is analytics, the model-serving layer if the product is AI. Show the modules inside and how they depend on each other. This is the diagram that lets the reviewer read the code with a map.

What decisions should you attach?

Attach an architectural decision record for every choice a reviewer might question. The ADR GitHub organisation, which maintains the format, defines an ADR as a document that "captures a single AD and its rationale", where AD means architectural decision, and says it helps a reader understand "the reasons for a chosen architectural decision, along with its trade-offs and consequences" [14]. The format is one page: the context, the decision, the alternatives considered, the consequences.

The decisions a reviewer questions most often are the ones that look expensive or unusual for the stage: why a single database rather than one per service, why a queue rather than direct calls, why this cloud, why a self-hosted component where a managed service exists, why one repository rather than several, why the framework you chose. Our post on how to choose a tech stack for a startup covers the reasoning at the point of choice; the ADR is the record of it.

Ten ADRs of one page each are read faster than one ten-page narrative, and they carry a signal the narrative does not: the dates. A decision record dated two years ago that says "we chose a single database because we have one team and one product; revisit at three teams" tells the reviewer that the team thinks about its own architecture over time. If you have no ADRs, write the ten most important ones now, dated today, and say in the index that they were written for the review. Reviewers accept that; they do not accept a narrative with no reasoning.

Why must every box exist in the repository?

Because the reviewer will look for it. A technical reviewer reads the repository and the infrastructure account with your container diagram beside them, box by box. A box that has no counterpart is either a plan, a retired component or a mistake, and whichever it is, the reviewer now reads every other box with less confidence. The investor-side page on technical due diligence red flags lists the gap between the founders' account and the system as the finding reviewers weigh most, and the architecture presentation is where that gap is easiest to create by accident.

The fix is procedural. Draw the container diagram from the deployment configuration and the cloud console, because those are what the reviewer will check it against. Then have an engineer who did not draw it walk it against the repository and strike anything that is not there. Put what you struck on a separate diagram labelled "planned", with a date and a cost, and present that one second.

There is a second reason. Van Itallie's sixth question, in his TechCrunch list of 25 October 2022, is whether you can explain the observed variation across codebases [2]. An architecture presentation that shows three services when the repository holds seven, four of them half-retired, invites that question in its least comfortable form. Show the seven, mark four as retiring, and give the date.

What should you say about the parts you would change?

Say what stops fitting at what scale, what you would replace it with, what that costs, and what triggers the work. A reviewer expects an architecture built for the company's current size. What they are checking is whether the founders can see where it stops being enough, because a team that can see the limit will plan the change, and a team that cannot will hit it.

A useful format is one table:

Part	Fits until	What changes	Cost	Trigger
Single database	Around 10x current write volume	Read replicas, then partition by tenant	Two engineer-months	p95 write latency over 200 ms for a week
Background jobs in the web process	Around 3x current job volume	Separate worker service on the queue	Three engineer-weeks	Job queue depth over 1,000 at peak
Hand-run deploy script	Now	Pipeline with automated rollback	Two engineer-weeks	Scheduled for next quarter

The numbers in the table are yours, from your own load tests and your own logs, and the reviewer will ask where they came from. "Around 10x" is acceptable in your own table when you can show the load test that produced it; a figure with no test behind it is a guess and should be labelled as one. This table is also the technical half of the roadmap, and a technical roadmap for a fundraise shows how it connects to the money being raised. The investor-side page on assessing technical debt describes how a reviewer weighs a table like this.

How should the walkthrough itself run?

Forty-five minutes, one engineer presenting, the diagrams on screen and the repository open in another window. Run it in this order:

1. Context diagram, five minutes. What the product is, who uses it, what it talks to. Match the deck.
2. Container diagram, fifteen minutes. Each box with its technology, drawn from the deployment configuration. Open the configuration and show the correspondence for two or three boxes, unprompted.
3. Component diagram for the container that carries the risk, ten minutes. Open the code alongside it.
4. Decisions, five minutes. Point at the ADR folder in the data room, summarise the three most important, and invite questions on the rest.
5. What we would change, ten minutes. The table above, with the tests and logs behind each number.

Then stop and let the reviewer ask. The questions will cluster around whichever box you were least confident presenting, and the correct answer to any question you cannot answer is "we will send that today", followed by sending it today.

Put the diagrams, the ADRs and the change table in the code and architecture folder of the engineering data room before the walkthrough, so that the reviewer has read them by the time you present. A reviewer who has already read the diagrams asks better questions, and better questions make shorter reviews.

What if the architecture is one service and one database?

Then present one service and one database, and say why. At seed and often at Series A, a single deployable unit with a single database is the correct architecture, and a reviewer knows it. What they want to see is the reasoning (one team, one product, no scale problem yet), the point at which it stops being enough, and the plan for then. A decision record that says exactly that, dated, is a stronger artefact than a microservice diagram for a company with four engineers, because the second one raises the question of who runs all of those services. The stage-by-stage view is on what changes in technical diligence from seed to Series B.