The work

Nothing is published here yet

The engagements are written up. None of them is on this page, because two things have to be true before one goes up, and neither is settled: every number in it has been checked by the person who ran the engagement, and the client has given written permission to be named.

Both are pending client sign-off and owner review. Until they land, an empty page is the honest version. We would rather show you nothing than a figure that invites the question "measured how?" and has no answer, or a logo we do not have the right to print.

If you want the detail before it is public, ask on a call. We go as far as our agreements let us, which is usually further than a web page ever would.

What an engagement looks like

Five service lines, and the shape each one usually takes. Durations are per line and never global, because a retrieval build and a training block are not the same animal.

• AI products, built end to endSix to twelve weeks to a first production surface. Week one is scoping and a thin end-to-end slice. After that, weekly shippable increments against a fixed set of acceptance criteria.
• Knowledge bases and retrievalFour to eight weeks. It starts with your documents and your analysts writing the questions the system must answer. Most retrieval failures are ingestion failures, so the early weeks go into parsing and chunking.
• Codebase and team optimizationThree to six weeks, usually alongside the team's normal work. One high-value, low-risk wedge first, and test generation is the usual choice. Prove it, then widen.
• Training and enablementA block of sessions over two to four weeks, run hands-on against your codebase and your tickets. People ship real changes during the session.
• Forward-deployed engineeringOngoing, measured in deployments rather than features. Recurring patterns get pushed back into your platform so the next account gets a supported capability instead of another one-off.

How work is scoped and handed back

• scopeA call, then a written scope: what gets built, in what order, and what we are deliberately skipping.
• first sliceA thin end-to-end slice in week one, not a demo. If the product is agent-shaped, the agent gets real tools against real state from that first slice, because an agent that can only talk teaches you nothing.
• cadenceWeekly shippable increments against acceptance criteria that were fixed before the week started.
• handbackA running system with its own tests, its own eval suite, and documentation that lets your team take it over. The deliverable is checked into your repo, not into a slide deck.

What we do not take on

• outside the fiveWork that is none of the five lines above. Most engagements are one of them, sometimes two. If yours is not one of them, we say so in the first reply instead of stretching to fit it.
• a demoA proof of concept meant to impress a steering committee. We build the whole product: tools, data model, the interface people touch, and the eval harness that says when a change made it worse.
• work we keepAn engagement that leaves you renting a system nobody on staff understands. We ship, then we hand over the keys.
• a number we cannot defendA metric that invites the question "measured how?" and has no answer. That rule is what leaves this page empty rather than full of confident percentages.

Where to look in the meantime

• The five service linesWhat each line is, what a client gets, and what a typical engagement runs to.
• The stack we build onEvery tool we work with, and where each one is the wrong choice.
• Cities we work inEvery market we take clients in, worked remotely from one desk in Vancouver, BC.
• How the shop operatesThe crew, the operating principles, and where we are.