A six-week engagement, end to end.
We get the question often enough that it deserves a proper answer. Here is what a WireNet engagement looks like, week by week, from the first call to the first replay.
Week 1 — Listening.
A reasonable question: what does a WireNet engagement actually look like? Six weeks is the number we quote. Here’s what fits inside it.
Week one is listening. We sit with the people doing the work. We don’t bring an ontology. We bring a notebook. By the end of the week we have a candidate list of five to fifteen entities — and, crucially, the verbs you use against them. ‘Archive’, not ‘soft-delete’. ‘Approve’, not ‘set status to approved’. The vocabulary is the deliverable.
Weeks 2–3 — Spine design.
Weeks two and three are design. We cut a schema small enough to fit on one page. We specify queries (the reads the surfaces need) and commands (the writes, with their inverses or an explicit ‘irreversible’ stamp). Every command’s event-log row is part of its contract from day one. We write the contracts before we write the implementations.
Weeks 4–6 — Build and host.
Weeks four through six are build and host. Postgres for the spine, a typed operations layer in front of it, an MCP endpoint your existing surfaces point at. We migrate any in-scope state behind operations. We don’t let anything else reach past them. By the end of week six, your Codex desktop, your Claude Code session, your overnight pipeline — they all speak the same operations.
Then you operate forever.
Then the engagement ends, and the operating phase begins. New functionality is a new operation, not a new schema. New surfaces are new adapters, not new contracts. The first replay against last month’s events usually happens within a fortnight. That replay is what most teams point to when they say the spine started paying for itself.
Six weeks is the floor, not the ceiling. Larger spines take longer. Smaller domains sometimes finish in four. The shape, though, is the same: listen, design, ship, then operate forever.