We have normalized paying $100/month for infrastructure before acquiring a single customer. It is time to return to the $5 VPS. Here is the architecture.
We need to talk about the cost of "Modern Web Development."
If you follow the standard tutorial for building a SaaS in 2026, your bill looks something like this on Day 1:
**Hosting (Vercel/Netlify): $20/month per seat
Database (Supabase/Neon): $25/month (once you hit the first limit)
Auth (Clerk/Auth0): Free tier, then expensive quickly
Redis (Upstash): Usage-based pricing**
Before you have even validated your idea or processed your first Stripe payment, you are looking at a recurring burn rate of $50–$100/month.
For a funded startup, this is a rounding error. For an indie hacker or a solo developer, this is death by a thousand cuts.
I spent the last few months architecting a way out of this trap. I wanted to see if I could build a fully functional, production-ready SaaS stack that runs entirely on a single $5/month VPS.
The answer is yes. And it is faster than the cloud.
The Architecture of Independence
The goal was simple: Zero Vendor Lock-in.
To achieve this, we have to fire the managed services and bring the logic back home. This is the stack that makes it possible:
1. The Database: SQLite (Local)
We have been gaslit into thinking we need a distributed database cluster for a todo-list app. We don't.
SQLite in WAL (Write-Ahead Logging) mode can handle thousands of concurrent writes per second. Because the data lives on the same NVMe drive as your application, query latency drops from 50ms (cloud) to 0.1ms (local).
The Backup Strategy:
The fear of SQLite is "What if the server dies?". The solution is Litestream. It streams your database changes to S3-compatible storage in real-time. If your $5 server melts, you restore your data to a new server in seconds.
2. Authentication: Better-Auth
Identity management has become a massive industry. But for 99% of apps, we just need secure sessions and OAuth.
Libraries like Better-Auth allow us to own our user data. It lives in our SQLite database, not in an external tenant. No per-user monthly fees.
3. Deployment: Docker & Nginx
This is the part most developers fear, and why they pay Vercel. Setting up a Linux server, configuring Nginx as a reverse proxy, and managing SSL certificates (Let's Encrypt) feels like "Ops work."
But once you have a docker-compose.yml file configured correctly, deployment becomes boring. You push code, a GitHub Action builds the container, and the VPS pulls it down.
Why This Matters
This isn't just about saving $50 a month. It is about Runway.
If your project costs $5/month to run, you can keep it alive forever. You can afford to wait for product-market fit. You can host 10 different failed experiments on the same server without paying a cent more.
If your project costs $100/month, you are on a clock. You shut it down if it doesn't make money immediately. High infrastructure costs kill innovation.
The Solution
I realized that the barrier to entry wasn't the code, it was the configuration. Setting up the Nginx proxy, the automated backups, and the Docker networking is tedious.
So, I packaged my entire architecture into a starter kit.
I call it The Boring SaaS Starter Kit.
It includes everything you need to deploy a Next.js 15 app with Stripe, Auth, and SQLite to a VPS in about 5 minutes.
Full Source Code: Next.js 15, Drizzle ORM, Tailwind.
Infrastructure: Production-ready Docker Compose setup.
Payments: Stripe integration with Webhooks handling.
Guide: A step-by-step manual for deploying to Hetzner or DigitalOcean.
Conclusion
You don't need a cloud budget to build software. You need a Linux server and the courage to manage your own stack.
Stop renting your infrastructure. Own it.
Top comments (39)
"You don't need a cloud budget to build software. You need a Linux server and the courage to manage your own stack." - hell yeah brother! 💯 nice article
Appreciate the support, Aaron. That specific line seems to be resonating with a lot of people.
The technical part isn't actually that hard; it is the mental hurdle of taking responsibility for the server that stops most developers. Once you cross that bridge, you never go back.
This really resonates. As someone building with Next.js, I’ve felt how “modern” stacks quietly lock you into a burn rate before PMF. Owning the stack with SQLite, Docker, and a VPS isn’t going backward—it’s thoughtful engineering and long-term leverage.
You hit on a crucial point with "long-term leverage." There is often a stigma that moving away from managed services is "going backward," but in reality, it is about regaining control of your unit economics.
If your burn rate is low, you have more time to find PMF. That is the ultimate leverage.
Love this approach! It’s refreshing to see a return to simplicity and ownership in a time where cloud services are often over-engineered for small projects. The $5 VPS is a game changer for solo developers or indie hackers, great for keeping costs low and ensuring long-term sustainability. The Boring SaaS Starter Kit sounds like a perfect way to get up and running quickly without the typical cloud pricing trap. Really inspiring!
Thanks, Sophia. I am glad to hear the philosophy resonated with you.
Simplicity is underrated. For solo developers, low overhead isn't just about money; it is about cognitive load. If you own your stack and it costs next to nothing, you can afford to play the long game. That sustainability is exactly what I wanted to unlock with the kit.
This is such a real-world take on SaaS economics — most guides focus only on scaling up, but thinking about exit strategy and cost control from day one is incredibly valuable. Loved how you broke down actionable ways to run a production service on a shoestring without compromising reliability. Thanks for sharing these practical insights!
Glad to hear that resonated. The industry obsession with scaling often obscures the immediate reality of survival.
For bootstrapped founders, extending the runway is infinitely more important than preparing for a million concurrent users. Low burn rate buys you the time you need to actually find product-market fit.
I'll stick to my $7/mo pg instance and usage-based cloud run instance all day. Saving those precious hours for actual development over devops setup seems like a better use -- especially when it would only come out to a $~5/mo difference.
That is a totally valid trade-off. If you are building a single revenue-generating app, the price difference is negligible compared to the value of your time.
The math shifts primarily when you are shipping multiple experiments. Hosting 5 different apps on managed services adds up quickly, whereas on a VPS, the marginal cost of the next app is zero. I also prefer the peace of mind of a capped bill versus usage-based billing during traffic spikes.
You had me at *Cloud Exit Strategy * 🙌
I'm glad you liked it!
This resonates hard, because the real problem here isn’t cost — it’s psychology.
We’ve normalized outsourcing understanding along with infrastructure. Vercel, managed DBs, hosted auth — they’re sold as “focus on product,” but what they really buy you is avoidance. Avoidance of ops, of failure modes, of actually knowing where your data lives and how requests move.
What I like about this post is that it reframes the $5 VPS not as nostalgia, but as leverage. SQLite + WAL + local IO isn’t some contrarian stunt — it’s aligning architecture with reality: most early-stage SaaS apps are not Google-scale, they’re idea-scale. Paying for distributed systems before you have distribution is backwards.
The runway point is the killer insight. High infra cost quietly forces premature decisions: kill ideas too early, optimize for monetization too soon, chase scale before signal. A cheap, boring stack buys you time, and time is the only thing that actually compounds in early product work.
Also appreciate calling out the real tax: configuration, not complexity. Most devs aren’t scared of Linux — they’re scared of the first time something breaks at 2am. Packaging the boring, repeatable parts is honestly more valuable than another “modern” stack tutorial.
This isn’t anti-cloud. It’s anti-defaults.
Cloud should be a choice, not a rite of passage.
Owning your stack changes how you think — about cost, about scale, and about responsibility. And yeah… boring infrastructure is usually the most honest kind.
This might be the most insightful comment I have read on this topic. "Outsourcing understanding" is a brilliant way to phrase it.
We often trade money for the privilege of not knowing how our requests are actually handled. That ignorance eventually becomes a liability when things break.
And the line "Paying for distributed systems before you have distribution is backwards", I might have to steal that. It perfectly summarizes the misalignment in the industry right now. The stack should match the stage.
This is exactly the mindset I love ! Thank you very much for making me smile while reading your article / post.
You are doing it right.
Credit goes to you 100%
Keep going you are on the right track
Thank you, Ali. I really appreciate that.
It is easy to get swept up in complexity, but usually, the simple path is the right one. Glad the post resonated with you.
It was an education 🤤
That is the best kind of feedback. My goal is simply to share the lessons I learned the hard way so others don't have to repeat the same mistakes. Happy building.
If you ever want to try it out i have a discount code for 50%.
I wanted to write : this is the way
(Reference to Mandolorian) but figured it might make more sense to not say it here ;)
Thank you for offering. I will keep it in mind
I caught the reference immediately. In the world of self-hosting and owning your infrastructure, "This is the way" feels like the appropriate motto.
The offer stands. If you decide to go down the VPS route and hit a wall, feel free to reach out.
Hi, could I use postgresql or supabase ? Tx
Yes, absolutely. Since the kit is built on Drizzle ORM, swapping the database provider is very straightforward.
You would simply need to change the database driver in the config from better-sqlite3 to postgres-js and add your Supabase connection string. The rest of the application logic (Auth, Stripe) works the same way.
I defaulted to SQLite to keep the entire stack self-contained on one server, but if you prefer managed Postgres, the code adapts easily.
With this I can build 20 different apps and let any of them monetize!!!
That is exactly the goal. The marginal cost of your second, third, or twentieth app is effectively zero.
It changes the strategy from "I hope this one works" to "I can afford to fail 19 times to find the one that works." That volume of experimentation is the cheat code for finding product-market fit.
I am interested working on libraries as this. Let me know if I could be of any help.
Appreciate the offer, Hafiz. Right now, the starter kit is a solo commercial project, so I am keeping the core development internal to ensure stability for customers.
However, the ecosystem around this stack (Litestream, Better-Auth) is open source and always looking for help. If you build something specific using this architecture, definitely let me know.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.