“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupéry
The Goldilocks Problem of Platform Engineering: Avoiding Over- and Under-Engineering
When you set out to build a platform, you’re immediately walking into a trap: the temptation to over-engineer. The trap is equally matched by its opposite: the risk of under-engineering. This “Goldilocks problem” of platform design has haunted builders from the earliest days of computing to the modern SaaS startup.
A Brief History of “Too Much” and “Too Little”
In the 1960s, IBM bet on too much: its OS/360 project famously ballooned into one of the most expensive software projects in history, weighed down by features and complexity. Fred Brooks, who led the effort, later chronicled the dangers of over-engineering in The Mythical Man-Month—a book still quoted today.
Fast-forward to the early web: Friendster is often cited as an example of under-engineering. The platform hit viral growth but collapsed under the weight of its own architecture. Users fled when page loads slowed to a crawl. Facebook, by contrast, took a pragmatic approach—launching on simple LAMP stack infrastructure, but quickly investing in caching, sharding, and homegrown distributed systems when load required it.
In other words, engineering decisions determine not just technical health, but the survival of entire companies.
The Inputs and Dimensions That Matter
The question every engineering leader faces is: How do I know how much is enough? The answer lies in mapping the key inputs and dimensions:
- Stage of the Company – Pre-seed/seed companies should bias toward speed and iteration; Series B+ should bias toward resilience and scale.
- Expected Load – Users, transactions, or data throughput. Even proxies matter.
- Volatility of Load – Spiky demand (e.g., ticket sales) requires more elasticity than steady demand (e.g., B2B SaaS seat licenses).
- Criticality of the Platform – Banking platforms demand higher fault tolerance than social apps.
- Cost of Failure vs. Cost of Delay – What hurts more: downtime or time to market?
- Regulatory & Security Requirements – SOC2, HIPAA, PCI, etc. raise the minimum bar.
- Talent & Team Composition – A lean team may not be able to operate bleeding-edge infrastructure responsibly.
A Formula for “Right-Sizing”
Some leaders have tried to turn this into a formula. Martin Fowler, in his writings on architecture, suggests optimizing for evolutionary design—systems that can adapt incrementally rather than be “right” from day one. The Industry Formula that’s gained traction is:
Right-Sized Engineering Effort (RSEE) ≈ (Expected Load × Cost of Failure) ÷ (Stage × Time-to-Market Pressure)
Where:
- Expected Load = projected users or revenue (proxy)
- Cost of Failure = reputational/financial risk per incident
- Stage = scaling factor (early stage = lower denominator, later stage = higher)
- Time-to-Market Pressure = how fast you need to learn
It’s not an exact science—but it forces leaders to articulate trade-offs rather than rely on gut instinct.
Building a Revenue Model to Approximate Load
Early-stage founders rarely have detailed user telemetry. Instead, revenue can serve as a stand-in for load:
- Define Unit Economics – If your SaaS charges $20 per seat/month, each seat = 1 unit of load.
- Estimate Conversion – Based on pipeline and market sizing, estimate how many seats you might add per month.
- Translate to Transactions – For example: 1 seat = 10 API calls/minute.
- Project Growth Curve – Apply conservative, base, and aggressive revenue growth scenarios.
- Derive Infrastructure Demand – $1M ARR might imply 5,000 seats, which implies 50,000 API calls/minute peak load.
This turns vague financial projections into engineering signals.
Formula:
Projected Load = (Revenue ÷ Unit Price) × Load per Unit
Example:
- Revenue Target: $5M ARR
- Unit Price: $500/year/user
- Users = 10,000
- If each user generates 20 requests/day → 200,000 requests/day (≈ 2.3 requests/sec steady state, with peaks ×10).
What Good Looks Like
- Slack (early years): Launched on simple AWS architecture but invested in monitoring and observability from day one. The result: they could scale when growth came, without premature complexity.
- Netflix (mid-2000s): Migrated to AWS after DVD rental infrastructure couldn’t scale. They built resilience patterns (Chaos Monkey, circuit breakers) just in time to meet streaming demand.
What Bad Looks Like
- Quibi (2020): Over-engineered for scale that never came. Hundreds of millions were spent on infrastructure for a product that failed in the market within months.
- Friendster (2002): Under-engineered, unable to handle user demand, and ceded the market to MySpace and Facebook.
Wrapping up…
Avoiding over- and under-engineering is less about finding the perfect architecture and more about knowing when to evolve. Reid Hoffman, co-founder of LinkedIn, put it bluntly: “If you aren’t embarrassed by the first version of your product, you’ve launched too late.” But Hoffman also warns against ignoring scale signals once product-market fit is achieved.
The best engineering leaders learn to instrument, monitor, and project. They know when they’re skating too close to the edge—and when they’re wasting cycles on problems they don’t yet have.
In the end, the “right” platform isn’t the most elegant—it’s the one that keeps pace with the business, no faster, no slower.
