“Full stack” means nothing until somebody defines it.
Used loosely it describes anyone who has touched both a browser and a database. Used properly it means strong in two layers, competent in the rest, and able to tell you which is which.
Nobody is excellent at all four layers. Say which two.
Interface, API, data and delivery are four disciplines with four different bodies of knowledge. An engineer who claims equal strength across all of them is either inexperienced enough not to know what they do not know, or is telling you what the advert asked for.
What exists, and is genuinely valuable, is an engineer who is strong in two, competent in the other two, and can say without prompting which is which. That person can own a feature end to end and knows when to ask for help, which is the property you are buying.
So every profile we put forward names the two. If you need someone strong on the interface, we will send you an engineer whose depth is there and whose API work is solid, not exceptional, and we will say so.
When full stack is the right hire is a separate question with a fairly clear answer: below about six engineers, splitting the roles costs more in handoffs than it returns in depth. Above that, specialists win, and the full-stack engineers become the people who can move between teams when something is stuck.
Which stack, and what it suits.
The retired MEAN, MERN, PHP, JavaScript and web-developer pages all point here, because in practice they were describing the same hire with different letters.
| Stack | What it is | Suits |
|---|---|---|
| MERN | MongoDB, Express, React, Node | Products moving fast with a small team and one language throughout |
| MEAN | MongoDB, Express, Angular, Node | The same, where the team is Angular-shaped |
| PERN | PostgreSQL, Express, React, Node | What we would usually recommend instead; relational by default |
| PHP / Laravel | Laravel, MySQL, Blade or Inertia | Content-heavy applications, fast delivery, the widest hiring pool |
| .NET + React | C#, ASP.NET Core, React, SQL Server | Enterprise environments already on Microsoft |
| Django + React | Python, Django REST, React, PostgreSQL | Where data or ML work sits close to the product |
What we ask a full-stack engineer.
The questions are chosen to find the boundary of what somebody knows, which is the whole point in this category.
Which two layers are you strong in?
Asked directly. A confident, specific answer is a good sign; “all of them” is not.
Design the schema for this feature.
Data modelling is the layer most often weak in self-taught full-stack engineers, and the one where mistakes are most expensive to undo.
What happens between merge and production?
The delivery layer. Engineers who have never owned a deployment tend to write code that is difficult to deploy safely.
Where would you put this logic, and why?
Client, API or database. The reasoning matters more than the answer, and it predicts what the codebase looks like in a year.
What is the last thing you learned properly?
Full stack requires continuous breadth. An engineer who cannot name something recent has usually stopped.
When would you tell us to hire a specialist?
Self-awareness about the limits of breadth. The best answers here are specific and immediate.
When full stack is right, and when it is not.
We staff specialists too, so this costs us nothing to write accurately.
- Right: a team under about six engineers. Handoffs between specialists cost more than the depth returns at this size. One person owning a feature end to end ships faster.
- Right: an internal tool or a first product version. Where the interface is functional rather than crafted, and speed of iteration matters more than depth in any one layer.
- Right: as connective tissue in a larger team. The person who can move to wherever the work is stuck is disproportionately valuable once you have several specialist teams.
- Wrong: when the interface is the product. Consumer-facing products with a design bar need a front-end specialist and a designer. A full-stack engineer will produce something competent and not more.
- Wrong: at real data scale. Once query performance, partitioning or warehouse modelling is the constraint, you need someone whose depth is there.
- Wrong: as a way to hire one person instead of two. If the honest requirement is two people's work, a full-stack hire buys you a backlog and a burnout instead of a saving.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring full-stack engineers.
Including the awkward question about whether the term means anything.
Is a full-stack developer just a generalist who is not very good at anything?
That is a fair caricature of a badly hired one, and it is not what a good one is. The distinction is depth in two layers instead of shallowness across four. An engineer who is strong on the API and the data model, competent on the interface, and comfortable deploying their own work can own a feature completely, no handoff, no waiting, no misunderstanding at a boundary. That is a real and valuable profile. The caricature is real too, which is why we ask every candidate to name their two layers and why we put it in writing on the profile you receive. If it turns out they were wrong about themselves, that is on us and we replace them.
MERN or MEAN, and does the choice matter?
The letter that matters is the M, and it is the one nobody asks about. React versus Angular is a real decision but it is mostly about your team and your hiring market. MongoDB as a default database is the choice more likely to cause you difficulty later: a great deal of business data is relational, and discovering that after two years of documents means either painful joins in application code or a migration. We would usually recommend PostgreSQL unless there is a specific reason for a document store, which makes the stack PERN and nobody has made an acronym out of that yet. If you already have a MERN or MEAN application, we staff both and this is not an argument for changing it.
Can one full-stack engineer replace a front-end and a back-end hire?
Only if the work is one person's worth. The honest test is throughput rather than capability: if your backlog needs two people's output, one full-stack engineer delivers half of it regardless of how broad their skills are, and the usual result is that whichever layer they enjoy least gets neglected. Where the saving is real is in coordination — one person owning a feature end to end removes handoffs, misunderstandings at the API boundary and the waiting that goes with them, which on a small team is worth a meaningful fraction of a person. Real, but not a whole hire.