Full-stack Developer

Shipping one feature takes two layers: the frontend, the screens people see and operate, and the backend, where the data and the rules behind those screens are handled. Even a comment notification needs a place to store the notification, a rule deciding whether to send it, and a red dot at the top of the screen.

Splitting those two across two people costs something. The shape of the data they'll exchange has to be agreed in a meeting, whoever finishes first waits for the other, and a changed requirement means agreeing again. In an organization with three layers and six people that cost is affordable. On a team with three people building, the time spent coordinating runs past the time spent building. Putting two people on one feature doesn't halve the build; it adds a new job of keeping them aligned.

Early-stage meeting notes repeat the same lines because of it. The server is ready but the screen isn't. If you send the value in that shape I have to convert it again on the screen. Who's fixing this one. More time went into waiting for each other than into anything that was actually hard. This role starts as a way to delete that waiting by letting one person carry a feature from end to end.

The feature gets cut vertically rather than horizontally — one person pushes it all the way down. Take that comment notification and the day runs like this.

1. Decide the stored shape. A notification holds who, on what, when, and whether it's been read, and that record needs a place in the database, which is what keeps such records and hands them back on request. The shape chosen here constrains every later step.
2. Write the rules. No notification for your own comment, and several comments on one document collapse into a single notification. These judgments belong on the server, not on the screen. Filter on the screen instead and every new path that sends a notification means writing the same rule again somewhere else.
3. Build the channel between the two layers. An API is the agreement about what gets exchanged and in what shape — and since the same person builds the screen, it can be defined to return exactly what the screen needs. That removes the step where one side reshapes what the other side sent.
4. Build the screen. Show the unread count, draw the list, open the right document when a row is tapped, and build what it looks like while loading and when there's nothing to show. An unread count that never clears is the kind of bug that only surfaces with both sides in view: the server marks the notification read while the screen keeps its own copy of the number, and nothing tells the copy to change.
5. Ship it. The merged code goes out through CI/CD, which checks it automatically and puts it on the server if nothing is wrong, and then the notification gets verified where it actually lands.

Going end to end alone makes the second pair of eyes matter more. Code review, where a colleague reads the change before it merges, is where someone fluent in only one of the two layers catches what the other missed.

Because the conversation between layers happens inside one head, the conversations that leave it are aimed at decisions rather than handoffs.

What gets built is settled with the product manager. Seeing both layers makes it possible to trade scope against cost in the same sentence: pushing notifications in real time is three days, checking every 30 seconds is half a day, pick one.

The shape of the screen is settled with the product designer. Mockups come across and get built, and when the data structure means a screen can't show something yet, that gets said on the spot. From the designer's side, the screen question and the server question go to the same person.

Technical direction is shared with the tech lead. Pushing down alone makes it easy to introduce approaches that drift from the team's standards, so the line between what gets decided alone and what gets decided together is drawn in advance. Anything that reaches across the whole product — scaling servers up and down, deployment paths — goes to the DevOps engineer, who owns deployment and operational automation.

"I'll carry this one end to end. Doing the screen alongside it is faster."

Meaning the feature won't be split across layers.

"No need to reshape the response. I'll return it from the server in exactly the shape the screen wants."

Building both sides means the intermediate step can go.

"Full-stack doesn't mean all of it. Deployment should go to someone else."

Drawing the boundary of the role.

When Pagedeck had ten people, Theo built document sharing end to end: the place to store share links, the rules attaching an expiry date and a password to each link, and the dialog that opens when someone hits share. It went out in a week.

At forty-five people the way of working survives, but what it gets pointed at has changed. Work that goes deep into one layer, like billing or permissions, goes to the specialist for that layer, and Theo takes the features that touch several layers a little: comment notifications, exports — small work in each layer and no way to skip any of them.

The most common mistake is reading it as someone good at every technology. The name contains a word meaning all of it, so that's the reading. What it actually describes is the ability to push one feature all the way alone, and the depth is usually tilted to one side: strong on the server and able to build a screen without help, or the reverse. Write a job posting without knowing the difference and it asks for screens, servers, infrastructure, mobile, and data. Nobody applies, and anyone hired against a list like that leaves once five jobs' worth of expectation arrives.

A companion mistake is assuming the depth is necessarily shallow. Covering a wide span makes it look that way. But bugs and design errors mostly appear between layers rather than inside them — a value returned in a shape that's awkward to use on the screen, a failure case nobody decided what to display for. One person watching that boundary closes those gaps. Remove the role entirely because the organization got bigger and the opposite shows up: one feature passes through three people's agreements before it ships, and the problems stuck between layers get pushed back and forth as somebody else's.