A Founder's Guide to Back-of-the-Envelope Capacity Planning

Before choosing a database or load balancer, founders must estimate traffic, storage, and server needs. A simple framework provides order-of-magnitude numbers to prevent overspending or a launch-day crash.

“Can a single server handle the traffic?” This is one of the first questions a system designer asks, according to a technical guide by Jaspreet Singh. Before choosing a database or caching layer, a founder must first understand the scale of the system. Skipping this step leads to two outcomes: over-provisioning that burns cash, or under-provisioning that kills a product on launch day. Back-of-the-envelope calculations provide a framework for making architectural decisions with reasonable estimates. System design is fundamentally about making trade-offs, and those trade-offs require a grasp of the numbers.

The standard estimation flow

The process begins with users and works down to the required hardware. The source lays out a five-step sequence: estimate total users, then calculate expected traffic, storage needs, RAM/cache requirements, and finally the number of servers. This flow forces a disciplined approach, moving from the known (or assumed) user base to the unknown infrastructure requirements. The goal is not perfect accuracy. The goal is to be in the right ballpark to make foundational architectural choices.

A cheat sheet for core assumptions

To ground these estimations, the framework relies on a set of common heuristics. These are starting points, not universal truths, often used in technical interviews to standardize the problem.

• Peak Traffic: 3x Average Traffic. This accounts for daily or weekly spikes in usage.
• Active Users: 10-20% of Total Registered Users. This helps translate a vanity metric (total signups) into a load metric (concurrent users).
• Hot Data: 20% of Total Data. This is the subset of data accessed most frequently, informing what should be prioritized for caching.
• Cache Hit Ratio: 80% of requests. This assumes an effective caching strategy where most reads are served from fast memory, not the primary database.

A worked example: thinking at scale

The source uses Facebook to illustrate the model. Starting with an assumption of one billion registered users, the first calculation is for Daily Active Users (DAU). Using the 20% heuristic, the system needs to be designed for 200 million daily active users. All subsequent calculations for traffic, storage, and server load would flow from this initial DAU estimate. The specific numbers are less important than the process of moving from one logical step to the next.

WHAT WE'D CHANGE

The provided framework is a solid starting point for a pre-launch thought experiment. Its origins in system design interviews, however, create blind spots for a founder building a real product. The assumptions need to be contextualized for an early-stage venture, not a FAANG-scale platform.

For a new product, assuming 10-20% DAU of total users might be dangerously low. Early adopters are often highly engaged, with DAU/MAU ratios potentially exceeding 50%. A “3x peak traffic” assumption could also be an underestimate. A successful Product Hunt launch or a viral post can easily generate 10x or 20x average traffic, and the system should be able to withstand that success. Founders should model best-case scenarios, not just average days.

The model also predates the widespread adoption of serverless architecture. The final step, “Number of Servers,” is an abstraction many founders no longer manage directly. The estimation exercise remains critical, but the output changes. Instead of server count, the founder should be estimating monthly costs for Vercel, AWS Lambda invocations, or Supabase database reads. The calculation shifts from capital expenditure to operational expenditure, making accurate estimation critical for managing burn rate.

LANDING

This estimation is not a one-time task performed before writing the first line of code. It is a living model of the business's technical and financial footprint. The initial back-of-the-envelope numbers should be replaced with actual metrics from analytics and logging as soon as they are available. The practice of connecting user growth directly to infrastructure cost is the core discipline. It builds a founder's intuition for the physical reality of their software, ensuring that growth is not just possible, but sustainable.

The investor read

Technical founders who can perform these calculations signal operational maturity and capital efficiency. This is not about precise prediction, but about demonstrating a grasp of unit economics at the infrastructure level. For bootstrapped or seed-stage companies, this skill is a proxy for disciplined resource management; a founder who can right-size their cloud bill is less likely to burn through capital on vanity infrastructure. While VCs funding growth-stage companies may prefer over-provisioning to avoid downtime, early-stage investors see this estimation as a positive signal of a founder's ability to build a sustainable, cost-effective product from the ground up.

Pull quote: “System design is fundamentally about making trade-offs, and those trade-offs require a grasp of the numbers.”