Delivery

Small pods, weekly proof, written scope

No account managers, no status decks, no discovery phase that produces a slide pack. You get the engineers who build it and a number to check the work against every week.

The cadence

The same shape on every engagement, whatever the arc.

  1. 01Day 1–2We sit with the people doing the work. Not a workshop — we watch the actual process, including the parts nobody documents.
  2. 02Week 1A written scope with the number we will close against, the assumptions it rests on, and what is explicitly not in it.
  3. 03Every weekA 30-minute review against that scope: what shipped, what slipped, what it cost. Same four questions every time.
  4. 04Every deliverableLands in your environment, not a demo of ours. You approve it where the contract clause and the thread already are.
  5. 05Go-liveWe train your people on the floor and hand over documentation they can follow without us.
  6. 06AfterMonitoring, evals and a named engineer. The thing we shipped keeps working, or we are the ones who find out first.

The pod

A pod is three to five people who stay with your engagement from scope to go-live. You get the same faces every week.

A lead engineer

Writes code on your project and answers your questions directly. This is the person you talk to, not a proxy for them.

A delivery lead

Owns the scope, the milestones and the cost position. Raises a change order before the work drifts, not after.

Applied AI and data

Where the arc needs it. Retrieval, evals and model routing are a specialism, not something the web engineer does on a Friday.

What we will not trade away

Engineering standards we hold regardless of budget, because they are cheaper than the alternative.

  • Tests before implementation. Every table ships with a policy test; every agent ships with evals. It is the standard, not the aspiration.
  • Your data is isolated at the database with deny-by-default policies, and that isolation is proved in tests rather than assumed.
  • No AI-generated commitment on price, scope or date. A person approves every one, enforced in the tooling.
  • You own the code and the infrastructure. There is no lock-in clause and no proprietary runtime you cannot leave.

What we need from you

Engagements rarely fail on the engineering. They fail because these three things did not happen, so we say them out loud before we start.

  1. One person who can decide

    Not a committee. Someone who can approve a deliverable and accept a change order inside a week. If approval takes three weeks, a six-week build takes four months and it is not the build that was slow.

  2. Access to the people doing the work

    A few hours with the person who actually runs the process we are automating. Their workarounds are the requirements; nobody else knows them.

  3. Honesty about the data

    Tell us the export is dirty, the spreadsheet has three versions and the legacy system has a field everyone uses for the wrong thing. We will find out in week two anyway, and finding out in week two costs more.

When something goes wrong

Because it does, eventually, on some engagement.

We tell you before you notice. A missed milestone appears in the weekly review with the revised date and the reason, not at the end. If we caused it, we absorb it; if the scope moved, it is a change order you see before the work happens. Incident handling, uptime and the escalation path are on the trust page as facts rather than promises.

Want to see it on your own work?

The first two days are the same whatever we end up building. Tell us what is slow and we will tell you whether it is worth the fortnight.

Scope it with us