The Stack Discourse

Someone posts their "modern stack" and two hundred developers pile in to explain why they chose wrong.

I used to participate in these debates. I'd read the comparison posts, watch the benchmark videos, and spend hours evaluating tools before writing a single line of product code. It felt like due diligence. It felt responsible.

It was procrastination.

After fifteen years of building products across Rails, React, Next.js, PHP, and whatever else the project demanded, I've arrived at a position that would have horrified my younger self. I genuinely do not care what stack I use. The choice rarely matters at all.

The Cognitive Load of Choosing

Psychologists have a name for what happens when you face too many options: decision fatigue. Every choice you make depletes a finite pool of mental resources. The more decisions you face, the worse you get at making them.

The modern web development ecosystem generates decisions at an alarming rate.

You need a framework, but first you need to evaluate seven of them. Each framework wants you to pick routing patterns, state management, styling approaches, deployment targets. You haven't written any product code yet and you've already made forty consequential-feeling choices.

Research on decision-making suggests that time spent deliberating often correlates negatively with decision quality past a certain threshold. Beyond that point of information gathering, you're delaying while exhausting yourself.

Meanwhile, the actual hard problems remain unsolved. Who is this product for? Why would they pay for it? How will they find it? No amount of framework evaluation answers these questions. The stack discourse lets you feel productive while avoiding the work that actually determines success.

The Scalability Myth

The most persistent argument in stack debates is scalability. Choose the wrong tool and you'll hit a wall. Your startup will crater under the weight of its own success because you picked Ruby instead of Go.

This argument is almost entirely theoretical for most of us.

Basecamp serves millions of users on Rails. Shopify processes billions in transactions on it. GitHub scaled to become the infrastructure of modern software development before Microsoft wrote them a very large check. Wikipedia runs on PHP. So does most of the web, still, quietly powering everything while developers argue about whether it's dead yet.

The bottleneck at scale is database queries, caching strategies, and architecture decisions that transcend framework choice. The language sitting between your server and your logic rarely determines whether you survive success.

And most of us won't have scaling problems because most of us won't have scale. The median startup fails not from too many users but from not enough of them. Worrying about whether your stack can handle ten million requests is fantasy when you haven't figured out how to get ten paying customers.

I've shipped products in PHP that Twitter would consider embarrassing. They still run. They still make money. The customers have never once asked what's powering the backend.

How I Became Stack Agnostic

The shift happened gradually. I worked on projects in Rails, then React, then Next.js, then back to PHP for something else. At first I had preferences and opinions about which felt best. Over time those preferences faded into something closer to indifference.

What changed was my attention. Instead of asking "what's the best tool for this?" I started asking "what will get me to done fastest?" The answers were usually whatever I already knew, whatever the existing codebase used, or whatever the team was comfortable with.

The products I've shipped in the last few years span the entire spectrum. AutoChangelog runs on Rails. Preflight is written in Go. The Email Growth Guide landing page is simple PHP. Even DailyPhotoTips, which has been running since 2019, is a lightweight PHP framework. I used what worked and moved on to the actual problems.

I still notice when something new comes out. I'll read about it, maybe try it on a weekend project. But the gravity of shiny new things has weakened. The boring proven choice and the exciting modern choice have become equally valid options. The tiebreaker is always which one reduces friction between me and a finished product.

The constraint is usually figuring out what to build, finding people who want it, and shipping before you lose momentum.

The Complete Solutions

The ecosystem now offers complete solutions that handle authentication, database, real-time sync, file storage, and edge functions. Supabase, Convex, PlanetScale, Neon. They're genuinely impressive, and they're also another vector for decision paralysis.

You can spend weeks evaluating backend-as-a-service platforms. Comparing pricing models, feature sets, lock-in risks, community activity. Each one has advocates who will explain why it's the obvious choice. Each has detractors with horror stories.

Or you can spin up Postgres on a $10 VPS and move on with your life.

I'm not dismissing these platforms. I've used them. They're fine. Sometimes they're the right call, especially when speed to prototype matters more than long-term control. But the decision about whether to use them is another fork in the road that takes you further from the destination.

The destination is a working product that solves a problem for people who will pay for it. No infrastructure choice gets you closer to that. Only building and shipping does.

The Middle Position

I sit permanently on the fence between shiny and proven, and I've learned to be comfortable there.

Vercel is easy to use and I don't particularly like using it, but I would if the project called for it. Next.js has features I'll never touch and rough edges that annoy me, but I'll reach for it when the situation fits. Rails still sparks genuine affection after all these years, but that affection doesn't translate to loyalty. I'll use something else tomorrow if something else makes more sense.

This sounds like having no principles. But the thing is I only have one principle. The product is what matters.

The tools serve the product. When you invert that relationship and make the tools the point, you've lost the plot.

The framework debates are mostly people arguing about their favorite tools in contexts where the tool choice doesn't materially affect outcomes. People treat their stack preferences like sports teams. They identify with them, defend them, feel personally attacked when someone criticizes them. Everything starts to look the same anyway.

That AI Dimension

The emergence of capable coding AI has made this even more obvious.

Claude writes decent code in essentially every mainstream language and framework. Cursor doesn't care if you're in TypeScript or Python or Ruby. The knowledge gap that used to make certain stacks feel risky has collapsed. You can be productive in an unfamiliar environment because the AI bridges the learning curve.

This should have ended the stack debates entirely. If you can ship quality code in any stack with roughly equal effort, the stack truly doesn't matter. Instead, people have found new things to argue about. Which stack the AI writes best. Which tools have better AI integration. Whether vibe coding is real engineering.

The discourse adapts. The procrastination continues.

I've written about vibe coding and I use AI extensively in my workflow. I'm trying to reduce friction, to get from idea to shipped product faster. Whatever stack accomplishes that with my current skills and available AI assistance is the right stack for that project.

What Actually Matters

The products I've built that succeeded solved real problems, reached the right people, and launched before I lost interest or resources. The products that failed had unclear value propositions, weak distribution, or I abandoned them before finding traction.

Stack choice doesn't appear in either category. The successes and failures happened across every technology I've used. The correlations are with product and market decisions, not infrastructure decisions.

When you strip away the technical complexity, building a product is about finding something worth building, building it, and getting it in front of people who care. Each of those steps contains genuine difficulty. None of that difficulty lives in whether you picked Remix or SvelteKit.

Permission to Stop Caring

If you're deep in a framework evaluation right now, here's permission to stop.

Pick something. Anything reasonable. The mainstream options are all fine. Rails, Django, Laravel, Next.js, Remix, SvelteKit, fucking plain HTML with some JavaScript. They all work. They all scale far beyond what you'll likely need. They all have communities, documentation, and solved problems waiting for you to copy.

Those hours you'd spend evaluating them could go toward the unsexy parts instead. Talking to potential customers, writing copy that explains your value, setting up the infrastructure that makes your product trustworthy. The work that doesn't feel like engineering but determines whether the engineering matters.

Your stack is a substrate. The plant grows in soil but nobody buys a plant for its dirt. Pick the soil you're comfortable with, plant something, and see if it grows.

If it does, the stack was fine. If it doesn't, the stack wasn't the problem.

The only wrong choice is the one that prevents you from starting. Everything else is details.