Front end, back end, no dead ends

Here’s a project structure we inherit often: a design agency produced beautiful screens, a development shop was hired to build them, and eight months later the two are exchanging increasingly formal emails while the client pays for a system that doesn’t exist yet. Nobody is incompetent. The structure is.

The seam is where projects die

Software isn’t a relay race where design hands a baton to development. The two disciplines answer each other constantly: a screen turns out to need data the back end doesn’t hold; a technical constraint suggests a better interaction; a user test invalidates an assumption both sides built on. When design and development are separate companies, every one of those conversations becomes a change request, a quote, a scheduling exercise, and — eventually — a dispute about whose contract covers it. The work isn’t hard. The seam is.

What “full stack, one team” changes

• Decisions take minutes, not meetings. The person designing the screen sits next to the person building the API. “Can we?” gets answered before lunch.
• One definition of done. No gap between “matches the mockup” and “actually works” — the same team owns both.
• Accountability has one address. When something’s wrong, there’s no triangle of blame between designer, developer and hosting company. One throat to choke, as our clients cheerfully put it.
• The budget buys building. A surprising share of split-project cost is coordination: meetings, documentation written to protect positions, work redone because the handover lost context. One team spends that money on the product.

Questions that expose a seam

Interviewing suppliers? Ask: who writes the API, and who designs the screens that use it — same company? When a design turns out to be technically expensive, what happens to the quote? Who do I call when it’s slow in production? Vague answers to any of these are the sound of a future stall.

Beautiful screens that never shipped help nobody. Working software that’s miserable to use helps barely more. The whole point of building bespoke is that the thing works and feels right — and that only reliably happens when the people responsible for each half are the same people.