I want to be precise about what I am arguing here, because this topic generates more heat than light. I am not saying that full-stack developers are bad. I am saying that "full-stack" as a hiring strategy for complex enterprise software is a bet that consistently loses in ways that are expensive and slow to diagnose.

The Era That Created the Full-Stack Developer

The full-stack model emerged from a specific moment in web development: the early 2010s, when a single developer with working knowledge of JavaScript, a backend framework, and SQL could ship a product that reached millions of users. The complexity ceiling was low enough that one person could hold the entire system in their head.

That era shaped a generation of hiring managers who still default to "we need a full-stack developer" regardless of what they are actually building. The assumption has calcified into habit.

Where Generalists Hit the Wall

For an MVP or a team of three, a strong full-stack developer is exactly what you need — broad coverage, fast iteration, minimal coordination overhead. I recommend them in that context.

But enterprise software has different physics. At scale, the decisions that matter most are the ones where depth is not optional.

Database architecture. A full-stack developer who is competent in SQL will write queries that work. A database specialist will design indexes, partition strategies, and replication topologies that keep working as data volume grows by an order of magnitude. I have seen systems that performed acceptably at 100,000 rows collapse under 10 million — not because the code was wrong, but because the schema was designed without understanding how the query planner would behave at scale. This is specialist knowledge, and generalists do not have it by definition.

Frontend performance engineering. A full-stack developer will build a frontend that renders correctly. A frontend performance specialist understands bundle splitting, hydration strategies, paint timing, layout shift causes, and how browser rendering pipelines interact with JavaScript execution. The gap between "renders correctly" and "performs correctly at scale" is where most enterprise frontend budgets disappear.

Security depth. Security is not a feature you add at the end. It is a set of disciplines — threat modeling, authentication flows, secrets management, dependency auditing, rate limiting, injection prevention — that require sustained expertise to get right. A generalist who "knows security" knows enough to be dangerous.

The Business Case

Hiring specialists feels more expensive upfront. The math changes when you factor in the cost of the incidents that specialists prevent.

A misconfigured database index on a high-traffic table costs you every day, invisibly, in slow queries that degrade user experience and inflate cloud costs. A frontend bundle that was never optimized costs you in bounce rates and SEO rankings. A security gap costs you in the form of a breach that generates regulatory fines, legal liability, and customer churn.

These are not theoretical risks. They are the problems I get called in to fix — after a generalist-built system has been running long enough for the shortcuts to become structural.

The Practical Middle Ground

This is not a binary choice. Most teams do not need a full department of specialists. What they need is clarity about where the complexity lives in their specific system.

If your application is data-heavy and query-intensive, the highest-value specialist hire is a database architect — or a senior developer who has spent years focused on that domain. If your frontend serves millions of users on mobile connections, frontend performance expertise pays for itself.

For early-stage work where speed matters more than scale, a strong generalist is still the right answer. The mistake is not hiring generalists — it is never graduating beyond them as the system grows.

For a deeper look at how these architectural decisions play out at the B2B portal level, my post on architecting for scale gets into the specifics.

If you are evaluating the technical structure of your team or your system, reach out. I am happy to give you an honest assessment of where specialist depth would make the biggest difference.