The Four-Week Vertical Playbook, and Our Own Scoreboard
The method for standing up a vertical on shared infrastructure in four weeks, followed by the registry that says how many of ours actually conform.
Why four weeks is possible at all
Almost nothing about a new vertical is new.
Every one of them needs to know who a user is, what a company is, how a person belongs to a company, how an API key is scoped, and how a permission gets overridden for one tenant. That is five entities, and they are identical whether the product rents excavators or books physiotherapy.
Above them sit the capabilities: nineteen packages under @inite/*, covering inbox, billing, incidents, notifications, i18n, security, storefront and knowledge among others, plus three horizontal services for auth, billing and brain. None of that gets rewritten either.
What is left is the part that makes the product itself: the domain objects and the workflows over them. For a rental business, the asset, the reservation and the dispatch. For a brokerage, the property, the listing and the deal. That is the only genuinely new code, and four weeks is how long it takes when everything underneath it already works.
The order that matters
| Week | What goes in | Why here |
|---|---|---|
| 1 | auth, tenant | Everything later depends on who is asking, for whom |
| 1 | api-kit | Uniform errors and limits before there are endpoints to unify |
| 2 | The domain model | The only genuinely new thing in the build |
| 2-3 | The main interaction: inbox or storefront | Whichever the product actually is |
| 3 | assistant, notifications | Useful once there is something to be assistant to |
| 4 | billing, security, i18n | Priced last because pricing changes most |
Identity first is the rule with the sharpest consequence. Retrofitting tenancy into a product that assumed one customer is the most expensive rework in this business, and it is the mistake that turns a four-week clone into a three-month one.
Billing goes late for the opposite reason. Pricing changes more often than identity does, and building it in week one means building it twice.
The scoreboard, unflattering
A playbook post usually ends with a count of successes. Here is the actual registry instead.
| Status | Count | What it means |
|---|---|---|
| production | 1 | Serving users |
| pilot | 2 | Actively calibrating the spec |
| migration_pending | 4 | Repo exists, intends to conform, data-model gap |
| drift | 4 | Consumes the shared packages, no manifest yet |
| non_conforming | 2 | Repo exists, no shared packages, no manifest |
| candidate | 3 | Named, not started |
| legacy | 2 | Superseded |
| conforming | 0 | Declares a version and meets the contract |
Eighteen entries. One in production. And the status the spec defines as the goal is held by nothing at all.
That last row is the one worth sitting with. conforming means a vertical declares its ecosystem version and meets the contract in full. Nothing does yet. Half the ledger sits at drift or migration_pending, which is to say: using the shared runtime in practice, not yet honest about it in writing.
Why we publish it that way
Because a count of verticals is a marketing number and a status ledger is an engineering one, and only the second can be wrong in a way that anyone notices.
"Sixteen verticals on a shared runtime" is a sentence that survives any amount of drift underneath it. "Zero conforming, four drifting" is a sentence that creates work. The ledger is hand-maintained and updated on each spec release precisely so it cannot quietly become the first kind of number, and the same reasoning is why the constitution-versus-runtime split keeps the spec repository free of executable code: a specification that ships runtime stops being checkable against anything.
What four weeks does and does not buy
It buys the removal of the repeatable part. A working multi-tenant product on infrastructure that other verticals have already debugged, with identity, billing and messaging inherited rather than discovered.
It does not buy customers, domain knowledge, correct pricing, or the point at which the thing pays for itself. Our own ledger is the proof: the infrastructure work is largely spread across eighteen entries, and exactly one is in production.
A vertical whose domain model is genuinely novel will also take longer, and no amount of inherited plumbing changes that. The four weeks is a claim about the floor, not the ceiling. The rent case study is the one where the number held, and the estate one shows what changes when the domain model diverges further from the template.
If you are doing this yourself
The transferable part is not our packages. It is the discipline of deciding, before the first vertical, which layer is allowed to have opinions.
Write down the entities every product in your family will share, and refuse to let any single product change them. Put the shared runtime behind a version. Keep a ledger of which products actually conform to it, and make the honest statuses uncomfortable to look at, because a ledger nobody winces at is a ledger nobody updates.
01If the method works, why is only one vertical in production?+
Because building a vertical and conforming to a spec are different jobs, and only the first one is urgent for anybody. A vertical reaches production when it serves users well enough to charge for; it reaches conforming when it declares an ecosystem version and meets the contract in full, which is work that pays off later rather than sooner. The registry is deliberately unflattering about this. Four of the eighteen sit at drift, meaning they consume the shared packages but have never published a manifest, and four more at migration_pending, meaning the repository exists and intends to conform but has a data-model gap. That distribution is what a spec-first programme actually looks like partway through, and publishing it as a status ledger rather than a marketing count is the only way the number stays useful internally.
02What is actually shared, and what has to be written each time?+
Shared: the five Ring 1 entities that define who a user is, what a company is and how the two relate, plus the capability packages for inbox, billing, incidents, notifications, i18n, security, storefront and knowledge, plus the three horizontal services for auth, billing and brain. None of that is rewritten. Written per vertical: the domain objects that make the product what it is, and the workflows over them. For a rental business that is the asset, the reservation and the dispatch; for a brokerage it is the property, the listing and the deal. The ratio is what makes four weeks possible, and it is also the honest limit of the claim, because a vertical whose domain model is genuinely novel will take longer no matter how much infrastructure it inherits.
03In what order should the capabilities be adopted?+
Identity first, always: auth and tenant, because every later decision depends on knowing who is asking and on whose behalf, and retrofitting tenancy into a product that assumed a single customer is the most expensive rework in this business. Then the request wrapper, so that error shape, logging and rate limits are uniform before there are many endpoints to make uniform. Then the capability that carries the product's main interaction, which is usually inbox for anything with conversations or storefront for anything with a catalogue. Billing comes later than founders expect, because pricing changes more often than identity does and building it early means building it twice. Security and i18n are last only in sequence, not in importance, and both are far cheaper to add on top of a clean tenancy model than to bolt onto a messy one.
04Does a four-week vertical mean a four-week business?+
No, and conflating the two is the most common mistake made with a number like this. Four weeks is the engineering time to stand up a working multi-tenant product on infrastructure that already exists and has been debugged by the verticals before it. It is not the time to find customers, learn the domain, get the pricing right or reach the point where the thing pays for itself. Our own ledger is the evidence: the infrastructure work is largely done across eighteen entries, and exactly one of them is in production. What the four weeks removes is the part that is genuinely repeatable, which frees the calendar for the part that is not. Anyone selling the second half as a four-week outcome is selling something else.
