My Perfect Tech Stack Was Wrong. Why I Blew It Up (Twice) Before Coding.
Picking your first tech stack is terrifying. As a solo founder, I felt this huge pressure to get it right the first time. The stack is your foundation, and you’re told you only get one shot to pour the concrete.
This is not a story about getting it right on the first try. This is the story of how my “perfect” stack fell apart and why I decided to blow it up—twice—all inside a Google Doc, before writing a single line of production code.
The “Perfect” Stack on Paper
Like a lot of founders, I wanted speed and simplicity. My first choice felt like a no-brainer: Vercel for the frontend and Supabase for the backend.
It seemed perfect. Vercel is best-in-class for hosting Next.js apps. Supabase was even better, promising an all-in-one backend that handled my database, user sign-ups, and more. It felt modern, smart, and fast. I documented it in my project plan and was ready to build.
But as I spent more time planning the product, I realized my perfect stack had some serious flaws.
Red Flag #1: The Stack Started Fighting the Product
The first problem was user authentication. I decided early on that I didn’t want to be locked into Supabase’s built-in auth system. I wanted the flexibility to switch later. That single decision meant I wouldn’t be using one of Supabase’s biggest features.
The second problem was the deal-breaker.
My product vision needed a system for running background jobs—things like summarizing content with an AI or sending emails. I found a great tool for this (pg_boss), but there was a huge catch: serverless platforms like Vercel and Supabase aren’t built to run these kinds of long-running tasks.
My stack, chosen for its simplicity, was now making my life more complicated. It was fighting my product’s core needs.
My Key Takeaway: The “best” tech on the market doesn’t matter if it’s not the right tech for your product.
The “Pre-Code” Pivot: It’s Cheaper to Change a Doc Than an App
I was at a crossroads. I could force it and build up a mountain of technical debt from day one, or I could admit I was wrong and start over.
I chose to start over. It’s infinitely cheaper to blow up your architecture in a document than it is to refactor a live application six months after launch.
I ripped Vercel and Supabase out of my project plan and replaced them with a single, more flexible platform: Railway.
The move to Railway was a shift in philosophy. It could host my Next.js app, my database, and my background worker, all in one place. The friction was gone.
Boilerplate for best-practices and accelerated development
At the same time as my tech stack shift, I decided to build on top of the Supastarter Next.js boilerplate. The name is a bit ironic now, but its real value was never about Supabase. It gave me a mature, battle-tested foundation with a proper testing framework, a modern database tool (Prisma), monorepo support, and best practices baked in. I wasn’t just getting a template; I was inheriting years of hard-won wisdom.
The Lesson: Your Product Leads, Your Stack Follows
This whole journey happened in the planning phase. It was a painful process of research, questioning, and being willing to tear down my own ideas. But it taught me a crucial lesson.
Your product vision has to dictate your architecture, not the other way around.
The intense planning wasn’t wasted time; it was the process of de-risking the project at the cheapest possible stage.
My current stack isn’t “perfect,” but it’s perfect for now. It was chosen to serve the product I’m actually building, and it was built not just to launch, but to evolve.