Meta Description: A founder runs multiple profitable SaaS companies spending just $20/month on infrastructure. Here's the lean tech stack playbook — single VPS, Go, SQLite, and local AI.
The Bootstrapper's Dilemma
Here's a story that sounds familiar: a founder walks into a pitch meeting. They have real users, real MRR, real product traction. The VC's response? "What do you even need funding for?"
That's exactly what happened to Steve Hanov — the creator of websequencediagrams.com and several niche SaaS products. His costs are so low that VCs can't figure out what to fund. And that's the point.
In 2026, the default startup playbook says: spin up AWS, provision EKS clusters, configure RDS instances, set up NAT Gateways, and accidentally burn $300/month before your first user even loads the landing page. The lean playbook says: rent a $5 VPS, compile a static binary, ship it.
One approach buys you a maze of managed services. The other buys you infinite runway.
The $20/Month Stack, Deconstructed
Hanov's approach isn't about being cheap for its own sake. It's about keeping the architecture so simple that you spend your time solving user problems instead of debugging infrastructure. Here's what the stack looks like:
One Server, One Binary
No Kubernetes. No container orchestration. No microservices talking to microservices. A single VPS from Linode or DigitalOcean at $5-10/month. 1GB of RAM with a swapfile if needed.
The backend? Written in Go, compiled into a single statically-linked binary on a laptop, SCP'd to the server, and run. No dependency hell, no virtual environments, no pip install nightmares. The deployment process is literally:
GOOS=linux go build -o app .
scp app root@yourserver:/opt/app/
ssh root@yourserver 'systemctl restart app'
A basic Go HTTP server handles tens of thousands of requests per second on potato hardware. No framework required.
SQLite Over Postgres
This is the part that makes most developers flinch. SQLite — in production? For a real SaaS?
Yes. And here's why it works:
- A local
.dbfile communicating over the C-interface is orders of magnitude faster than making a TCP network hop to a remote Postgres server - Enable Write-Ahead Logging (WAL) with two pragmas, and readers don't block writers, writers don't block readers
- On an NVMe drive, a single SQLite file handles thousands of concurrent users
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
The enterprise mindset says you need an out-of-process database server. The lean mindset says: your database is a file on a disk, and that's a feature, not a bug. No connection pooling, no network latency, no separate server to manage and monitor.
Local AI Instead of API Bills
This is where it gets really interesting. Hanov runs batch AI workloads — deep stock market research, summarizing thousands of quarterly reports — on a used RTX 3090 bought from Facebook Marketplace for $900. No OpenAI API bills. No rate limits. No "logic bug in my prompt loop that cost me $200 before I noticed."
The upgrade path is pragmatic:
- Start with Ollama — one command to spin up any model, perfect for iterating on prompts
- Move to vLLM for production — PagedAttention makes it dramatically faster for concurrent batch requests. Send 16 async requests and they all finish in roughly the time of one
- Transformer Lab for fine-tuning — when you need to customize models on local hardware
For frontier model tasks that can't run locally (user-facing chat, complex reasoning), he uses OpenRouter as a single API gateway to every major model. One integration, automatic fallback routing — if Anthropic goes down, it falls back to OpenAI. Users never see errors.
The Copilot Hack
Here's a detail that resonates with any developer watching their AI tooling costs: Hanov uses a standard GitHub Copilot subscription (~$10-20/month) plugged into vanilla VS Code. Not Cursor. Not Windsurf. Not a $200/month API habit.
The trick: Copilot charges per request, not per token. So a brutally detailed prompt that tells the agent to "keep going until all errors are fixed" while it spends 30 minutes chewing through an entire codebase still costs roughly $0.04. Write good prompts with strict success criteria, hit enter, and let Microsoft subsidize your compute.
Why This Matters in 2026
The timing of this playbook matters. Three trends are converging:
AI has collapsed the cost of building. A solo founder with good prompting skills and a $5 server can now build what took a 5-person team two years ago. The bottleneck isn't engineering capacity — it's finding the right problem.
VCs are asking harder questions about burn. The zero-interest-rate era of "growth at all costs" is over. Investors want to see capital efficiency. A founder who can demonstrate $10K MRR on $20/month infrastructure has a fundamentally different conversation than one burning $50K/month on AWS.
Simple stacks survive longer. Every abstraction layer you add is a maintenance burden. Every managed service is a potential single point of failure and a definite line item. A single server with a single binary and a single database file is boring — and that's exactly why it works.
The Real Lesson: Constraints Create Focus
Hanov's stack isn't just about saving money. It's about what happens when you remove infrastructure as a variable:
- You know exactly where your logs are — they're on the one server
- You know exactly why something crashed — it's the one binary
- You know exactly how to fix it — restart the one process
- You have infinite runway — $20/month means you can iterate for years
The traditional startup playbook optimizes for scale that hasn't arrived yet. The lean playbook optimizes for survival and learning. When you're pre-product-market-fit, survival and learning are the only metrics that matter.
You can always migrate to Kubernetes later, when you actually have the traffic that justifies it. But you can't undo the months of infrastructure complexity you built "just in case."
When Lean Stops Working
To be fair — this approach has limits. The $20/month stack works beautifully up to a point. When you need:
- Multi-region redundancy for enterprise SLAs
- Complex relational queries across millions of rows
- Real-time collaboration features (CRDTs, WebSockets at scale)
- SOC 2 compliance and audit trails
...you'll eventually need to graduate beyond a single VPS and SQLite. But that's a good problem to have, and by the time you have it, you'll have the revenue to solve it properly.
The mistake is pre-optimizing for scale you haven't earned yet.
Conclusion
Steve Hanov's $20/month stack is a reminder that the tech industry's default complexity is a choice, not a requirement. You can build real businesses — profitable ones — on simple, boring infrastructure.
A single VPS. A Go binary. SQLite with WAL. Local AI for batch work. OpenRouter for frontier models. Copilot for coding.
Total cost: less than a Spotify subscription.
The question isn't whether this stack can scale to millions of users. The question is: do you need to scale to millions of users before you've found ten who love your product?
Start lean. Graduate when the data tells you to. And enjoy the infinite runway.
FAQ
Q: Can SQLite really handle a production SaaS with thousands of users? A: Yes, with WAL mode enabled. SQLite with Write-Ahead Logging allows concurrent reads and writes without blocking. On NVMe storage, it handles thousands of concurrent connections. It's used in production by companies like Turso and Fly.io for their own infrastructure.
Q: What's wrong with using AWS for a new startup? A: Nothing is wrong with AWS — but it encourages over-engineering from day one. Managed services, EKS clusters, and RDS instances add up fast ($300+/month before your first user). A $5 VPS forces you to keep things simple and gives you the same runway as a $1M seed round with a high burn rate.
Q: How do you handle database backups with SQLite?
A: SQLite backups are just file copies. You can use the .backup command for consistent snapshots, or simply copy the .db file during low-traffic periods. Combine with S3 or any object storage for offsite backups — still well under $20/month total.
Q: Is local AI really practical for production workloads? A: For batch processing — research, summarization, data extraction — absolutely. A used RTX 3090 ($900 one-time) running vLLM can process thousands of inference requests without per-token API costs. For real-time user-facing features, you'd still want a cloud API for latency reasons.
About the Author: Arkin is a software engineer and startup founder building Orbits Studio. He writes about lean engineering, indie hacking, and building products without the enterprise bloat. Find him at arkin-dev.com.