Stop Building for 'Scale.' You Don't Have Users Yet.

Authored by Shayan

I once spent six arduous months crafting the "perfect" architecture for my inaugural project. It boasted Redis for caching, Kafka for event streaming, multiple database replicas, load balancers, and auto-scaling groups – an infrastructure built to accommodate millions of users. The reality? We attracted a mere 12.

Those six months were consumed by setting up infrastructure rather than delivering value to users. It was a harsh lesson: nobody actually wanted what we had meticulously built.

Here's an uncomfortable truth many refuse to acknowledge: most of us design for a scale we'll likely never achieve, solving problems that don't exist, and optimizing for non-existent traffic.

The "But What If We Go Viral" Trap

Every significant technical decision often begins with the daunting question: "But what if we need to scale?"

• What if we land on the front page of Hacker News?
• What if we suddenly have 100,000 concurrent users?
• What if our database can't handle the immense load?

As "reasonable" engineers, we prepare. We integrate Redis because "caching is crucial." We deploy Kafka because "event-driven architecture is the future." We set up multi-region deployments because "global users expect low latency." We add Elasticsearch because "search must be lightning-fast."

Meanwhile, our actual metrics tell a different story:

• Daily active users: 3 (you, your co-founder, your mom)
• Database queries per second: 0.1
• Server CPU usage: 2%
• Cache hit rate: 0% (because there's nothing to cache)

Real Companies That Scaled Without the Circus

Consider these potentially sobering figures:

• WhatsApp managed 450 million users with just 32 engineers, relying on Erlang and FreeBSD, not Kafka or a Redis cluster.
• Basecamp thrives on a monolith. They've been profitable for decades, generating millions in revenue with only a handful of servers and no multi-region deployment.
• Stack Overflow handled 10 million daily visitors on merely 9 web servers – not 90 or 900. They operated without a CDN for years.
• SQLite powers an astonishing 35% of all websites. It's a file-based database that could fit on a floppy disk, not Postgres or MySQL.

These aren't struggling startups; they are massive operations running on what many architects would dismiss as "legacy" or "unscalable" technology.

The Actual Cost of Premature Scaling

Building for scale before you have users comes at three significant costs:

The Money Cost

You will inevitably overpay for infrastructure you don't yet need. While this might be affordable, it's rarely the primary issue.

The Time Cost

Every piece of infrastructure added exponentially increases complexity. A simple user signup can transform into a distributed systems problem:

1. Check Redis cache for existing user
2. Write to primary database
3. Replicate to read replicas
4. Send event to Kafka
5. Process event in a separate service
6. Update search index in Elasticsearch
7. Invalidate relevant caches
8. Sync to backup region

What could be a single SQL INSERT statement becomes a multi-step distributed system challenge.

The Opportunity Cost

This is the most critical cost. While you're meticulously setting up your third AWS availability zone, your competitor is shipping ten new features. While you're debugging Kafka message drops, they're engaging with customers. While you're optimizing Elasticsearch queries that run twice a day, they've simply used Postgres full-text search and moved forward.

I observe this constantly with UserJot users. The successful ones rapidly deploy simple features. Those who struggle are still locked in debates over Redis versus Memcached.

When You Actually Need to Scale

Here's a straightforward test. You should only begin to consider scaling when:

• Your server response times are consistently above 500ms.
• Your database queries are demonstrably slow (measure them first!).
• You're spending over $100/month on a single server that is consistently maxed out.
• You have actual users actively complaining about performance.

Notice what is explicitly not on this list:

• "It might be slow someday."
• "What if we go viral?"
• "Best practices say we should."
• "Netflix does it this way."

The Architecture That Actually Scales

Want a secret? The easiest architecture to scale is the simplest one.

Start with this:

• One server (using Rails, Django, Node, or your preferred framework)
• One database (Postgres is an excellent choice)
• A straightforward deployment process (e.g., git push to deploy)

This basic setup can comfortably handle your first 10,000 users, and likely your first 100,000 if your application isn't inherently resource-intensive.

When you genuinely encounter limitations, follow this process:

1. Measure what is actually causing the slowdown.
2. Fix that specific bottleneck.
3. Repeat.

This might mean selectively adding Redis for specific caching needs (after proving its necessity). It might involve a read replica for reports (after queries genuinely become slow). It could mean offloading image processing to a background job (after it actually blocks requests).

Crucially, these additions should be made in response to real problems, not hypothetical ones.

What This Looks Like in Practice

When I developed UserJot, I deliberately went against much of what I'd learned as an engineer. My stack was intentionally minimalist: no Redis, no message queues, no multiple databases, no global CDN, no multi-region setup. Just the simplest possible version.

The entire stack comprises:

• TypeScript and Postgres
• Everything behind Cloudflare
• One repository
• One deployment

That's it. And it has performed exceptionally well.

This streamlined setup handles:

• User authentication
• Payments through Stripe
• Email sending
• File uploads
• Real-time updates (using Postgres LISTEN/NOTIFY, not Redis pub/sub)
• Background jobs (using Postgres as a queue, not RabbitMQ or Kafka)
• Full-text search (using Postgres, not Elasticsearch)
• Vector search for similar feedback (using pgvector, not a separate service)

No Redis (Postgres can cache query results). No Kafka (Postgres can handle events). No Elasticsearch (Postgres offers robust full-text search). No separate databases for different data types (Postgres efficiently manages JSON, vectors, and relational data).

When a slowdown occurs, we measure it, fix it, and move on. We never preemptively add services based on speculative future needs.

The Uncomfortable Truth About Your Scale

The harsh reality for most of us is that we will never need to scale beyond a single server. Even many successful businesses operate on surprisingly straightforward infrastructure.

If you're building a SaaS product, roughly 1,000 paying customers are needed to generate a decent income. Most single servers can comfortably accommodate 10,000+ users without breaking a sweat.

You are, quite literally, optimizing for a problem you would be fortunate to even have.

How to Build Without the Scale Obsession: A Playbook

Here's my current playbook, forged through hard-earned experience:

• Week 1-2: Prototype

  • SQLite for the database (yes, really!)
  • Use your most familiar framework.
  • Deploy on the simplest platform (Railway, Render, or any free-tier service).
  • No Redis, no queues, no complex additions.

• First 100 Users:

  • Migrate to Postgres if necessary.
  • Implement basic monitoring (uptime is sufficient).
  • Focus entirely on achieving product-market fit.
  • Still no Redis, still no queues.

• First 1,000 Users:

  • Add error tracking.
  • Consider Redis only if you identify a specific bottleneck (measure first!).
  • Start thinking about backup strategies.
  • One region is typically still adequate.

• First 10,000 Users:

  • Now you can begin to consider more advanced architecture.
  • You have revenue to fund infrastructure investments.
  • You have real usage patterns to guide optimization efforts.
  • Perhaps now that cache layer becomes genuinely necessary.

The Permission You Need to Hear

• You don't need Redis yet.
• You don't need Kafka.
• You don't need Elasticsearch.
• You don't need multiple databases.
• You don't need multi-region deployment.
• You don't need a CDN for your 50 users.
• You don't need horizontal scaling.
• You don't need database sharding.

What you do need is to ship something people want.

All that complexity you're adding isn't insurance against future problems; it's a guarantee of present ones.

My Challenge to You

For your next project, try this:

• Employ the most "boring" stack you know.
• Deploy everything on a single server.
• Utilize a single database for all your data.
• Refrain from adding anything until you genuinely encounter an actual limit.

I promise you'll ship faster, spend less money, and quite possibly never even reach those limits anyway.

Building simply makes it easier to scale when the time actually comes. Paradoxically, the complex architectures we design for theoretical scale often hinder real scaling due to their multitude of interdependent parts.

And if you need a feedback board to truly engage with the users you're building for (instead of just imagining scaling problems), I'm developing UserJot for precisely that purpose. It's a simple tool, built on simple infrastructure, designed to do exactly what's needed.

Stop building for scale. Start building for users. The scaling challenges will resolve themselves if you're fortunate enough to encounter them.