// August 18, 2026
Choosing a Stack When Everyone Online Disagrees
3 min read
// related
// August 18, 2026
3 min read
// related
There's a diner near everyone, at some point in their life, with a fourteen-page menu. Two hundred items, every cuisine, laminated. And there's a taco truck somewhere in the same town serving six things.
The truck's food is better. It's not close, and everyone quietly knows why: the truck committed. The diner kept its options open, and keeping every option open is just a slower way of choosing none of them.
I did not understand that I was standing in the diner until I'd been there for months.
When I started building for real, I did what every new developer does: I asked the internet which tools to use. The internet was glad to help. It has benchmark videos, framework comparison threads, and forum wars conducted at one in the morning by people who all sound completely certain and completely disagree.
Every option was credible. Every community was loud. Every choice had a post explaining why it was obsolete. I'd finish a night of research knowing more and deciding less — which should have been the tell, because research that moves you further from a decision isn't research anymore. It's hiding.
I spent months periodically reopening the Supabase-versus-Firebase decision, reading the same comparisons and convincing myself that one more round of research would reveal an obviously correct answer. It never did. Eventually I had to stop asking which platform could theoretically do more and ask which one let me keep building the product already in front of me.
A psychologist named Barry Schwartz wrote a whole book about this, The Paradox of Choice. The popular takeaway is that more options always make people miserable, and that version turned out to be too broad. The narrower one held: when the options are complex, hard to compare, and you don't yet know enough to know what you want, more of them leaves people less satisfied, not more. Which is framework selection, described exactly.
And the people hit hardest are what Schwartz calls maximizers: the ones determined to find the best option rather than one that meets the need. Maximizers decide slower, second-guess harder, and enjoy their eventual choice less — because somewhere out there, an option they didn't take is winning a benchmark.
Framework research turns almost everyone into a maximizer. The fix is deciding, in advance, to be the other thing: define what good enough means, take the first option that clears it, and stop looking. Satisficing isn't settling. It's refusing to pay infinite search costs for marginal gains.
So I stopped asking "what's best," a question with no stable answer, and started asking four questions that actually converge:
That filter produced my stack: React, TypeScript, Supabase, and Vercel on the web, Kotlin for the Android app. I've written before about why those deliberately unremarkable choices were the brave ones. But notice what the questions have in common: none of them ask which tool is best. They ask which tool will still be holding when I'm tired, stuck, or gone. Different question. Answerable.
The stack barely matters. That's the secret the framework wars can't admit, because the wars are the product. Success on real projects comes down to whether you ship, whether you can maintain what you shipped, and whether you keep going — and every mainstream stack supports all three. The diner and its fourteen pages exist because choosing feels like progress and commits you to nothing.
Pick your six things. Get good at them. The menu isn't the meal — cooking is the meal, and the truck's been telling you that the whole time.