What a full-stack developer cannot do
A capable full-stack developer covers more ground than most job adverts require, and there is still a boundary. It is not where people expect. The gaps are rarely technical skills that could be learned in a month; they are disciplines with their own failure modes, where the cost of not knowing what you do not know is high and delayed. Knowing which of those you can safely leave uncovered is the useful part.
Where does the range actually stop?
At the disciplines where the risk is invisible until it is realised. Security, data engineering, database administration at scale, infrastructure under real load, product design, and anything involving statistical models. A generalist can work in all six and will produce something that functions in each of them.
The distinction that matters is between producing something that works and knowing what could go wrong. A full-stack developer will implement authentication that lets the right people in. Whether it also keeps the wrong people out under conditions nobody demonstrated is a different question, answered by a different kind of experience.
This is not a criticism of generalists. It is a description of what specialism is: a long memory of failures in one narrow area. No breadth substitutes for that, and no amount of care compensates for never having seen the failure.
Which gaps can you safely leave open?
Most of them, for a while, and the honest answer depends on scale and on what your product holds. Set out plainly, it is clear which gaps are a matter of quality and which are a matter of exposure.
| Discipline | A generalist covers | It stops at | Cheapest cover |
|---|---|---|---|
| Security | Authentication, access rules, dependency updates | Threat modelling, and anything holding payments or health data | A scoped external review before launch and yearly |
| Databases | Schema design, indexes, reading a query plan | Replication, failover, tuning under sustained load | Managed database with automated failover |
| Infrastructure | Deploying and running a normal web application | Multi-region, capacity planning, cost at scale | A platform that removes the choice, until it costs too much |
| Data engineering | Reports and exports from the operational database | Pipelines, history, reconciliation, warehousing | Defer entirely until someone asks the same question twice |
| Product design | Reasonable interfaces from a clear pattern | Research, information architecture, novel interactions | A designer for a few days per significant feature |
| Machine learning | Calling a model API and handling the result | Training, evaluation, knowing when the output is wrong | Do not build it in-house first |
Which gaps are dangerous rather than merely missing?
Three, and they share a property: the failure is silent until it is catastrophic. Security is the obvious one, and the specific danger is not a missing feature but an assumption nobody stated, such as an endpoint that checks who you are and not what you are allowed to see.
Data loss is the second. Backups that exist and have never been restored are the standard example, and every generalist knows this in principle. The gap is not knowledge, it is that restoring a backup is a day of unglamorous work with no visible output, so it does not happen unless somebody schedules it.
The third is anything with a regulatory dimension. Payment handling, health information, and personal data in jurisdictions with meaningful enforcement all carry requirements that are not discoverable by reading the code, and a competent developer will implement something reasonable that is nonetheless non-compliant. That gap is filled with advice, not with engineering.
Does hiring a second generalist help?
Not for these gaps. Two generalists have roughly the same shape, so the second hire doubles your capacity and leaves the boundary exactly where it was. This is the most common expensive mistake at the point a small team starts to feel the limit.
It does help with a different problem, which is worth separating. A second developer gives you review, a second opinion, and continuity when one is away. Those are real benefits and they are about resilience rather than about reach.
So the question to ask before the second hire is whether the pain is volume or type. If work is queuing, a second generalist is right. If work is stalling on a class of problem nobody can start, another generalist will not unstick it.
How do you cover a gap without hiring?
Buy the discipline rather than the person, in the smallest unit available. A security review scoped to a specific application, a few days of a designer, an experienced engineer on a monthly review call. These arrangements are unfashionable and they cover the risk at a fraction of a salary.
Managed services are the other route and are usually underused by small teams. A managed database, a managed queue, and a platform that handles deployment remove entire disciplines from your scope. The cost is money and some flexibility, and both are worth it until the bill becomes a line item somebody notices.
Whichever route you take, arrange it as a recurring commitment rather than a one-off. A single review at launch verifies the state of the system on one day, and the value of these arrangements comes from repetition.
What is the test that you have hit the limit?
Work stops being estimated. When a developer who normally gives you a confident rough figure starts saying they will need to look into it, and that answer repeats for the same category of work across several weeks, they have reached the edge of their experience. It is a reliable signal and it arrives early.
The second signal is recurrence. If the same kind of problem returns after being fixed twice, the fixes are addressing symptoms because nobody has the depth to see the cause. Counting recurrences by category is a five minute exercise on any issue tracker and it points directly at the missing discipline.
The third is the question nobody in your company can answer. Write down the three technical questions you would most like a definite answer to. If nobody internal can answer any of them, that is your gap, and it is usually cheaper to buy an answer than to hire for it.
Common questions
- What is outside a full-stack developer's range?
- Six disciplines where the risk is invisible until realised: security threat modelling, database administration at scale, infrastructure under real load, data engineering, product design research, and statistical modelling. A generalist can work in all six and produce something that functions. What they lack is the long memory of failures in one narrow area, which is what specialism actually is.
- Which technical gaps are actually dangerous for a small team?
- Three, because the failure is silent until it is severe. Security assumptions nobody stated, such as an endpoint checking who you are but not what you may see. Backups that exist and have never been restored, which is a scheduling failure rather than a knowledge one. And regulatory requirements around payments, health data or personal data, which are not discoverable by reading code and are filled with advice rather than engineering.
- Should you hire a second full-stack developer to cover skill gaps?
- No. Two generalists have the same shape, so the second hire doubles capacity and leaves the boundary where it was. It does solve a different problem, giving you review, a second opinion and cover when one is away, which is resilience rather than reach. Before hiring, ask whether work is queuing or stalling: queuing calls for capacity, stalling calls for a different discipline.
- How do you cover a specialist gap without hiring a specialist?
- Buy the discipline in the smallest unit available: a security review scoped to one application, a few days of a designer per significant feature, an experienced engineer on a monthly review call. Managed services cover others outright, since a managed database or deployment platform removes a whole discipline from your scope. Arrange these as recurring commitments, because a single review only verifies one day.
- How do you know a developer has reached the limit of what they can carry?
- Estimates stop. A developer who normally gives a confident rough figure starts saying they need to look into it, repeatedly, for the same category of work. The second signal is recurrence: the same class of problem returning after two fixes means the fixes are addressing symptoms. The third is writing down the three technical questions you most want answered and finding that nobody internal can answer any of them.
