The Boring Stack I Reach For on Every Side Project

I've been in Software Development for 15 years now and I've got a pretty long list of side projects that I've attempted over all these years. Most recently I've been building Hikari, getgoodr, AnimeGuesser, imablank, NAJ Times, and few more that have never made it past a prototype. If there's one thing that's a bit more common for the recent projects, it's that I've stuck to a pretty boring stack. I don't mean boring in a bad way here but it's just something that's tried and true from my perspective.

WHY BORING WINS

If you're new to web development and haven't noticed it yet: there's always something new. Whether it's a major release of the framework you're using, a completely different framework, new library, new patterns, new x y or z. Learning these new things can take up time but if you're like me and just want to build something new, stick to a boring stack.

Boring tools are the ones I already know, I don't have to think about them so all my thinking goes to what I'm building.

When I try to learn something new I'll try to change just one thing at a time instead of everything all at once. This gives me an oppurtunity to learn something a little more focused without worrying about anything else and how things could get affected.

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 / 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 and I don't have hockey 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, 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. Find me on Discord.