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 archite...
For further actions, you may consider blocking this person and/or reporting abuse
"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.
I am testing a SAAS product on a $3.5 plan I bought at vultr. Be wise
Discount code for the first 10 users
Code
RUXE37H
Discount
50%
Bold and refreshing—this shows that with smart architecture and discipline, you can challenge assumptions and build efficient, sustainable SaaS systems.
You identified the key ingredient: Discipline.
It is actually much harder to maintain a simple architecture than a complex one because the industry constantly pushes you toward adding "just one more service."
Sustainable systems are exactly the goal here, both financially and technically. Thanks for reading.
Great article
Thank you! Im glad you liked it!
Nice and clear explanation!
Thank you! Im glad you liked it.
This is so useful! Because the high costs of renting infrastructure these days is absurd, especially if you have a startup with zero customers at the beginning. Will definitely save this for later. Thank you for sharing