The Boring Stack I Reach For on Every Side Project

I've been writing software for about 15 years now, and I've got a long list of side projects to show for it. Hikari, getgoodr, AnimeGuesser, imablank, NAJ Times, and plenty more that never made it past a prototype. If there's one thing all of that taught me, it's this: the framework was never my bottleneck. Finishing was.

So at some point I stopped chasing new tools and started reaching for the same boring stack every single time. And I mean boring as a compliment.

WHY BORING WINS

Every new library, every clever pattern, every "this will change how you build" tool is also a decision. And decisions are exactly what kill side projects. When you're working on something in the cracks of your week, you don't have the energy to relearn navigation or debate state management. You have maybe an hour, and you want to spend it on the actual idea.

Boring tools are the ones I already know cold. I don't have to think about them, so all my thinking goes into the thing I'm actually trying to build. That's the whole trick.

MY DEFAULT STACK

Here's what I reach for now, more or less without thinking:

• Next.js with TypeScript as the default. It's the web app and the API in one place, and it's the same framework across nearly everything I build.
• Expo and React Native with Expo Router when a project needs a mobile app, usually sharing types and logic with the web side rather than rebuilding them.
• PostgreSQL on Neon for the database. It's serverless Postgres that's quick to spin up and scales down to nothing when an app is idle, and it's the thing that replaced my old reach-for-Supabase reflex.
• Prisma as the ORM most of the time, with Drizzle when I want something lighter. Either way, the database schema is the single source of truth and the types flow out from there into the rest of the app.
• Auth.js, formerly next-auth, for authentication, with better-auth as the occasional alternative when a project calls for it.
• Tailwind for styling, React Query for data fetching, and Zod for validation, so I'm not reinventing any of them for an app only I might use.
• Vercel for web hosting and deploys, and EAS for the mobile builds and submissions.

None of that is exciting. That's the point. These are after-work projects, so the window is small. Once the kids are asleep, it's go time, and this stack is what gets me from idea to actually building before bed.

WHAT I DELIBERATELY DON'T DO

Just as important is the list of things I no longer reach for on a side project:

• No premature backend architecture. It's one Postgres database until it genuinely can't be.
• No exotic state libraries for an app with four screens.
• No rewriting my setup every time a new tool trends. It can be great and still not be worth the switching cost on a weekend project.

I've learned the hard way that every one of those "improvements" is really just a new way to not ship.

THE PAYOFF

The reason this matters isn't tidiness, it's momentum. When the boring parts are already decided, the gap between an idea and a running app shrinks to almost nothing. That's how I end up with so many little apps: the cost of starting is low enough that I'll actually do it. Most of them are for an audience of one, and that's fine. The stack is what lets me find out which ideas are worth more than an afternoon.

ONE CAVEAT

This is my side-project stack, not my gospel. At work, with a team and real users and money on the line, the tradeoffs change and "boring" sometimes means something completely different. But for personal software, where the only real risk is that I never finish, boring is the most underrated feature there is.

If you've got a stack you keep coming back to, I'd love to hear it. Drop it in the comments or find me on Discord.