The Responsibility Spine.

You can feel it before you can name it.

It usually arrives as a feeling before it has a name. A small change takes longer than it should. A fix here breaks something over there. Every change starts with a search. One person becomes the only one who really understands a part of the system. And then someone lets an AI write more of it, and now no one is sure where anything lives.

The reflex is to blame the code, or the developer, or “tech debt.” But the pattern underneath is quieter and more mechanical: things kept getting added, and the places they should live were never decided on purpose. Speed turned into uncertainty, uncertainty into investigation, investigation into delay, and delay into the fear that makes a team stop touching the parts that matter most.

A prototype treats a feature as one thing. A product can’t.

In a prototype, a feature is one thing: it works on the screen. In a product, that same feature quietly becomes several. It needs a rule, an email, an admin action, a piece of data, a permission, an error case, and a place to run.

Each of those parts is a responsibility, and each one needs somewhere to live. The feature you asked for was one thing. The feature the product has to carry is seven.

Not deciding is still a decision.

Here is the part that is easy to miss: not deciding where a responsibility belongs is not the same as making no decision. It just hands the decision to whatever is nearest. The closest file decides. The fastest patch decides. The prompt you gave the AI decides. A developer’s end-of-day fatigue decides. A database flag decides. A check bolted onto the frontend decides.

Left alone, those parts still get placed — just not on purpose. A business rule ends up copied into the frontend, the admin, and a nightly job. The truth about what the product actually does migrates into one person’s head. None of that is bad code or a bad developer. It is what growth does to a product when no one decides where things go.

Either responsibility is placed deliberately, or it spreads accidentally.

The set of homes is the spine.

Give every responsibility one clear home, and those homes — taken together — form a structure. That structure is the product’s Responsibility Spine: the running shape of the system where each important responsibility has one place to live, so adding a feature is not a fresh argument every time.

It is not only a technical object. It is a decision-support structure. Once it exists, the whole team can answer the questions that used to start an argument:

• Where does this rule belong?
• Where does this data belong?
• Where does this email come from?
• Where does this admin action live?
• Where does this failure become visible?
• Where does the next feature attach?

A product without a spine answers those questions too — silently, by accident, a little differently every time someone ships under pressure. A product with one answers them out loud, the same way, every time.

The spine is found, not generated.

Building a spine is not adding more structure for its own sake. It is closer to the opposite: finding the structure that is already trying to exist. Most of what looks like ten different features is really the same few responsibilities showing up in different states. The work is recognising that — asking, of each new thing: is this truly different, or is it the same responsibility appearing in a new form?

Get that question right and the product stays small at its core while it grows at its edges. Get it wrong — force together things that are not the same, or split apart things that are — and you get either a tangle or a pile of special cases. This is the part that takes judgment, and it is why a spine cannot simply be generated from a template.

Software does not only need features added. It needs the common shape between features found.

Why it is the part most teams skip.

None of this is secret. Most teams skip it anyway — not from carelessness, but from pressure. There is no time to step back. There is no architect in the room. The product owner wants the next visible feature. The developer is rewarded for shipping. An AI can produce working code in seconds. Against all of that, stopping to ask “where does this belong?” feels like overhead.

It is not overhead. It is what prevents overhead later. But it is genuinely hard — it asks you to see the shape of a system before the system is finished — and the hard, unglamorous work that has no deadline is exactly the work that gets skipped. That is why placing responsibility is, at once, one of the most important parts of building a product and one of the most consistently overlooked.

Slow once, faster afterwards.

Building the spine is not the fastest way to ship the first feature. It asks for a little time up front to decide where things go. The payoff is everything after: the second feature reuses the homes instead of inventing them, the tenth still has somewhere to land, and changes stop turning into searches.

A product does not grow well by only adding features. It grows well by adding a feature, then folding what that feature revealed back into the spine — so the structure gets clearer as the product gets larger, instead of muddier. The feature works either way. The difference is everything that comes after it.

Not the fastest way to ship the first feature. A faster way to keep adding them after the first one works.

What this means when AI writes the code.

AI changes the economics of writing code, but not the economics of placing responsibility. It makes generation cheap; it does not make the structure clear. Pointed at a system with no clear homes, an AI puts new code where the prompt points, where the nearest example sits, where the current context makes it easiest — which means it can produce entanglement just as fast as it produces features.

So the value of a spine goes up, not down, in an AI-heavy workflow. A product with clear homes is one a human or an AI can keep building safely, because the next change has an obvious place to go. That is why the written guide that ships with the work — the architecture notes, the rules, the continuation file — is part of the deliverable, not decoration. It is the interface between the spine and whoever continues the product next, human or model.

We leave the product in a shape where humans and AI can continue it without guessing where things belong.

What Smallbox actually builds.

Smallbox builds your product’s first Responsibility Spine: one deployed .NET product with the places a growing product needs already in place — accounts, an operable admin, transactional email, failures you can find, a real deployment. Then it does the part that proves the structure is real: it wires one of your actual workflows through all of it, end to end.

The diagram is not the deliverable. The deliverable is one real product workflow travelling through the spine — which is the only honest proof that the homes are in the right places and connect the way they should.

Timing is the whole point. Before a prototype, the product is too uncertain to know what its first real workflow even is. After it has grown into accidental structure, placing responsibility is not placement anymore — it is moving live behaviour: user habits, admin actions, data shape, emails, jobs, reports, deployment assumptions. It is cheaper to place responsibility before it spreads than to recover it after it has become behaviour. The window is after the prototype works and before the product hardens — and that is the window this is built for.

The Foundation Map: the modules a spine is assembled from →

The live architecture map: every service behind both products →