What "Full Stack" Should Actually Mean

Job listings for "full stack developer" mostly describe a frontend developer who is comfortable writing a CRUD endpoint. That's a real and useful skill set. It is not the same thing as owning a feature end to end, and the difference shows up exactly where teams split the work.

Where the seams show

Split a feature across a frontend contractor and a backend contractor, and the API contract between them becomes a negotiation instead of a decision. The frontend wants a shape that's easy to render. The backend wants a shape that's easy to persist and validate. Both are reasonable. Neither person can unilaterally resolve the tension, because neither owns both sides — so the contract gets renegotiated mid-project, usually after one side has already built against the old version.

The same thing happens with error states. A backend developer who never has to render a loading spinner tends to under-specify what a failure response looks like. A frontend developer who never has to reason about retry semantics tends to assume every request either succeeds or shows a generic error toast. The result is a feature that works in the demo and falls apart the first time a request times out halfway through.

What ownership actually buys you

On Pharos — the billing and inventory product I've been building solo — the sale-document screen has to behave differently depending on whether it's an invoice, an estimate, or a delivery challan: different totals, different validation, different effect on stock and GST posting. That's not a frontend decision or a backend decision. It's one decision, made once, that happens to have a UI half and a schema half.

Deciding that a converted estimate stays visible as "Invoiced" instead of disappearing is simultaneously a UX call (the biller shouldn't lose track of where a document went), a schema call (the record needs a status field and a link back to its origin), and an audit-trail call (accounting needs to see the conversion happened). Splitting that decision across two people means someone has to fully explain the other two-thirds of it before either can act — or, more realistically, one side makes the call without the context and the other finds out during QA.

I saw the same pattern building a non-custodial wallet extension: the encrypted local storage design and the UI that reads from it aren't separable concerns. Get the storage schema wrong and the UI has nowhere sensible to represent partial state. Get the UI's assumptions about load time wrong and the storage layer gets asked to do synchronous work it shouldn't.

The actual definition

Full stack, to be a meaningful hire rather than a job-title exaggeration, means: the person can look at a feature, decide the data model, build the API, build the interface that consumes it, and ship the pipeline that deploys both — and when those four things pull in different directions, the same person feels the tension and resolves it, instead of it being negotiated across a Slack thread between two specialists who each own half.

That doesn't mean full-stack developers are better than specialists — plenty of problems genuinely need deep frontend or deep backend expertise, and a generalist who's mediocre at both halves is worse than either specialist. It means: for a feature where the interesting part is the seam between UI and data — which is most product features — one person owning the whole thing removes a coordination cost that specialists can't remove by being better specialists.