Most stacks are designed for scale.
Mine isn’t.
It’s designed to stay simple.
Not because scaling doesn’t matter, but because I’m not there yet. And more importantly, because I don’t want to spend time maintaining infrastructure I don’t need.
I don’t avoid infrastructure. I avoid owning it.
The constraint
I build solo.
Projects are small to medium in scope. Some are experiments, some are products, some are freelance work.
None of them require complex infrastructure.
So the goal is not flexibility or completeness.
It’s:
- minimal setup
- low maintenance
- fast iteration
- something I won’t abandon in three months
That rules out a lot of things by default.
Frontend and hosting
For product work, I use Next.js with Vercel.
It gives me everything I need:
- frontend
- API routes when necessary
- deployment without setup
Push to GitHub, it’s live.
That’s the level of complexity I want.
For my own site, I go even simpler.
Astro with GitHub Pages and Cloudflare Workers.
Static by default. Minimal moving parts. Cheap to run.
No reason to make that more complicated.
Auth and database
Firebase for both.
Auth and Firestore cover:
- user accounts
- data storage
- real-time updates when needed
No separate backend. No ORM. No migrations.
It’s not the most flexible setup, but it removes more problems than it creates.
That’s the trade I want.
CI/CD
I keep this minimal, but I don’t avoid it.
For web projects:
- Vercel handles deployments
- GitHub Actions runs simple workflows when needed
Build, test, deploy. No complex pipelines.
For iOS:
- Xcode Cloud handles builds, tests, and distribution
All of this follows the same rule:
Use managed systems where possible. Keep custom logic minimal.
Monitoring
Very little.
UptimeRobot for basic checks.
Some logs when needed.
No dashboards, no alerting systems, no observability stack.
At this scale, I don’t need them.
Costs
Almost zero.
- hosting → free tiers
- Firebase → free at this scale
- Vercel → free for what I use
The only real costs are:
- Apple Developer account
- tools
This is intentional.
I don’t want infrastructure cost to shape decisions.
What I didn’t choose
I’ve used AWS and GCP before.
They’re powerful.
They’re also unnecessary for what I’m doing.
Same with:
- Kubernetes
- custom backend infrastructure
- complex CI/CD setups
All of these make sense at a certain scale.
But introducing them early just creates overhead.
That’s the same pattern I wrote about in When Not to Use Kubernetes.
When this breaks
This stack won’t hold forever.
It breaks when:
- backend logic becomes complex
- data grows significantly
- multiple services need coordination
At that point, more structure makes sense.
But until then, adding it early just slows things down.
Closing
This is not the best stack.
It’s the simplest one that covers everything I actually build.
That’s enough.
And more importantly, it stays out of the way.
