The stack monoculture
Almost every new web product is Next and React and Postgres and Tailwind. The sameness is load-bearing and it also has a price worth naming.
Bob Bass
Count the stack behind the last ten products you saw launched this year: Next.js on Vercel, React, Tailwind, a shadcn-style component set, Postgres behind Supabase or Neon, Drizzle or Prisma in the middle. Now count the meaningful variations. There are barely any. For most of web history the first weeks of a project were a fight: framework against framework, database against database, each choice made in public and defended in blog posts. The fight is over. Nearly everyone picked the same answer, and the sameness is load-bearing, which is a polite way of saying that when it fails, it fails everywhere at once.
How the monoculture happened
Defaults compound. React's dominance had network effects running from hiring through documentation to component libraries. Tailwind rode tutorial momentum. Postgres took the default-database seat by being good enough at nearly everything, and every managed platform made it the one-click option. Each layer picked what the layer below already implied, until the whole stack was implied by the first choice.
Then a force arrived that made the old herding look gentle: the models. Coding agents are trained on a corpus where these choices dominate, so the stack they generate by default is the stack most code was written in, and generated code that arrives closer to compiling gets kept. New engineers learn from agent output, reviews converge on the same idioms, and the monoculture acquired a self-reinforcing loop no previous default ever had: the tools that write code prefer the code most people already wrote.
Deprecations then ratified it. When the React team flagged create-react-app as deprecated, the migration path everyone was handed pointed at the same framework. The alternatives (Rails, Laravel, Astro, SvelteKit, HTMX for the purists) remain perfectly good tools that still get real work shipped. They are just no longer defaults. They are choices somebody has to make on purpose.
What the monoculture buys
The upside is real and worth spelling out. The hiring pool is shared: a team can staff up from people whose last four codebases all looked like this one, and onboarding lands in days because pattern recognition transfers wholesale. Your strange bug was somebody else's this week, and the fix is already in an issue thread. Failure modes get discovered at population scale, from hydration mismatches to connection-pool exhaustion, and the population writes the postmortems for you. Vendors build for exactly this stack, so deploys, preview environments, caching, and observability work well on it with nearly no configuration.
For small teams this is the best time in the web's history to ship. One engineer with a weekend can put up what a funded startup needed six vendors and a quarter to assemble a decade ago. The floor is higher than it has ever been, and no amount of taste should talk anyone out of using it.
What it costs quietly
The costs arrive slowly and arrive together.
Opinions atrophy. When the default is universal, most people never have to choose, so the skill of choosing decays: reading a boring trade-off, forming a view under pressure, defending it with reasons better than "it's the default." The next decision where the default is genuinely wrong (a realtime collaborative editor, an embedded device, a workload Postgres will not love) finds a team that has never evaluated anything, holding its entire platform by habit.
Differentiation moves entirely upstream. If every competitor ships the same rails in the same week, engineering advantage migrates to product judgment, distribution, and data. There is an honest argument that this is an overdue correction, since for many products the stack was a fake moat all along. It still changes what a strong engineer is priced at and what an engineering culture is for, and the industry is in the middle of repricing both.
The tooling market converges on one buyer. Vendors build for the monoculture because the monoculture is the market, which starves the alternates of sponsorship and attention. Concentration itself becomes the risk: the CrowdStrike outage in 2024 demonstrated the failure mode of one faulty update on one dominant platform, grounding flights and postponing surgeries. A web monoculture is milder in degree, not in kind. One pricing change, one supply-chain compromise, one license decision ripples through a very large fraction of new software at the same time.
Staying deliberate inside the monoculture
None of this argues for contrarianism. Rebuilding on exotic technology for taste is how teams acquire failure modes they cannot hire their way out of. Keep the defaults and keep the ability to notice them. Write down, for each default, the one sentence that would justify replacing it. Occasionally ship something small on the alternative you have never touched, so the muscle exists when a feature genuinely needs it. And when someone says the default is wrong for this particular problem, require a named constraint and an alternative that survives it, costed honestly. The monoculture is a fine answer. The failure is treating it as the only question.
From the desk that wrote this
This blog is run by the team behind Layerbase, so every post comes with a conflict of interest attached rather than concealed behind it.