Hanov demonstrates with real revenue numbers that multiple $10K MRR SaaS products can run on a single VPS costing $20/month. His approach uses SQLite or PostgreSQL, server-side HTML rendering, and no container orchestration, Kubernetes, or serverless — proving that right-sizing infrastructure to actual business needs dramatically reduces costs without sacrificing functionality.
The editorial argues that AWS bills routinely consume 20-30% of revenue for early-stage companies, and that the 'scale-ready' architectures promoted by engineering blogs amount to paying enterprise prices for startup-scale traffic. Hanov's $20/month figure serves as a pointed provocation against an industry norm where most startups spend more on observability tools like Datadog than he spends on his entire stack.
The editorial is careful to note this isn't about running the next Stripe on a Raspberry Pi. The businesses in question are modest but profitable solo-developer products — the kind with low concurrent user counts where a single well-configured server can handle thousands of requests per second. The implication is that the approach has clear boundaries around product scale and complexity.
Steve Hanov published a detailed breakdown of the technology stack powering his portfolio of SaaS businesses, each generating around $10,000 in monthly recurring revenue. The punchline: his total infrastructure spend is approximately $20 per month. The post hit the front page of Hacker News, collecting 589 points and hundreds of comments, reigniting one of the oldest debates in software engineering — how much infrastructure do you actually need?
Hanov's approach is aggressively simple. He runs his applications on a single VPS (likely a modest Hetzner or DigitalOcean instance), uses SQLite or PostgreSQL for persistence, renders HTML server-side, and skips the entire modern web platform stack — no container orchestration, no managed Kubernetes clusters, no multi-region failover, no serverless functions, no separate CDN layer for API responses. His total infrastructure cost is less than what most startups spend on their Datadog bill alone.
The businesses themselves are modest but profitable — the kind of products that a solo developer can build, maintain, and support without a team. This isn't a story about running the next Stripe on a Raspberry Pi. It's about right-sizing infrastructure to actual business needs.
The timing of this post isn't accidental. Cloud infrastructure costs have become a genuine strategic concern for startups. AWS bills routinely consume 20-30% of revenue for early-stage companies, and the "scale-ready" architecture that engineering blogs promote often amounts to paying enterprise prices for startup-scale traffic. Hanov's $20/month figure is a provocation — but it's a provocation backed by real revenue numbers.
The core argument is that most SaaS products will never serve enough concurrent users to justify the complexity of distributed systems. A single well-configured server with a competent database can handle thousands of requests per second. For a B2B SaaS tool charging $50-200/month per seat, you might need only a few hundred active users to hit $10K MRR. That's not a load problem — that's a Tuesday afternoon for a $6/month VPS.
The Hacker News discussion broke predictably along experience lines. Indie developers and bootstrappers saw immediate validation: they've been quietly running profitable businesses on simple stacks for years, but the industry's default advice pushes them toward Kubernetes clusters and microservice architectures designed for companies with 50-person platform teams. Several commenters shared similar setups — single-server deployments running Rails, Django, or Go applications that serve thousands of paying customers without breaking a sweat.
Platform engineers and infrastructure specialists pushed back, and their objections aren't trivial. What happens when that single server's disk fails at 3 AM? Where are the backups? What about compliance requirements that mandate multi-region availability? How do you handle zero-downtime deployments? These are legitimate concerns, but they're also concerns that primarily matter at a scale most $10K MRR businesses will never reach. The counterargument writes itself: you can buy a lot of manual recovery time with the $980/month you're saving by not running on AWS EKS.
There's also a subtler point that got less attention in the thread: operational simplicity isn't just cheaper — it's faster. When your entire stack is one server running one process talking to one database, debugging is trivial. There's no distributed tracing needed because there's nothing distributed. There's no service mesh to misconfigure. The cognitive overhead of understanding your production environment drops to near zero, which matters enormously when you're also the product manager, designer, support team, and marketing department.
If you're building a new SaaS product today, the honest question to ask yourself isn't "how will this scale to a million users?" It's "what's the simplest thing that could work for my first 500 paying customers?" For the vast majority of B2B SaaS products, a single VPS with a relational database and server-rendered pages is not just adequate — it's optimal.
The practical playbook looks something like this: start with a $5-20/month VPS from Hetzner, DigitalOcean, or Vultr. Use PostgreSQL or SQLite. Render HTML on the server — if you need interactivity, sprinkle in htmx or Alpine.js rather than shipping a full React SPA. Set up automated daily backups to object storage (another $1-2/month). Use a simple deployment script that SSHs into the box, pulls the latest code, runs migrations, and restarts the process. This entire setup can be built and understood by one person in an afternoon.
The key caveat: this approach works for products where downtime is measured in minutes, not milliseconds. If your SaaS handles financial transactions, medical data, or real-time collaboration at scale, you'll eventually need more infrastructure. But "eventually" is the operative word. Too many founders build for the company they hope to become rather than the company they are, and the complexity tax on premature architecture is paid in shipping speed, not just dollars.
It's also worth noting what Hanov doesn't mention: the hidden costs of simplicity. A single-server architecture means you are the on-call rotation. Database tuning, OS updates, security patches — all of these fall on you. Managed services exist because operations work is real work. The $20/month stack is really $20/month plus your time, and your time has value. For a solo founder whose alternative is not building the product at all, that trade-off is obvious. For a funded startup with a team, the calculus shifts.
The pendulum between simplicity and complexity in software infrastructure swings on roughly a 5-7 year cycle. We're currently in the early stages of a simplicity swing — driven by rising cloud costs, the maturity of single-server tools, and a generation of developers who watched venture-backed companies burn through millions on infrastructure for products that never found market fit. Hanov's $20/month stack isn't a universal prescription, but it's a useful benchmark: if your infrastructure costs more than your revenue, you have an architecture problem, not a scaling problem.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.