The whole product, or the part blocking it.

• A product that does not exist yet, where the hard part is not the interface and you want one team accountable for all of it.
• An existing product with a component that is blocking the rest, where the blocking part reaches below the application layer.
• A rebuild where the current system is understood well enough to say what must survive it.
• Internal or operational software a business genuinely runs on, rather than a proof of concept.
• A team that has the surface handled and needs the backend, the data model and the deployment path built properly underneath it.

A reference architecture, meaning the shape the work is designed to rather than a record of systems delivered. It names layers and responsibilities and never products: what runs at a given layer is a decision taken with you during scoping, not one taken here in advance.

• A written scope: the problem as understood, what will and will not be built, the stages, and the acceptance criteria for each.
• An architecture memo carrying the decisions, the alternatives considered, and the conditions that would make one worth revisiting.
• The interface and frontend application, built against real states rather than the happy path.
• Backend services and APIs, with the data model and the integrations behind them.
• A deployment path from commit to running service, with a rollback that has been exercised.
• A runbook and handover pack: how to operate it, how it fails, and what is deliberately manual.

• Agreeing a number before anyone has agreed what the work is, which is where fixed-price builds usually fail.
• A seam between vendors where the frontend blames the backend and the hard problem belongs to neither.
• Inheriting a system nobody can explain, where every future change starts with archaeology.
• A finished product that only functions while the people who built it are available.
• Discovering during an incident that the rollback path was theoretical.

• Design-only engagements. The interface is built here, but a visual comp with no system under it is somebody else's offer.
• A fixed price against a scope nobody has written yet. Scoping comes first, and it is real work.
• Staff augmentation by the hour with no defined outcome, where the engagement is a seat rather than a result.
• A deadline the scope cannot support. A date met by skipping the parts that make the system hold is not a date worth agreeing.
• Rebuilds where the existing system is not understood well enough to say what must survive it. That is discovery, and it gets scoped as discovery.

1. 01

   Source in your repositories

   The code lives in your organisation from the first commit, not in ours and copied over at the end. You own the code and the IP produced under the engagement, and that is stated in the engagement document rather than assumed.

2. 02

   Infrastructure in your accounts

   Everything runs in accounts you control, provisioned as code so an environment can be rebuilt from source rather than remembered. Revoking our access is something you can do without asking.

3. 03

   The reasoning, written as it happened

   The architecture memo, the decisions and the rejected alternatives, recorded while they were fresh rather than reconstructed at the end. This is the part usually lost, and it is the part that makes the next change cheap.

4. 04

   A runbook for the things that need operating

   Routine tasks, failure modes and their responses, where the logs are, what is deliberately manual, and the known limitations. Written for someone who was not there.

• BuildA multi-tenant content platformA product surface read as a problem class: an authoring model, and keeping the published output in agreement with it.
• DocumentsSample artifactsThe scope, the architecture memo, the runbook and the handover pack, shown as the formats you would receive.
• ProcessHow engagements runDiscovery, written scope, milestones, acceptance and handover, published before the first call.