What does full-stack actually mean?
Full-stack means one person can carry a feature from the database to the screen without handing it to anybody else. That is the whole claim, and it says nothing about how deep they go on either end. The title describes a range, not a level, which is why two candidates with identical CVs can be worth very different amounts to you depending on which half of the range your work sits in.
What does the title actually guarantee?
Only that the person is not blocked by a boundary. They can add a column, write the endpoint that reads it, and build the interface that shows it, without waiting for a second engineer. That is genuinely valuable, and it is all the title promises.
It does not promise depth at either end. Somebody can be entirely competent at shipping features across a stack while never having tuned a query, sized an index, or debugged a memory leak in a long-running process. Nothing in the term covers that, and nothing should be inferred from it.
The practical consequence is that the word tells you about the shape of the work someone can take on, and nothing about the ceiling of the work they can survive. Both matter, and only one is in the title.
Which kinds of full-stack developer are there?
Four shapes come up repeatedly, and they are not interchangeable even though all four are honestly described by the same two words. The difference is where the person's instincts live when a problem is ambiguous, which is exactly when it matters.
The reason this matters at hiring time is that the mismatch is invisible for the first month. All four ship features. The divergence shows up when something goes wrong in the half of the stack they are weakest in, because that is when they either diagnose it or escalate it.
| Shape | Strong at | Escalates on | Best fit |
|---|---|---|---|
| Frontend-leaning | Interface, state, accessibility, browser behaviour | Query performance, data modelling, background jobs | Products where the interface is the product |
| Backend-leaning | Data modelling, APIs, jobs, integrations | Layout, interaction detail, design implementation | Products where the value is in the data and rules |
| Product generalist | Shipping whole features quickly, judgement about scope | Anything requiring depth under load | Early products still finding their shape |
| Platform generalist | Deployment, environments, observability, glue | Nuanced interface work and design fidelity | Small teams with nobody owning infrastructure |
Where does the ambiguity cost money?
In the gap between what you assumed the person could absorb and what they can. A company with a heavy reporting workload hires a strong frontend-leaning generalist, and six months later the reports are slow, nobody has looked at an execution plan, and the fix is treated as a mystery rather than as a missing skill.
It also costs money in the other direction, more quietly. A backend-leaning developer building a customer-facing interface will produce something that works and feels wrong, and the cost surfaces as churn and support load rather than as a bug report anyone can act on.
Neither of these is a failure by the developer. Both are failures of the brief, because the brief asked for a range and did not say which end of it the job actually lives at.
Is one full-stack developer the same as two specialists?
No, and the difference is not only about depth. One person carrying a feature end to end removes the handover entirely, and handovers are where requirements get quietly reinterpreted. On small, fast-changing work, one generalist commonly out-delivers two specialists who have to agree on an interface between them.
The trade is that a generalist has one attention span. Two specialists can work in parallel on the same feature; one generalist cannot, so throughput on a single large feature does not double when the work does.
The useful test is whether your work arrives as many small pieces or as a few large ones. Many small pieces favour generalists, because each piece completes without coordination. A few large ones favour specialists, because the coordination cost is paid once and the parallelism is real.
How do you write a brief that filters correctly?
Describe the work, not the stack. A list of technologies attracts everybody who has touched them; a description of the actual problems attracts the people who have solved those problems and quietly repels the rest, which is the more valuable effect.
State the centre of gravity explicitly. A line saying that roughly seventy per cent of this role is backend work on a reporting-heavy product, and that the interface work is functional rather than design-led, will lose you applications you did not want and gain you honest conversations with the ones you did.
Name the parts you have nobody for. If there is no infrastructure owner and the new hire will inherit deployment, say so in the advert rather than in month two. Candidates who find that appealing exist, and they are not the same candidates who find a pure product role appealing.
What should you ask in the first conversation?
Ask what they reached for last time something was slow, and listen for whether the answer lives in the browser or in the database. Both are legitimate answers. Which one arrives first, unprompted, tells you where their instincts sit better than any self-assessment does.
Then ask what part of the stack they avoid. A candidate who names one specifically and explains how they compensate is describing a real professional; a candidate who says they are comfortable everywhere is either exceptional or has not worked anywhere the difference showed.
Finally, ask them to describe a feature they took from an empty database table to a screen someone used. The detail in that story is the closest thing to a direct measurement of the claim the job title makes.
Common questions
- What does full-stack developer actually mean?
- It means one person can take a feature from the database through the API to the interface without handing it to anyone else. The term describes a range of work, not a level of skill, and guarantees nothing about depth at either end. Someone can be a genuinely effective full-stack developer and have never tuned a slow query or debugged a browser rendering problem.
- Is a full-stack developer worse than a specialist?
- Not worse, differently shaped. A generalist removes handovers, which is where requirements usually get reinterpreted, so on small fast-changing work one generalist often out-delivers two specialists coordinating an interface between them. The trade is attention: two specialists can work in parallel on one large feature and a single generalist cannot.
- How do you tell whether a full-stack developer is frontend or backend leaning?
- Ask what they reached for the last time something was slow and notice whether the answer starts in the browser or in the database. Both answers are legitimate; the one that arrives first without prompting reveals where their instincts live. Asking which part of the stack they avoid is the other reliable probe, because a specific answer indicates self-knowledge rather than weakness.
- Should a job advert list technologies or problems?
- Problems. A technology list attracts everyone who has touched those tools, while a description of the actual work attracts people who have solved that work and quietly discourages the rest. State the centre of gravity explicitly, such as the proportion of the role that is backend, and name any area the new hire will inherit because nobody currently owns it.
- Can one full-stack developer replace a whole team?
- For an early product with small, frequent pieces of work, one capable generalist can carry surprising amounts of ground. The limit arrives when work stops arriving as small pieces and starts arriving as a few large ones, or when depth is required under load. At that point coordination cost is paid once and parallel specialists become the cheaper arrangement.
