Open any job board and you will find the posting. "Full-stack developer wanted." Then the list: React and TypeScript on the front, Node or Python or Laravel on the back, PostgreSQL, Redis, AWS, Docker, Kubernetes, a CI/CD pipeline, mobile a plus, and — buried near the bottom, phrased as if it were a personality trait — "an eye for design." That is not a role. That is an engineering department compressed into one requisition and one salary, and the person who wrote it is hoping nobody notices.
The pitch behind "hire a full-stack developer" is almost always the same, and it is almost always about money. One hire instead of two. One person who can take a feature from a Figma sketch to a deployed endpoint without a handoff. Fewer meetings, fewer dependencies, faster shipping. On a spreadsheet it looks like arbitrage: buy breadth, skip the specialists, keep burn low. I have watched founders talk themselves into it for eleven years, and the spreadsheet is lying to them.
The label is doing work it was never built to do
"Full-stack" describes a way of working, not a species of person you can order off a menu. It means an engineer is comfortable moving up and down the stack instead of throwing work over a wall — building the API and the screen that consumes it, and understanding why the query is slow instead of filing a ticket about it. That is genuinely valuable. It is also nothing like the fantasy in the job post, where one human holds frontend, backend, infrastructure, mobile, and design at senior depth simultaneously.
Nobody is at the top of five ladders at once. The honest version of a good full-stack engineer is deep in one thing and competent across the rest — able to be dangerous everywhere and expert somewhere. When a buyer treats the word as a promise of expert-everywhere, they are not hiring a generalist. They are hiring a story about a generalist, and the gap between the two is where products quietly rot.
What actually goes wrong is invisible for six months
Here is the part the two-for-one math never prices in: a solo full-stack developer writes code that no one reads. That is the real cost, and it does not show up as a missed deadline. It shows up later — as the migration nobody sanity-checked, the auth flow with a hole in it, the schema decision that made sense at 2am and boxes you in eighteen months on. One person moving fast across the whole stack, unreviewed, is not a bargain. It is a loan against the future at an interest rate you cannot see yet.
We treat code review as non-negotiable for exactly this reason: every pull request at our studio is read by at least one other senior engineer before it merges. That is not process theater. It is the mechanism that catches the shortcut before it ships, spreads knowledge so the product does not live in one person's head, and keeps the bus factor above one. A lone full-stack hire, by definition, deletes that mechanism. You are not saving a salary. You are removing the second set of eyes and calling the removal a feature.
Full-stack is real — it just belongs inside a team
None of this is an argument against full-stack engineers. It is an argument against the solo unicorn. The largest group at our studio is full-stack — Laravel and PHP on the backend, React on the front — and they run multi-year SaaS builds where the same people carry a product from first commit to production and keep carrying it for years. Full-stack is how they work. It is not a heroic individual doing the job of four; it is a mode of working that only pays off when there is a team and a review culture around it.
The version that genuinely earns its keep goes further than most job posts imagine. We do not hand infrastructure to a separate department — the engineers who write the application code own the DevOps for it, the pipelines, the environments, the monitoring. That is full-stack extended all the way to production, and it works because the person shipping the feature also owns why it broke at 3am. That is the opposite of one overloaded generalist; it is depth of ownership distributed across people who review each other.
The screen you should run instead of counting technologies
If you are hiring, stop scoring candidates by the length of their tech list. The list is noise. A resume that claims eleven technologies is telling you the person has touched eleven things, not that they are trustworthy in any of them. The word "full-stack" on a CV has quietly become a synonym for "I've done a bit of everything," which is the same information as "I've done nothing deeply."
Screen for depth first: one area they can go all the way to the bottom of, where they can explain not just what they did but why the alternatives were worse. Then screen for the breadth that lets them move — can they follow a request from the button click to the database row and back without needing a translator at every layer. Depth plus mobility beats a wide, shallow checklist every time, and it is the only definition of full-stack worth paying for.
The economics the two-for-one story gets wrong
The budget case for one full-stack hire assumes the second engineer is pure cost. It is not. The second engineer is the review, the redundancy, and the argument that stops the bad decision. Skip that and the savings are front-loaded while the bill is deferred — you feel clever in month two and pay for it in month fourteen, usually right when the product finally has users who notice.
There is a fair sizing point buried here. A small full-stack pod — call it four engineers with a tech lead — is a real number, and in our engagements that lands somewhere around twenty-five to fifty-five thousand a month depending on seniority mix and how much of it is senior. That looks expensive next to one generalist at a single salary. It is not, once you count the debt the single generalist accrues and the rewrite that debt eventually forces. The cheap option is only cheap until the first thing you cannot fix cheaply.
When one full-stack developer is genuinely the right call
I will not pretend the exception does not exist. There is a narrow window where a single full-stack developer is exactly right: the throwaway prototype, the internal tool, the V1 you fully expect to rewrite once you learn whether anyone wants it. When the goal is to answer a question fast and the code is disposable, one generalist moving quickly is the correct, cheap, honest choice — and dragging a full pod into it would be waste.
The mistake is letting that window quietly become the architecture. The prototype earns users, the throwaway code stops being thrown away, and the solo hire who was perfect for a two-week spike is now the single point of failure for a system real people depend on. The moment a product stops being disposable is the moment one full-stack developer stops being enough — and almost nobody notices that line until they are already past it.
We've made the long version of this case in our full breakdown of when staff augmentation is worth it. For team composition, rates, and how engagements start, our staffing services cover it.
The position, stated plainly
Hire full-stack engineers. Do not hire a full-stack developer as a way to buy an engineering department for one salary, and do not hand a single one the whole product to own alone. The value of full-stack was never the cost you cut by not hiring the second person — it was the person who moves fluidly across the stack while another senior reads their code. Buy the working mode and the review culture that makes it safe. The lone unicorn in your job post does not exist, and the closest thing to it you can actually hire is the most expensive shortcut in software: cheap today, and quietly compounding against you the whole time.