Full Stack Dev Guide

"Full stack" turns up in job ads, agency pitches and LinkedIn bios, usually with no definition attached. Here is what it actually means, what it doesn't, and why it matters if you are paying for software to be built.

The short version

Every app or website has a few layers between the person using it and the information behind it. A full stack engineer works across all of them, instead of owning one slice and handing the rest to somebody else.

Take a customer tapping "Book now". Before that tap becomes a confirmation email, it passes through four layers:

• The front end. The screens, buttons and forms people see and touch, in a browser or on a phone.
• The back end. The rules that run behind the screen: checking a login, working out a price, making sure two people can't book the same slot, talking to your payment provider.
• The database. Where the information lives: customers, orders, bookings, everything you will need to look up later.
• The infrastructure. The servers and hosting that keep it running, the process that puts a change live, and the monitoring that tells someone when it breaks.

"Full stack" means the same person, or the same small team, is responsible for all four.

A mobile app fits the same picture. It is another front end, talking to the same back end and the same database as your website. That is why one team can build web and mobile together without the two drifting apart.

What it does not mean

It doesn't mean one person who is world-class at everything. Nobody is. Deep specialists still exist, in security, in performance at huge scale, in brand and interface design, and some projects need them.

It isn't about a particular tool either. The languages and frameworks change every few years. The job doesn't: owning the whole path from the screen, through the rules and the data, to something live that people can use.

What it does mean is that nobody involved treats their layer as the edge of the world. A front-end developer who understands the database asks for a sensible shape of data instead of working around a bad one. A back-end developer who has seen the screen builds what the screen actually needs.

Why the handoffs are the real problem

Split a project across separate people or companies for design, front end, back end and hosting, and every boundary becomes a handoff. Each one costs something. Context gets lost, questions wait in a queue, and each group can finish its own part while still waiting on another.

You can spot the symptoms in a status report. The screens are "done", but there is nothing for them to talk to. The back end is "done", but nobody has worked out how to put it live. A small change needs three people and a week.

When one team owns the whole thing, a change to a form field and to the database behind it happen together. The answer to "why didn't that email send?" comes from someone who can go and look, not from a ticket that gets passed along.

A feature isn't finished when the code is written. It's finished when someone can use it.

What it looks like on a real project

Say a small business wants an online booking system to replace phone calls and a shared spreadsheet. (This is an illustration, not a client story.)

With a full stack team, the same people:

1. Agree with you what the first version has to do, and what it doesn't.
2. Design the booking screens and build them.
3. Build the rules: opening hours, no double bookings, what happens when someone cancels.
4. Set up the database that holds every booking.
5. Wire up the confirmation and reminder emails.
6. Put the whole thing on a real web address, and keep an eye on it after launch.

You deal with one team. You see it working on a real address as it develops, and when something looks wrong, you know who to ask.

When you need it, and when you don't

Full stack is the right shape when you are building something with moving parts: a customer-facing app, an internal tool that replaces spreadsheets, a product with logins, payments or stored data. Those pieces have to agree with each other, and a team that can see all of them makes fewer mistakes at the seams.

You probably don't need it if what you want is a marketing site: something that shows what the business does and lets your team update pages. That is a website job, not an application job, and an editable CMS site or a hand-built one will be quicker and cheaper. At the other end, if you run a very large platform with its own infrastructure and security teams, you will want specialists alongside anyone who works across the stack.

The honest trade-offs

Working across the stack has downsides too. A team that covers everything can't always match a specialist in one narrow area, such as a very distinctive visual identity or a heavily regulated payments set-up. And a small full stack team has limited hands: it can do a great deal in the right order, but it is not a room of twenty people working in parallel.

What you get in exchange is fewer handoffs, faster answers and one place to point when something goes wrong. For most small and mid-size businesses, that is a trade worth making. The useful thing is to know that it is a trade, and to ask any team you are considering where their limits are.

Four questions to ask any team that says "full stack"

The label is easy to claim. These questions show whether it is true:

1. Who deploys it, and who fixes it when it breaks? The answer should be the same team that built it.
2. Can I see it running before it is finished? You should be able to click through a working version on a real web address, not just look at screenshots.
3. What do I own at the end? You should get the code and the documentation, so you are not locked in.
4. What happens when the scope changes? A good answer is that they tell you early and price the change before doing the work.

These are the questions we hold ourselves to. At SAMX, we fix the price and the launch date in the first week, you see a working demo every week, and at launch you get the repository and handover documentation.

If you are weighing up a build, the full-stack web and mobile service page has the detail. Or tell us what you are trying to build and we will say honestly whether it is a fit.