You don't need a framework. You need users. Choosing tools is the most productive-feeling way to avoid shipping, and AI makes the temptation worse.
A few weeks ago this site was sitting on my local machine. Fully built. Twenty-six files. Two CSS files. One shared JavaScript file that handles email forms. It deployed instantly, loaded fast, and did everything I needed it to do. Nobody had seen it. I hadn't shared it with a single person.
And instead of fixing that, I was sketching out a migration to Astro. Thinking about component libraries. Considering whether the sidebar duplication across six files justified a build step, a package.json, a node_modules folder, and a templating system.
Six files. I was about to introduce a build pipeline to avoid editing six files. On a site that zero people were using because I hadn't shown it to anyone yet.
I stopped. Not because I figured out the right technical answer. Because I recognized the feeling. It was the same feeling I've had thirty times before, in that projects folder full of things nobody uses. The feeling of solving a problem that doesn't exist yet so you can avoid the one that does. The site didn't need a better architecture. It needed to be live. It needed to be in front of someone who could tell me whether it was worth anything.
There's a particular kind of work that feels exactly like shipping but isn't. Migrating to a new framework. Setting up a component library. Configuring a CI pipeline. Evaluating three static site generators to find the one with the best plugin ecosystem. Each of these tasks is real work. You write code. You solve problems. You commit changes. At the end of it, your project is different than when you started.
But your users, if you have any, can't tell. Nothing changed for them. You rebuilt the factory floor and the product on the shelf is identical.
I call this infrastructure cosplay. You dress up as someone who's shipping, but you're actually reorganizing the workshop. The toolbelt gets nicer. The workbench gets cleaner. The thing you're supposed to be building with those tools sits untouched.
This isn't new. Developers have been doing this forever. But AI makes it more dangerous because it compresses the timeline. You can now migrate an entire site to a new framework in an afternoon. Which means the cost feels negligible. "It's just a few hours." But those are the same few hours you could have spent writing the essay, building the feature, or having the conversation that might actually move things forward.
The speed of the migration isn't the point. The direction is. You moved fast sideways.
I've heard every version of the argument, mostly from myself.
"Real developers use frameworks." Your users don't care what's in your source code. They care whether the page loads and the thing works. A static HTML file served from a CDN does both better than most framework-generated bundles. If your identity as a developer is tied to your stack, that's an ego problem, not a technical one.
"It'll be easier to maintain later." Later when? When you have 200 pages? You have 12. When you have a team of five? You're one person. You're optimizing for a future that requires your current product to succeed, and you're spending your time on the optimization instead of the success. If the product works, you'll know when maintenance is painful because maintenance will actually be painful. You won't have to guess.
"I should learn React anyway." That's fine. Call it what it is. It's a learning project. The problem isn't learning new tools. The problem is disguising a learning project as product work. If you want to learn React, go learn React. Build a toy. Take a course. Don't retrofit a working product into a learning exercise and pretend it's an upgrade.
"My site looks unprofessional without components." Show me a user who bounced from your site because they viewed source and saw raw HTML. Your site looks unprofessional when the copy is bad, the layout is broken on mobile, or the thing you're selling isn't clear. None of that is a framework problem.
Frameworks aren't bad. They solve real problems. The question is whether you have those problems yet. Here's how to tell the difference between a real problem and a hypothetical one.
You actually need a framework when:
Notice the pattern. Every trigger on that list is about pain you've already felt, not pain you're anticipating. The nav update you've already done three times. The feature you already tried to build and couldn't. The post you already didn't publish. If you can't point to a specific moment where the current setup cost you something real, you don't have a framework problem.
You don't need a framework when:
If you do outgrow static HTML, the answer almost certainly isn't React. Here's the progression that matches how solo builders actually grow:
Static HTML. You're shipping content. A few pages, a few tools, maybe a blog. Everything is hand-edited. The duplication is minor. This is where most solo builders should stay far longer than they think.
Static site generator. You've hit 30+ pages with shared layout and the nav changes are genuinely eating your time. Eleventy or Astro gives you templates and partials while keeping the output as plain HTML. No client-side JavaScript. No React. Your pages still load instantly and deploy anywhere. This is the right next step for 90% of content sites that outgrow static HTML.
Framework. You're building an actual application with client-side state, authenticated users, real-time updates, or complex interactive features. Not a marketing site with a contact form. Not a blog with a calculator. An application. If you're not sure whether what you're building qualifies, it doesn't.
Most solo builders who reach for a framework are at stage one trying to jump to stage three. They skip the middle step entirely because a static site generator doesn't feel ambitious enough. It doesn't have the same status. Nobody writes blog posts about how they migrated to Eleventy. But it's the right tool, and the right tool used well beats the impressive tool used to procrastinate.
The stack question is never really about the stack. It's about whether you're solving a problem you have or a problem you're inventing to stay busy.
This is true for frameworks. It's true for AI model selection. ("Should I use GPT-4 or Claude?" Use whichever one you already have an API key for and start building.) It's true for infrastructure. ("Should I use Kubernetes?" You have eleven users.) It's true for everything.
I watched this exact pattern destroy momentum inside large organizations for years. The team that spent a quarter evaluating orchestration platforms while the competitor shipped on a cron job and a Postgres database. The startup that rebuilt their MVP in a "more scalable" architecture before they had enough users to test the original one. The enterprise AI team that debated fine-tuning strategies for months while a guy with a spreadsheet solved the same problem in a week.
The builder who ships on the wrong stack beats the builder who's still setting up the right one. Every time. Without exception. Because shipping is how you find out what actually needs to change. Everything before that is speculation wearing work clothes.
Before I touch my tools, I ask myself five questions. If I can't answer yes to at least three of them, I put the tooling change down and go do something that actually faces a user.
That last one is the hardest to answer honestly. I know because I still get it wrong. The pull to upgrade, migrate, refactor, and optimize is strong. It feels responsible. It feels professional. It feels like the kind of thing a serious person does.
But serious people ship. And shipping happens on the stack you already have, not the one you're building next.
Builder's Path is a public lab from Sellhausen AI Systems focused on AI-native building, validation, and product judgment.