What do you need from us, and when?

Roughly six to ten hours of your time across two weeks: API docs and access on day zero, sign-off on the tool manifest by day two, and a review of the acceptance run near the end. The three days that always slip are the ones waiting on your access, so the earlier that lands, the tighter the timeline holds.

What if we fail the acceptance script?

Then it is not done, and we keep working at no extra cost until it passes, because the script was agreed before we started. Acceptance is defined by the ten prompts you approved, not by our judgement, which is the whole point of writing them first.

What happens in the 30-day defect window?

Anything that was in scope and does not work gets fixed free. It is a warranty on the build, separate from the retainer. New requests are change orders; broken promises are defects, and we treat the line between them honestly.

Can you go faster than fourteen days?

Sometimes, for a small internal build, and we will quote the compressed timeline and its cost. We will not compress the manifest gate or the acceptance script, because those are what keep a fast build from becoming a slow rebuild.

Process

Fourteen days, and what happens on each of them

Two weeks from a signed tool manifest to a deployed server, gated four times: nothing is built before the manifest is signed, "done" is defined by a ten-prompt acceptance script, every diff is reviewed by the founder, and a 30-day defect window opens at handover. The clock is honest about the three days that are almost always waiting on your access.

Day by day

The fourteen-day build clock, D0 to D14
Day	What happens
D0	Kickoff, access, and the first draft of the manifest
D1–D2	Manifest finalised and signed
D3–D9	Build against the manifest and acceptance script
D10–D11	Automated checks, then founder diff review
D12–D13	Deploy, monitoring, and the acceptance run with you
D14	Handover; the 30-day defect window opens

The manifest gate

Nothing is built before the manifest is signed, because scope drift in integration work is a definition problem, not a discipline problem. The manifest names every tool: its inputs, outputs, access, data source and scope.

manifest.yaml

- name: orders.search
  access: read
  inputs: [query, limit]
  source: postgres:read_replica
  scope: store:read
- name: order.flag
  access: write
  dry_run: required
  destructive: false

The acceptance script

Ten prompts, written before the code, that the finished server must answer correctly against every client you support.

acceptance.txt

1. "Show me orders from yesterday" -> orders.search returns rows
2. "Flag order 5590 for review (dry run)" -> dry_run, no write
3. "What is the stock level for SKU-12?" -> inventory.levels
...ten total, each with an expected result

The QA gate

Two passes catch different things. The automated suite catches regressions and contract mismatches. The human diff review catches the ones a test would never think to write: a tool named ambiguously, an error message a model cannot act on, a scope wider than the manifest allows.

Handover

You receive the repository, the deployment, the monitoring configuration, the signed manifest and the acceptance results. If you took the retainer, we keep the last three current. If you did not, everything is yours to run.

Process questions

What do you need from us, and when?: Roughly six to ten hours of your time across two weeks: API docs and access on day zero, sign-off on the tool manifest by day two, and a review of the acceptance run near the end. The three days that always slip are the ones waiting on your access, so the earlier that lands, the tighter the timeline holds.
What if we fail the acceptance script?: Then it is not done, and we keep working at no extra cost until it passes, because the script was agreed before we started. Acceptance is defined by the ten prompts you approved, not by our judgement, which is the whole point of writing them first.
What happens in the 30-day defect window?: Anything that was in scope and does not work gets fixed free. It is a warranty on the build, separate from the retainer. New requests are change orders; broken promises are defects, and we treat the line between them honestly.
Can you go faster than fourteen days?: Sometimes, for a small internal build, and we will quote the compressed timeline and its cost. We will not compress the manifest gate or the acceptance script, because those are what keep a fast build from becoming a slow rebuild.

Twenty minutes is enough to sketch your tool list.

Book a 20-minute scoping call