The Year I Lost Choosing Technology
2024 was my year of analysis paralysis. Seriously.
I spent months evaluating stacks. Next.js or Remix? Prisma or Drizzle? PostgreSQL or try something new with SQLite + Turso? Kubernetes from day one or wait until it's needed? Monorepo or polyrepo? REST or GraphQL or tRPC or gRPC?
Every technical decision felt irreversible. Like choosing wrong would condemn me to rewrite everything in six months.
Spoiler: I built nothing in that time. Zero. Just comparisons, benchmarks, and create-next-app on repeat like an empty ritual.
The Lie of the "Right" Stack
Someone on Twitter posts their stack: Next.js, TypeScript, tRPC, Prisma, PostgreSQL, Tailwind, Vercel, Clerk, Upstash, Planetscale. It's elegant. It's modern. It gets 3,000 likes.
What they don't tell you:
- Their product has 47 users
- 80% of those technologies are overkill for what it does
- They switched stacks three times before launching
- Half those tools were added because "that's what everyone uses," not because they needed them
Chasing the "right" stack is chasing an Instagram photo. It looks good. It doesn't reflect reality.
What Actually Matters
After a year of inaction, I made three decisions that changed everything:
1. The stack is not the product. Your users don't care if you use PostgreSQL or MongoDB. They care that your product solves their problem, loads fast, and doesn't lose their data. Technical elegance is for you, not for them.
2. The best stack is the one you already know. Sounds obvious, but tech FOMO makes you forget. If you've mastered Laravel, use Laravel. If you've been on Django for years, use Django. Execution speed with a known stack beats any theoretical advantage of a new one.
3. Migrating isn't failing. "If I choose wrong, I'll have to migrate later." Yes. So what? Migrating a product with users and traction is a luxury problem. It means you have something worth migrating. Choosing "wrong" and shipping beats choosing "right" and never shipping.
My Actual Stack (No Posturing)
This is what I use today for Guayoyo:
- Frontend: Astro + a bit of React where needed. Not Next.js. Not Remix. Astro. Because the content is static and I don't need SSR for everything.
- Styling: Tailwind. Because it's fast, not because it's trendy.
- Hosting: Cloudflare Pages. Automatic deploy from GitHub, SSL, CDN, cache, everything included. Costs $0.
- Backend: n8n for workflows, occasional plain Node.js webhooks. No framework. If your backend is 3 endpoints, you don't need NestJS.
- Infrastructure: K3s on a VPS for anything requiring real compute. No EKS, no GKE, no vendor lock-in.
- Database: PostgreSQL. Yes, the one that's always been there. The one that worked before the trendy ORM of the month existed.
It's not the stack you see in viral tweets. But it's in production, solves real problems, and I understand it completely.
The Rule That Changed Everything
I only add a technology when the one I have hurts me.
Is Next.js better than Astro for certain things? Sure. Does Astro hurt me today? No. So I don't switch.
Is Kubernetes complex? Yes. Would Docker Compose work for what I have? Probably. But K3s lets me grow without changing paradigms when the time comes.
Every new technology is debt you acquire. It charges interest in complexity, maintenance, onboarding, and external dependency. Make sure the return is worth it before you sign.
Build > Choose
If you're stuck in the "what stack do I use?" cycle, my advice is brutally simple:
Pick what you already know. Build. Ship. Iterate.
In six months, if your current stack is holding you back, changing it will be a problem you want to have — because it means your product grew enough for it to matter.
Done with tech hype? More every week. Newsletter or X.
Top comments (0)