Got 1 Paying User. Time to Move to Kubernetes.
We’ve all seen it. You launch your MVP. One person swipes their card. And before the welcome email even goes out, you're knee-deep provisioning Kubernetes clusters, configuring Istio, setting up autoscaling groups, deploying multi-region failover, and writing 200 lines of YAML. Because, well, “what if TechCrunch writes about us tomorrow?” This post is for every builder who got caught in the overengineering trap. The joke is funny because it’s true. But the reality? You probably don’t need 90% of the tech you’re thinking about. Here’s why. The Danger of Premature Optimization Premature optimization is solving problems that don’t exist yet. It’s the engineering version of buying a 12-slice toaster when you live alone and don’t even eat toast. It feels productive. It feels smart. But often, it’s just disguised procrastination. You’re not scaling for real users — you’re scaling for a fantasy future. And worse: you’re spending time building scaffolding instead of the actual product. Instead of fixing onboarding, improving feedback loops, or talking to your users — you’re trying to debug a Docker networking issue caused by a service that doesn’t even have traffic yet. What You Actually Need at 1–100 Users Let’s be honest. At this stage, your app isn’t under pressure. No one is stress-testing your endpoints. Your biggest performance risk is forgetting an index, not a traffic surge. What you need right now is: A dead-simple app structure A Postgres database (or SQLite if you're feeling spicy) Something easy to deploy (Fly, Sliplane, Render, Cloudflare Workers, etc.) Logs, error tracking, and a way to see what’s breaking A way to collect and prioritize feedback from real users That’s it. This is the season of rapid learning, not scaling. You need to move fast, ship weekly, and iterate on what’s working — not what might break in a hypothetical future. Scaling Problems Are Good Problems If your product is struggling to stay online because traffic doubled overnight — congratulations. You’ve made it to the good problems. The worst kind of startup death is when nothing breaks because no one uses your app. Scaling should be a reaction to real usage — not a prediction based on hope. You don’t win by preparing for scale that never comes. You win by building something people use, love, and need. When that happens, scaling becomes justified, obvious, and even fun. How Far Can a Single Instance Actually Go? A lot farther than you think. Real-world examples: A $5 DigitalOcean Droplet: A friend ran a bootstrapped SaaS with thousands of monthly users and daily Stripe payments — all from a single VM running Rails + Postgres. Nomad List by levelsio: started as a single PHP file and SQLite database. Served thousands of users before scaling ever became a conversation. UserJot (what we’re building): A Node.js app with just Postgres. No Redis. No queue system. It handles thousands of feedback submissions, reactions, and comments with ease. Modern cloud hardware is absurdly powerful: A $25–$40/mo VM can get you 4–8 vCPUs, 8–16GB RAM Postgres can easily manage millions of rows and hundreds of concurrent users with proper indexing Monthly active users are not concurrent users — most of the time, your live load is in the dozens, not hundreds You are more likely to hit product confusion or churn before you hit infra limits. When You Actually Need to Scale Here’s how you know scaling is actually necessary: Your database CPU sits at 90% under normal load Pages start timing out during usage spikes You’re getting support tickets about slowness — not just once, but often You can’t ship features anymore without complex refactoring due to system constraints Until then? Keep it boring. Keep it simple. Keep shipping. A Simple Stack Will Take You Further Monoliths are underrated. They’re easier to test, easier to deploy, easier to debug, and easier to change. You don’t need to untangle five services, rebuild containers, push to three different repos, and pray CI doesn’t crash. You just... ship code. Here are examples of simple stacks that punch way above their weight: Node.js + Postgres — still our go-to for building fast, scalable products Rails or Laravel + SQLite/MySQL — works wonders for early-stage SaaS Cloudflare Workers + KV — surprisingly robust for small products Simple doesn’t mean weak. It means focused. Your goal is momentum, not architecture awards. Final Thought: Earn Your Scaling Problems Your product doesn’t need to be ready for 1 million users. It needs to be ready for 10 people who actually care. When your infra starts creaking under pressure, celebrate. You’ve hit the rare place where performance becomes a real, necessary, and rewarding problem to solve. Until then, keep things simple. Kubernetes will still be there when you’re ready. If you are building a product and looking for a way to collect and p
We’ve all seen it.
You launch your MVP. One person swipes their card.
And before the welcome email even goes out, you're knee-deep provisioning Kubernetes clusters, configuring Istio, setting up autoscaling groups, deploying multi-region failover, and writing 200 lines of YAML.
Because, well, “what if TechCrunch writes about us tomorrow?”
This post is for every builder who got caught in the overengineering trap. The joke is funny because it’s true. But the reality? You probably don’t need 90% of the tech you’re thinking about.
Here’s why.
The Danger of Premature Optimization
Premature optimization is solving problems that don’t exist yet. It’s the engineering version of buying a 12-slice toaster when you live alone and don’t even eat toast.
It feels productive. It feels smart. But often, it’s just disguised procrastination. You’re not scaling for real users — you’re scaling for a fantasy future.
And worse: you’re spending time building scaffolding instead of the actual product.
Instead of fixing onboarding, improving feedback loops, or talking to your users — you’re trying to debug a Docker networking issue caused by a service that doesn’t even have traffic yet.
What You Actually Need at 1–100 Users
Let’s be honest. At this stage, your app isn’t under pressure. No one is stress-testing your endpoints. Your biggest performance risk is forgetting an index, not a traffic surge.
What you need right now is:
- A dead-simple app structure
- A Postgres database (or SQLite if you're feeling spicy)
- Something easy to deploy (Fly, Sliplane, Render, Cloudflare Workers, etc.)
- Logs, error tracking, and a way to see what’s breaking
- A way to collect and prioritize feedback from real users
That’s it.
This is the season of rapid learning, not scaling. You need to move fast, ship weekly, and iterate on what’s working — not what might break in a hypothetical future.
Scaling Problems Are Good Problems
If your product is struggling to stay online because traffic doubled overnight — congratulations. You’ve made it to the good problems.
The worst kind of startup death is when nothing breaks because no one uses your app.
Scaling should be a reaction to real usage — not a prediction based on hope.
You don’t win by preparing for scale that never comes. You win by building something people use, love, and need. When that happens, scaling becomes justified, obvious, and even fun.
How Far Can a Single Instance Actually Go?
A lot farther than you think.
Real-world examples:
- A $5 DigitalOcean Droplet: A friend ran a bootstrapped SaaS with thousands of monthly users and daily Stripe payments — all from a single VM running Rails + Postgres.
- Nomad List by levelsio: started as a single PHP file and SQLite database. Served thousands of users before scaling ever became a conversation.
- UserJot (what we’re building): A Node.js app with just Postgres. No Redis. No queue system. It handles thousands of feedback submissions, reactions, and comments with ease.
Modern cloud hardware is absurdly powerful:
- A $25–$40/mo VM can get you 4–8 vCPUs, 8–16GB RAM
- Postgres can easily manage millions of rows and hundreds of concurrent users with proper indexing
- Monthly active users are not concurrent users — most of the time, your live load is in the dozens, not hundreds
You are more likely to hit product confusion or churn before you hit infra limits.
When You Actually Need to Scale
Here’s how you know scaling is actually necessary:
- Your database CPU sits at 90% under normal load
- Pages start timing out during usage spikes
- You’re getting support tickets about slowness — not just once, but often
- You can’t ship features anymore without complex refactoring due to system constraints
Until then? Keep it boring. Keep it simple. Keep shipping.
A Simple Stack Will Take You Further
Monoliths are underrated.
They’re easier to test, easier to deploy, easier to debug, and easier to change.
You don’t need to untangle five services, rebuild containers, push to three different repos, and pray CI doesn’t crash. You just... ship code.
Here are examples of simple stacks that punch way above their weight:
- Node.js + Postgres — still our go-to for building fast, scalable products
- Rails or Laravel + SQLite/MySQL — works wonders for early-stage SaaS
- Cloudflare Workers + KV — surprisingly robust for small products
Simple doesn’t mean weak. It means focused. Your goal is momentum, not architecture awards.
Final Thought: Earn Your Scaling Problems
Your product doesn’t need to be ready for 1 million users.
It needs to be ready for 10 people who actually care.
When your infra starts creaking under pressure, celebrate. You’ve hit the rare place where performance becomes a real, necessary, and rewarding problem to solve.
Until then, keep things simple. Kubernetes will still be there when you’re ready.
If you are building a product and looking for a way to collect and prioritize feedback from real users, check out UserJot. I would love to hear what you think.
