--- title: "The Boring Stack I Reach For on Every Side Project" description: "After 15 years and a dozen half-finished apps, I stopped chasing shiny tools. Here's the deliberately boring stack I reach for on every side project, and why boring is the point when your real bottleneck is shipping." author: "Romel Dris" published: "2026-06-20T00:00:00.000-07:00" last_updated: "2026-08-12T07:16:54.890Z" canonical_url: "https://romeldris.ca/blog/the-boring-stack-i-reach-for-on-every-side-project" markdown_url: "https://romeldris.ca/blog/the-boring-stack-i-reach-for-on-every-side-project.md" categories: ["Programming"] keywords: ["react native side project stack","expo typescript stack","boring tech stack","best stack for side projects","indie app stack"] --- # The Boring Stack I Reach For on Every Side Project > After 15 years and a dozen half-finished apps, I stopped chasing shiny tools. Here's the deliberately boring stack I reach for on every side project, and why boring is the point when your real bottleneck is shipping. 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](https://getgooder.co), [AnimeGuesser](https://daredesuka.com), [imablank](https://imablank.com), [NAJ Times](https://najtimes.ca), 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.