Role
Full stack engineer who owns the feature, not a layer
A feature has been in progress for three weeks. The API is done, the interface is done, and it does not work, because the two were built against different assumptions and neither person was wrong.
How I fit
I take a feature from the data model to the screen and out to the person using it. The value is not that I can write both halves, it is that the decisions get made together. Knowing what the query can return cheaply changes what the screen should ask for, and that knowledge only exists in one head when one head does both.
A challenge from this role
A feature is three weeks in. The backend is complete and tested. The frontend is complete and tested. Together they do not work, because the API returns what was easy to return and the screen needed something adjacent, and the mismatch only became visible at integration.
How I approach it
Start from the screen, always, because the screen is where the requirement is real. Sketch what the person needs to see and do, then work backwards to what the server must provide, then check whether that shape is cheap to produce. When it is not, the conversation happens immediately rather than in week three, and it happens between two constraints held by one person rather than as a negotiation. Build the thinnest slice end to end first, screen to database and back, before either half is complete, because integration is where the assumptions are hiding and it should happen on day two rather than day twenty.
What proves it
Schedulers, payment reconciliation, approval gateways and multi-tenant data design in production.
Dense operational screens used all day by staff under time pressure, designed as well as built.
Sole engineer on a platform, so every feature has been data model to screen to support call.
A thin slice end to end before either half is finished, which is where integration assumptions surface.
A coverage first site where the primary answer is served in one request, because the audience is on the worst connections.
The seam is where the time goes
Most product delay is not implementation. It is the gap between two correct implementations of slightly different assumptions.
An API returns what was natural to return. A screen needed something one shape away. Both were built carefully, both were tested, and the mismatch surfaces at integration, which is usually the point where the deadline has already been committed.
When one person holds both, that gap closes at design time rather than at integration time, and it closes silently, which is why it is invisible as a benefit and enormous as one.
Start from the screen
The screen is where the requirement is real. Everything upstream exists to serve it.
Starting from the data model produces a system that is coherent and subtly wrong, because the shape that is natural to store is rarely the shape somebody needs to act on.
Questions people actually ask
- Is full stack not just shallow on both sides?
- It can be. The honest test is whether somebody can point at production work in both halves that a specialist would respect. The engine and interface writing on this site is that test, offered so you can check rather than take my word for it.
- How do you avoid becoming the bottleneck?
- Write it down as you go, and design so that pieces can be picked up without a meeting. Owning a feature end to end does not have to mean being the only person who understands it, and that difference is entirely a documentation habit.