Assessing architecture and scalability

Architecture is how a system is put together: how the pieces are split, how they communicate with each other, and where the data lives. Scalability is whether that structure keeps working as the company grows. For an investor, these matter because almost every deal thesis assumes growth, and growth is exactly what breaks systems that were built for today's size.

Why is architecture a business question?

Architecture is a business question because the limits of a system cannot be seen until the growth in the plan happens, and that is the most expensive moment to discover them. A system that runs well for ten thousand users can stop working at a hundred thousand. A database design that is fast with a gigabyte of data can become slow at a terabyte. A company can look healthy until the platform cannot handle the load its own growth created. Then it must fix the problem under pressure, with unhappy customers, on a deadline it does not control.

So the question in diligence is "will this architecture support the growth the thesis assumes, and if not, what breaks first and what does it cost to fix". That connects directly to the deal, which is the approach of the main guide. If the thesis depends on scaling the organisation as much as the system, the scaling engineering teams guide is the related guide, because a system and the team behind it scale together.

Reveneau's architecture assessment starts with a live explanation by the engineers rather than a diagram, because a diagram shows the system as someone once drew it and a live explanation shows the system as the engineers understand it today; the difference between the two is itself a finding.

What should the team be able to explain?

The team should be able to explain the main components, where user data lives, what happens when a request comes in, and which parts everything else depends on. You are listening for two things: whether they understand their own system, and whether the design has single points that cannot be duplicated.

The twelve-factor methodology, published by Adam Wiggins and used as a reference for software delivered as a service, gives a reviewer a short list of things to ask about: one codebase tracked in version control, explicit dependencies, configuration kept out of the code, backing services such as databases treated as attachable resources, a strict separation of build, release and run, stateless processes, and development and production kept as similar as possible. A team that can say which of those it follows and which it does not has thought about its architecture.

There is also a pattern worth knowing when you compare the org chart with the diagram. Conway's law, stated by Melvin Conway in 1968, observes that organisations that design systems are constrained to produce designs that are copies of their own communication structures. If three teams do not talk, the system will have three parts that do not talk either. When the architecture looks disorganised, ask how the teams are organised before concluding the engineers are careless.

What breaks first as the company grows?

Ask the direct question: what breaks first as we grow, and at what scale. A strong team knows the answer, because they think about it. They can tell you the database will need attention around a certain size, or a particular service will need to be split. A team that says "it will just scale" either has not thought about it or is not being honest with you, and both are a concern.

Common limit	How it shows up	Usual repair	Cost range
Database cannot keep up	Slow pages as data grows, one large table everything reads	Indexing, splitting data, read replicas, a different store for one workload	Engineering weeks to months
Tightly coupled system	Every change touches many parts, one failure stops everything	Separate the parts that change at different rates	Partial rewrite, months
Single server or single process	No way to add capacity except a bigger machine	Stateless processes behind a load balancer	Known fix, weeks
Every call waits for a reply	Slow third-party calls block users	Queues and background jobs	Weeks per workflow
Manual scaling	Someone adds capacity by hand when it is slow	Automated scaling rules	Weeks, plus the cost work below
No separation of environments	Testing happens in production	Staging that matches production	Weeks, and a process change

These are prices rather than verdicts. A system with real scaling work ahead of it is normal, especially for a fast-growing company that built for speed first. As we have argued, execution speed is the moat, and teams that moved fast often have unfinished scaling work as a result. The job is to price that work against the thesis, which the assessing technical debt page covers in full.

How do you read reliability from the incident history?

Read it for whether the team fixes the underlying causes of failures or only their visible effects. Every real system has incidents. The incident history is a finding only when the same failure repeats, when nobody wrote anything down, or when the team cannot say how long recovery took.

Google's Site Reliability Engineering book gives a reviewer the vocabulary. A service level indicator is "a carefully defined quantitative measure of some aspect of the level of service", such as the share of requests that succeed. A service level objective is "a target value or range of values for a service level that is measured by an SLI". A service level agreement is the contract with users that carries consequences for missing the objective. The book also states that insisting on meeting objectives 100 percent of the time is "both unrealistic and undesirable", because it slows innovation and forces expensive, over-conservative designs, and it recommends an error budget, a rate at which the objective can be missed. A team that can name its objectives and its error budget is a team that has decided how reliable it needs to be. A team with no objectives is guessing.

The same book describes a postmortem as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring", and lists triggers for writing one: user-visible downtime beyond a threshold, any data loss, on-call intervention, and a resolution time beyond a threshold. Ask for three recent postmortems. Read them for the root cause and the follow-up, and check whether the follow-up was completed. DORA's failed deployment recovery time, the time to recover from a deployment that needs immediate intervention, is the number to ask for alongside them; the assessing code quality page explains the other four DORA metrics.

What framework can a reviewer use to structure the assessment?

The AWS Well-Architected Framework is the most widely published one, and its structure works for systems on any cloud. AWS describes it as key concepts, design principles and best practices for designing and running workloads in the cloud, organised into six areas it calls pillars.

Pillar	AWS's focus	The diligence question
Operational excellence	Running and monitoring systems, improving processes	Who is on call, what do they see, how do they learn from incidents?
Security	Protecting information and systems	Covered on the security and compliance page
Reliability	Performing intended functions and recovering from failure	What are the objectives, what is the error budget, what broke last quarter?
Performance efficiency	Allocating computing resources in a structured way	What breaks first as load grows, and at what scale?
Cost optimisation	Avoiding unnecessary costs	How does running cost change with users and revenue?
Sustainability	Minimising environmental impact	Rarely a deal question, unless a customer contract requires it

A reviewer does not need to run the full AWS review. Using the six headings to organise the live explanation is enough to make sure nothing is skipped and to give the deal team a report structure they will see again from other advisers.

How does infrastructure cost reveal a scaling problem?

Infrastructure cost reveals a scaling problem when it rises faster than revenue, because that means each new customer costs more to serve than the last. The FinOps Foundation defines its discipline as an operational framework and cultural practice that creates financial accountability through collaboration between engineering, finance and business teams, and the first thing that practice asks for is a bill broken down by product, customer and environment. A target that can produce that breakdown can answer the question; a target that has one undivided monthly bill cannot.

Ask what the infrastructure costs today, how that cost has moved over twelve months, and how it moves with each new customer. Ask whether anyone is responsible for the bill. Ask what happens to the cost if traffic doubles. Moving between cloud platforms is a project of its own (our note on migrating an app from AWS to GCP sets out what it involves), so a plan that depends on a migration needs its own line in the budget. The cloud cost due diligence page covers rebuilding the bill in detail, and the SaaS metrics versus engineering reality page covers what happens when the gross margin in the model and the infrastructure bill disagree.

How do you put it in the deal?

Name the gap between where the architecture is and where the growth in the thesis needs it to be, estimate the work to close it, and raise that in the deal negotiation. A clean architecture with room to grow counts in favour of the deal. An architecture with known limits is a priced task for the first year, and the technology after the deal guide covers how that task becomes part of the hundred-day plan. An architecture the team does not understand well enough to answer questions about is the warning, and the warning signs page covers why. The technical due diligence checklist lists the architecture questions in a form you can take into the meeting.