Full-stack developers
A full-stack developer carries a change the whole way — from the shape of the data through the interface a person uses to do something with it. The value is not that one engineer knows everything, because none do. It is that a feature stops being handed between people, and this guide is about when that trade is worth making and when it is not.
What does a full-stack developer do?
A full-stack developer builds complete features across both the server and the interface: the schema change, the queries, the API or server action, the screens that consume it, and the tests and deployment that put it in front of users. The defining characteristic is ownership of a vertical slice rather than a layer, which removes the coordination cost of splitting a single feature across two people — at the price of less depth than a specialist has at either end.
The economics are worth stating plainly, because they explain both the popularity of the role and its limits. Splitting a feature across two engineers requires a contract agreed before either can start, written down, kept current and renegotiated whenever the product moves. One engineer holding both ends skips all of that. For small features and unsettled requirements the saving is substantial; for large surfaces with stable contracts it mostly disappears — which is why the same hire looks obviously right in one team and obviously wrong in another.
The breadth is genuine but it is not free, and pretending otherwise is how teams end up disappointed. Time spent following the rendering and accessibility landscape is time not spent on query planning and concurrency. A capable full-stack engineer knows where their own knowledge thins out and says so rather than improvising through it — and the places most often improvised through are the ones with delayed costs: accessibility, indexing, authorisation and anything with simultaneous writers.
In practice the role has consolidated around a smaller technical footprint than it once had. One language across both sides, shared rather than duplicated types, a framework that renders on the server and hydrates on the client, and a managed data layer have narrowed the distance an engineer must travel. The breadth is more attainable than it was, but the work has not changed — the difficult parts of each layer are still difficult, and the seam between them is where most of this role’s interesting decisions are made.
When teams need this capability
Full-stack is a shape of responsibility rather than a fallback for teams that cannot afford specialists. These are the conditions under which that shape genuinely outperforms a split.
Features are stalling at the handoff
Work sits waiting for an endpoint that is nearly ready, or waiting for a screen that cannot start until a response shape is agreed. When the coordination overhead between two engineers exceeds the work itself, giving one person the whole slice removes the queue rather than shortening it.
The domain is still changing shape
Early product work rewrites its own model repeatedly. A frozen API contract is an obstacle in that phase, because the contract is the thing being discovered. One engineer moving the schema, the endpoint and the screen together can follow the product wherever it goes without a negotiation each time.
The team is too small for a per-layer split
Below a certain size, dividing by layer creates specialists who are individually idle and collectively blocked, because the work does not arrive in a balanced ratio. Dividing by feature keeps everyone unblocked and spreads knowledge of the system across more than one person.
Internal tooling has to exist but cannot justify a team
Admin consoles, back-office workflows, operations dashboards and support tooling are unglamorous, genuinely valuable, and rarely the top priority for either specialism. They are close to ideal full-stack work: modest interface demands, real data modelling, and a clear internal user to talk to.
Support and on-call work spans the layers
A bug report describes a symptom, not a location. Someone who can follow a wrong number from the screen back through the API to the query resolves it in one pass, where a layer-bound engineer can usually only establish that the fault is not theirs.
Core capabilities
Vertical slice delivery
Taking a requirement through schema, server logic, interface and release as a single unit of work, including the parts that are nobody’s favourite: migrations, permissions, empty states and the rollout plan. The skill is sequencing so that the slice stays deployable throughout rather than landing as one large change.
Boundary and contract design
Deciding what the server computes and what the client derives, how much a response should contain, and where each shape is defined. The seam is where full-stack engineers are most valuable, because they can see both consequences of a decision without having to describe either to someone else.
Pragmatic data modelling
Designing a schema that supports the product’s queries, holds its invariants through constraints, and can be migrated safely once real records exist. This is depth applied to the common cases rather than to the exotic ones, and knowing which is which is part of the capability.
Interface implementation to a standard
Building screens that handle their loading, empty and error conditions, work across viewport sizes, and remain operable by keyboard. The bar is a competent interface rather than a distinguished one, and holding even that bar consistently is what separates full-stack engineers from backend engineers doing interface work unwillingly.
Authentication and session handling
Login, sessions, tokens, refresh, redirects and route protection are a single flow that happens to be implemented in two places. It is an area where a split ownership model produces gaps, and where whole-flow ownership is a genuine advantage.
Trust boundaries and validation
Understanding that validation in the interface is there to help the user and validation on the server is the only thing enforcing the rule. A full-stack engineer usually writes both, which makes it their responsibility to keep them consistent without letting the client version be mistaken for a control.
Cross-layer debugging
Tracing a defect from a reported symptom through network activity, server logs and the query that produced the value. This is the capability that most clearly rewards breadth, because the diagnosis rarely stops in the layer where the symptom appeared.
Knowing the edge of their own depth
Recognising when a problem has crossed into specialist territory — a complex accessibility pattern, a query that needs real optimisation, an authorisation model with genuine subtlety — and raising it rather than producing a plausible answer. This is the single most valuable trait in a full-stack engineer and the hardest to interview for.
Product judgement
Scoping a feature to what is achievable, proposing a cheaper variant that gets most of the outcome, and asking the question that removes a requirement. Engineers who see the whole slice are unusually well placed to notice when the expensive part is not the valuable part.
Technology ecosystem
Common technologies in full-stack engineering are listed below. This describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit — and because full-stack work is defined by its span rather than its tools, the more useful signal is which combinations a candidate has carried into production together.
Languages
- TypeScript
- JavaScript
- Python
- PHP
- Ruby
- Go
- C#
Full-stack frameworks
- Next.js
- Nuxt
- Remix
- SvelteKit
- Rails
- Laravel
- Django
- Phoenix
Interface layer
- React
- Vue
- Svelte
- Tailwind CSS
- TanStack Query
Server and API
- Node.js
- NestJS
- Express
- FastAPI
- tRPC
- GraphQL
- REST
Data access
- PostgreSQL
- MySQL
- SQLite
- Prisma
- Drizzle
- Redis
Identity and services
- OAuth 2.0
- Auth.js
- Clerk
- Keycloak
- Stripe
- S3-compatible storage
Delivery and testing
- Docker
- GitHub Actions
- Vercel
- Playwright
- Vitest
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
The failure mode when hiring for this role is accepting a wide list of technologies as evidence of a wide capability. Breadth on a curriculum vitae is easy to assemble; breadth that has survived production is not. Assess the shape of the experience rather than its surface area.
Honest self-assessment
Ask directly which half of the stack they are weaker at. Almost every full-stack engineer has a stronger side, and the ones who claim otherwise are usually the ones who will not raise a problem when they should.
- Names a specific weaker area without prompting or defensiveness
- Describes how they compensate — asking, reading, or deliberately narrowing scope
- Can identify work they would hand to a specialist rather than attempt
Evidence of complete ownership
Ask them to walk a feature from the first schema change to the moment users had it. The detail in the unglamorous middle — migration, permissions, error handling, rollout — tells you whether they owned it or contributed to it.
- Can describe the migration and how it was sequenced against the deploy
- Remembers the states and edge cases, not only the happy path
- Talks about what happened after release, including anything that went wrong
Reasoning at the boundary
The interesting decisions in this role are about what belongs on which side. Ask how they decide whether a calculation runs on the server or in the client, and listen for the criteria rather than a habit.
- Weighs payload size, trustworthiness and change frequency, not just convenience
- Keeps rules that must always hold on the server
- Has a coherent story for where shared types or shapes are defined
Depth where it is unavoidable
Breadth is acceptable everywhere except in the few places where a shallow decision compounds. Probe indexing, authorisation and concurrent writes specifically — these are the ones that look fine in review and become expensive later.
- Can explain why a particular query needed an index and how they confirmed it
- Enforces access control where the data is read, not in the interface
- Notices when two users could act on the same record simultaneously
Interface standards they will not drop
A full-stack engineer under delivery pressure decides how much interface quality to keep. Ask what they always do regardless of the deadline — the answer describes their actual floor.
- Builds loading and error states as part of the feature, not afterwards
- Checks keyboard operability without being asked to
- Can say what they would cut under pressure and what they would not
Cross-layer diagnosis
Give them an ambiguous symptom — a value displayed incorrectly — and ask how they would locate the fault. This exercises the exact advantage the role is bought for.
- Narrows systematically from what the user sees back toward the source
- Uses network inspection and server logs together rather than guessing a layer
- Confirms the cause before changing code
Judgement about their own fit
Ask when they would advise a team to hire a specialist instead. A candidate who can argue against their own placement has thought about the tradeoff seriously, and will be a better colleague when the work outgrows them.
- Can describe a project where breadth was the wrong purchase
- Distinguishes work that needs depth from work that merely looks difficult
- Has worked alongside specialists and describes the boundary without friction
Interview questions worth asking
These questions are aimed at the tradeoff rather than the technology, because that is where this role succeeds or disappoints. They are written for you to use in the interviews you run; judging the answers, and choosing who joins, stays with your team.
Which side of the stack are you weaker at, and what do you do about it on a project where it matters?
What a strong answer shows
Calibration, which is the trait that makes breadth safe. A specific, unhurried answer with a compensating strategy is a good sign. A claim of even strength across everything usually means the candidate has not been close enough to either end to find the floor.
Take a feature you built end to end and walk me from the schema change to the release.
What a strong answer shows
Whether the ownership was real. The revealing details are in the middle: how the migration was sequenced, what permissions were involved, which states were built, and how it was rolled out. Contributors describe outcomes; owners describe order.
How do you decide what the server returns versus what the client works out for itself?
What a strong answer shows
Boundary reasoning. Look for criteria — payload cost, whether the rule must be enforced, how often it changes, whether another consumer will need the same answer — rather than a preference expressed as a principle.
You validate the same rule in the form and on the server. How do you keep them from drifting apart, and which one is the rule?
What a strong answer shows
Whether the trust boundary is understood. The server version is the rule; the client version is assistance. Strong answers also describe a mechanism for sharing the definition rather than a promise to remember.
A user reports that a total on screen is wrong. Nobody can reproduce it. How do you find it?
What a strong answer shows
The advantage of breadth applied to a real problem. Look for narrowing across layers, attention to what is specific to that user — their data, their permissions, their timezone, a cached response — and confirmation of the cause before a fix.
Describe something you built that a specialist would have done differently, and what it cost.
What a strong answer shows
Retrospective honesty about the limits of breadth. Engineers who have worked alongside specialists usually have a clear example. Engineers who insist nothing would have been different have either not been reviewed closely or have not looked.
When would you tell a team that a full-stack developer is the wrong hire?
What a strong answer shows
Whether they understand the role as a tradeoff rather than an identity. Good answers describe conditions: heavy interface demands, a large surface with stable contracts, hard reliability requirements, or a team already deep enough at both ends.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A small product team is delivering features that each touch the schema, the API and the interface. Every item requires two people to coordinate before either can start, and the coordination has become the slowest part of the process while the backlog continues to grow.
- Approach
- Additional full-stack capacity takes whole features from the same backlog, working to the conventions the team already applies — their branching model, their review expectations, their testing approach and their release process. What gets built, and in what order, is decided internally as it was before.
- What this adds to the team
- The team can run more work in parallel without adding coordination overhead to each item. Product direction, prioritisation and the standards the code is held to remain with the team that owns them.
Related disciplines
Frequently asked questions
- Is one full-stack developer equivalent to a frontend developer and a backend developer?
- No, and expecting that is the most common way this hire disappoints. One engineer produces roughly one engineer’s output, with less depth at each end and no coordination cost between them. The comparison is different rather than cheaper: a full-stack engineer delivers complete features sooner, while two specialists deliver more total work and hold a higher ceiling in their areas. Which is better depends on whether your constraint is throughput or difficulty.
- Is full-stack a genuine specialism or a compromise?
- It is a specialism in integration rather than in a layer. The distinctive skill is seeing a feature whole — choosing where a responsibility belongs, keeping both sides consistent, diagnosing across the seam — and that is not something a layer specialist automatically has. It becomes a compromise only when it is bought for work that needed depth, which is a purchasing error rather than a fault in the role.
- When is a full-stack developer the wrong choice?
- When the difficulty concentrates at one end. Products with demanding interface requirements — complex interaction, strict accessibility conformance, serious performance budgets — want frontend depth. Products with high write volume, intricate domain rules or hard reliability targets want backend depth. Large teams with stable contracts also lose the coordination saving that justifies the role, because the contracts have already been negotiated and no longer need to be discovered.
- Do full-stack developers handle infrastructure and deployment as well?
- Usually enough to ship their own work: containers, environment configuration, a CI pipeline, migrations and a release they can perform safely. That is different from owning the infrastructure. Cluster design, networking, cost management and platform reliability are a separate discipline, and treating deployment familiarity as infrastructure ownership is how teams end up with production environments nobody can confidently change.
- How do you assess breadth without the interview becoming superficial?
- Go deep in a few places rather than sampling widely. One end-to-end feature examined closely tells you more than a tour of every technology on the CV, because the follow-up questions expose whether the knowledge is load-bearing. Then probe the areas where shallowness is expensive — indexing, authorisation, concurrent writes — and treat a clear admission of uncertainty as a positive signal rather than a gap.
- What seniority does full-stack work require?
- Breadth without judgement is risky, so this role generally rewards experience more than a layer-bound one does. A mid-level engineer works well where conventions are established and someone else is reviewing the consequential decisions. Where a full-stack engineer will be setting the schema, the boundary and the interface standards largely unsupervised, seniority matters — there is no specialist alongside them whose review would otherwise catch a shallow choice.
- How do full-stack developers work with an existing engineering team?
- Staff augmentation places them inside your team’s process — the priorities you set, the conventions you have agreed, the reviews you run and the architecture you have chosen. You direct the work. Talent.ID’s part is the employment relationship: payroll, employee benefits, talent administration and the continuing relationship with the employee.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.