{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidgv3viqk2qexftpzc5qhszrbhtavvu5julrjj6zx2r7uscnenlua",
    "uri": "at://did:plc:5sgu76a53rz3n6unbykmovqy/app.bsky.feed.post/3miuzfkafnzq2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicjegbe3rjs3cgnhszdvxa57bm2nd7yqrbvjiqbs7ovm7zwz6fboa"
    },
    "mimeType": "image/jpeg",
    "size": 66640
  },
  "description": "Beautiful code. Clean architecture. Zero users. Most early-stage startups quietly die here, engineers solving problems three years too early while real users wait for something that simply works. ",
  "path": "/why-you-should-not-build-for-10-million-users-on-day-one/",
  "publishedAt": "2026-04-07T05:13:05.000Z",
  "site": "https://sahilkapoor.com",
  "tags": [
    "Why \"Monolith\" Became a Bad Word"
  ],
  "textContent": "Picture this.\n\nIt's Day 3 of your startup. You have zero users, a landing page that took four days to \"get right,\" and a Figma file your designer friend made as a favour. But your engineering team? Fully locked in. The whiteboard looks like a NASA mission control diagram. Kafka queues, auto-scaling Kubernetes pods, a read replica database in Singapore, and a separate microservice for _sending welcome emails_.\n\nSomeone in the room says, \"But what if we go viral?\" And just like that, three weeks are gone.\n\n_You realise that you are building an airport before proving people want to travel._\n\nThis is not a hypothetical. This is the founding story of dozens of startups that never made it past 500 users. Not because their idea was bad. But because their CTO was playing a different game entirely, one called _\"impress the senior engineers we haven't hired yet.\"_\n\n## The CTO Trap: Architecting for Prestige, Not Progress\n\nHere's a pattern that repeats itself with eerie consistency across early-stage startups: the most technically talented person in the room becomes the biggest bottleneck to shipping.\n\nEngineering leaders and CTOs, brilliant and well-intentioned, are wired by years of Big Tech experience to think in scale. At Google, you _have_ to think about billions of requests. At Amazon, eventual consistency is a survival skill. Those instincts make total sense at that scale.\n\nBut transplanted to a 4-person startup with 12 beta users? They become a liability.\n\nThe CTO spends a sprint debating SQL vs. NoSQL for a dataset that currently has 200 rows. The VP of Engineering insists on full CI/CD pipeline observability before the product has a single paying customer. The result: the business is bleeding runway while the infra is _immaculate_.\n\nThe technical debt conversation is real, but so is the **product debt** that silently piles up while engineers are busy optimising for a future that may never arrive.\n\n## A Founder's Confession: I Did This Too\n\nAs a technical founder, I constantly fell into this trap. It _felt_ like diligence but was actually avoidance.\n\nEvery time I sat down to build, my brain would drift. _What if this endpoint gets hammered? Should I cache this query? What if 50,000 concurrent users hit this at once?_ Hours would vanish into benchmarking and architectural debates before a single real user had signed up.\n\nThe brutal truth: **I was optimising for a problem I didn't have, while ignoring the problems my actual users were screaming about.**\n\n> _\"Premature optimisation is the root of all evil. The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times.\"_\n> **- Donald Knuth**\n\nYou think you're being a responsible engineer. But you're really hiding behind technical complexity to avoid the scarier work - the ambiguity, the user conversations, the imperfect first version that might actually teach you something.\n\n## Your First Job Is to Survive to 1,000 Users\n\nNobody has ever killed a startup by having a slow API at 80 users. They _have_ killed startups by spending 6 months building infrastructure instead of finding product-market fit.\n\nReframe the goal entirely:\n\n  * **0 to 100 users:** Does anyone actually want this?\n  * **100 to 1,000 users:** Can we retain them and understand why they stay?\n  * **1,000 to 10,000 users:** Now what breaks? Great. Fix those actual things.\n\n\n\nProblems at 10 million users are _phenomenal_ problems to have. You can hire engineers to fix them. You can raise a round on the back of them.\n\nProblems at 0 users are existential. No amount of elegant distributed architecture saves you from them.\n\n## Scale Assumptions Kill Product Intuition\n\nHere's a subtler damage that over-engineering does. It **disconnects you from your user.**\n\nWhen you build for millions, you stop listening to the 10 people in front of you. Every sharp edge that makes your product uniquely useful gets sanded off in the name of scalability. The weird workflow, the opinionated design, the scrappy feature that shouldn't work but somehow does - all gone.\n\nThe startups that _do_ reach 10 million users usually got there by being irrationally focused on a small group first. Airbnb went door-to-door photographing apartments. Stripe's founders personally integrated their API with early customers' codebases. They did unscalable things on purpose.\n\n> _\"Do things that don't scale. It's so important to get early customers that if you have to do a ton of manual stuff, that's okay. You'll learn a lot from it.\"_\n> **- Paul Graham, Y Combinator**\n\n## The Monolith Lesson Nobody Learns Until It's Expensive\n\nThe over-engineering instinct shows up most visibly in architecture choices. I've seen founders spin up 8 microservices before writing their first user-facing feature, each one a beautifully isolated monument to a scale they've never experienced.\n\nAs I wrote in Why \"Monolith\" Became a Bad Word, \"monolith\" became an insult not because monoliths are actually bad, but because the industry started associating them with legacy and laziness. Shopify served millions of merchants on a monolith for years. Amazon Prime Video migrated _back_ from microservices to a monolith and cut costs by 90%.\n\nThe real lesson: use boring technology. A Postgres database, a well-structured monolith, a simple job queue. **Optimise for speed of learning, not speed of serving.**\n\n## The Day CarInfo Crashed From Success\n\nNovember, 2016. We were three months into CarInfo. Eight thousand users a day, growing steadily, everything feeling under control.\n\nThen a journalist tweeted a photo of a politician. Our app was visible in the screenshot.\n\nBy the time we woke up and saw the notification pile, it had already happened. 10000 thousand downloads in a few hours, 50000 by the day ended. We hadn't pitched it, planned it, or prepared for it. A single tweet from someone we'd never met changed everything.\n\nBy end of day, the servers were down.\n\nHere's the part worth sitting with: **we hadn't over-engineered. We had under-provisioned.** And we still almost lost it all.\n\nThat moment taught me something more precise than \"build for scale.\" You can't predict the trigger. But you can build systems that recover fast. The goal isn't an architecture that never fails. It's one that fails gracefully and comes back quickly. And you only learn what that means by getting hit once.\n\nNo Kubernetes setup on Day 3 would have saved us. But having clean, simple infrastructure that we _understood completely_ meant we could fix it fast. A tangled microservice maze on month three would have been a disaster we couldn't debug under pressure, at 2am, with 50,000 people waiting.\n\n## When Scale Planning Actually Matters\n\nThat CarInfo story is also a reminder that this isn't a case against thinking about scale ever. Some domains genuinely need architectural thought from the start:\n\n  * **Fintech and health tech:** compliance, data residency, and audit trails are nearly impossible to bolt on later\n  * **Real-time systems:** chat, live collaboration, and streaming have structural constraints baked into their nature\n  * **Multi-tenancy:** if your B2B product will serve enterprise clients, data isolation matters before you sign your first contract\n\n\n\nThe rule of thumb: **plan for 10x your current load, not 10,000x.** Build the next rung of the ladder, not the entire skyscraper.\n\n## The Question That Actually Matters\n\nThe question that wasted my early months: _\"How do I make this fast?\"_\n\nThe question that changed everything: _\"What is this user actually frustrated by?\"_\n\nOne leads to Grafana dashboards and cache hit ratios. The other leads to the insight that changes your retention, your conversion, and eventually your entire business model.\n\nYou don't prove confidence by building for millions before you have hundreds. You prove it by shipping fast enough, learning fast enough, and staying close enough to your users to _earn_ the problem of scale.\n\nSo here's the challenge worth sitting with before your next sprint planning: _What are you over-building right now that your users will never notice?_",
  "title": "Why You Should Not Build for 10 Million Users on Day One",
  "updatedAt": "2026-04-07T05:13:07.775Z"
}