For years, "I can build the whole thing" was a pitch that landed. Database design, the API, the frontend, the deploy pipeline — one person, no handoffs. Clients liked it because it meant nobody was ever blocked waiting on a specialist who was busy on something else.
That pitch has stopped being interesting, because everyone makes it now and a lot of them can deliver on it. The bar for "full-stack" moved from rare to assumed, and the thing clients actually pay a premium for moved somewhere else.
What "full-stack" was really signalling
It was never about knowing every layer equally well. It was a promise of self-sufficiency: hand this person a problem and they will carry it end to end without a chain of dependencies. That is still worth something. It is just no longer scarce.
Frameworks got better at hiding the hard edges. Managed platforms turned "set up the infrastructure" into a dashboard. Bootcamps produced a decade of people trained specifically to work across the stack. And now a model will scaffold the parts you are rusty on. The breadth got democratised, which is good for the industry and bad for anyone whose entire value proposition was the breadth.
The T, not the pillar
The useful shape is a wide horizontal bar of general competence with one deep vertical spike coming off it. Broad enough to move through any part of a system without getting lost; deep enough in one area that people come looking for you specifically.
Clients do not lie awake worrying about whether someone can wire up a form or stand up a CRUD endpoint. They lie awake about the payment integration that has to reconcile three providers, the auth migration that can't log everyone out, the data model that is six months from not scaling. That is the work they want to hand to someone who has clearly done it before and watched it break. The spike is what makes that credible.
How I picked the spike
I did not sit down and choose payments and entitlements as a strategy. I kept being the person who got handed that specific mess — the duplicate charge, the subscription state that disagreed with itself across platforms, the webhook that fired twice. After the third or fourth time, it stopped being a nuisance and became the thing I was known for, and then the thing I got hired for.
If there is advice in that, it is: notice which kind of problem keeps finding you, and lean into it on purpose instead of treating it as an interruption. The specialisation you back into by pattern is usually more durable than one you pick off a list of what pays well this year.
When breadth still wins
Specialisation is a bet, and it does not pay everywhere. Early-stage teams before product-market fit need someone who can build ten different small things this quarter, not one deep thing. Tiny teams need range because there is nobody to hand the other layers to. Agencies doing a high volume of varied builds are buying flexibility, and a specialist is a worse fit for that than a strong generalist.
The bet pays off at a particular scale of client and problem: when the thing they are hiring for is genuinely hard, genuinely high-stakes, and worth paying to get right the first time. Below that line, range is the asset.
If you're mid-career and reading this
Do not drop the breadth. It is the horizontal bar — you still need to move confidently through a whole system, and a specialist who can't is just a bottleneck with a title. Add the spike deliberately: pick the area that already makes your clients nervous, own something in it in production, and write about what you learned. The generalist who is also visibly the "payments person" or the "performance person" gets both kinds of work, and gets to charge more for one of them.
Where I've landed
I still do full-stack work every week — most projects need it, and I like it. But I get hired for the entitlements problem, and being hired for a specific hard thing is a better business than being available for anything.
FAQ
Is full-stack development still worth learning?
Yes — it's the baseline now. Being able to work across the stack is what keeps you from being blocked and lets you reason about a whole system. It just isn't a differentiator on its own any more, because most working developers can credibly claim it.
Should I specialise as a developer?
Add a specialisation on top of broad competence rather than instead of it. The strongest position is T-shaped: wide enough to navigate any part of a system, deep enough in one area that people seek you out for it. Pure specialists get brittle; pure generalists get commoditised.
What is a T-shaped engineer?
Someone with broad working knowledge across the stack (the horizontal bar) plus genuine depth in one domain — payments, security, data infrastructure, performance — that they're known for (the vertical spike). It's the shape that gets you both general project work and premium work in your specialty.
When is being a generalist better than specialising?
Before product-market fit, on very small teams, and in agency-style work with a high volume of varied builds. Anywhere the job is "build many different small things," range is worth more than depth. Specialisation pays once the problems are hard enough and high-stakes enough to be worth paying a premium to get right.
How do I choose a specialisation?
Notice which kind of problem keeps landing on your desk and which cleanup work you keep being trusted with, then lean into that on purpose. A specialisation you back into by demonstrated pattern tends to be more durable than one picked purely for its current market rate.
Does specialising limit my job options?
Only if you let the breadth atrophy. Keep the general skills sharp and a specialisation widens your options — you stay eligible for generalist roles and become the obvious hire for anything in your domain. The risk is going so narrow you can't function outside it.
Further reading
- Valve — Handbook for New Employees — the "T-shaped people" framing, hiring for breadth plus one deep spike
- Jeff Atwood — The Two Types of Programmers — an older take on range versus depth that has aged into relevance
- patio11 — Don't Call Yourself A Programmer — on positioning your skills around the problem a business actually has
- David Epstein — Range — the case for generalists, worth reading against the grain of this post
- Scott Adams — Career Advice (the "talent stack") — being top-25% at two or three things beats being top-1% at one
Related on this site: AI writes the code now is the other half of this — the breadth got cheaper because the typing got cheaper; leaving the cloud is having a moment is the same "decide it on your actual constraints, not the headline" thinking. See what the specialisation looks like in practice in the Protect-A-Plate case study, or get in touch.