Skip to content

How an engagement runs

Every engagement runs the same way, whatever we are building: phases with a defined end, artifacts you keep, and a decision gate at each boundary where you can stop.

What holds in every engagement

Engagements differ in what they produce. An eight-week readiness engagement and a build that runs for months are not the same piece of work. These four commitments apply to both, and you can hold us to them.

  • The team that recommends is the team that builds

    The engineers who assess your systems are the engineers who write the code. Nothing is handed to a delivery partner after the recommendation, which is also why our recommendations tend to be smaller than a consultancy would propose: we have to build them.

  • Every phase ends with something you own

    Every phase ends with a document, a dataset, a repository, or a running system, delivered in editable source and useful to you even if the engagement stops there.

  • Decisions belong to the agency

    We assess, draft, design, build, and operate. You decide, adopt, and approve. Nothing proceeds past a gate without your approval, and stopping is always one of the options.

  • Scope changes only through an approval gate

    Scope changes on nearly every project. We document changes when we find them, price them before they are built, and work them only after you approve them in writing.

The five phases

These are the names used in your proposal and in every status note that follows it. A phase has a defined end, it produces something you keep, and it closes at a gate where your agency decides whether the next one starts.

From your team
The people and the hours the phase needs from your agency. We publish it because an engagement that quietly consumes your staff time has a cost that never appears on the invoice.
You keep
What exists at the end of that phase, in editable source, and stays yours if the engagement goes no further.
Decision gate
The point where the work stops and waits. Nothing after the gate starts until your agency says it does.

  1. Phase 1. Understand

    We learn what you run and what is failing, from the people who work around it every day.

    From your team
    Introductions, system documentation, and about six hours of your team's time
    You keep
    Current-state assessment, with the costs and risks named
    Decision gate
    You confirm the findings before anything becomes a recommendation

  2. Phase 2. Decide

    We put options in front of you, each with what it costs, what it takes from your staff, and what it rules out.

    From your team
    Executive sponsor and budget owner, one working session
    You keep
    Costed options and a sequenced plan
    Decision gate
    You choose, including choosing to stop or to take the plan to another firm

  3. Phase 3. Build

    We build in your repository, with a working demonstration on a fixed schedule throughout the build.

    From your team
    A decision maker who can approve scope, and staff time for review
    You keep
    Working software, source, and documentation as it is produced
    Decision gate
    Demonstration against the acceptance criteria agreed before the build

  4. Phase 4. Adopt

    We train the people who will use it and the people who will maintain it, and we measure whether it is being used.

    From your team
    The staff who will live with it
    You keep
    Training, runbook, and measured adoption
    Decision gate
    Your team demonstrates they can run it without us

  5. Phase 5. Operate or hand over

    You self-host, self-host with support, or have us run it in your own cloud tenancy. All three are priced in advance.

    From your team
    A named technical contact
    You keep
    Transition plan, or an operating agreement with published response times
    Decision gate
    Moving between the options costs no exit fee, at any time

What happens when scope changes

Scope changes on nearly every project. We manage changes through a documented approval process, so your agency sees the cost of a change before any work happens.

A fixed price means little without a published process for scope changes, because scope changes on nearly every project and the process decides who pays for them. Ours is published below, step by step.

See engagements and pricing

  1. Step 1. The change is documented

    Anything outside the written scope is raised as a change request, in writing, as soon as we identify it.

  2. Step 2. The change is priced

    You receive the cost and the schedule impact in writing before any work on the change starts.

  3. Step 3. Your agency decides

    You can approve, defer, or decline the change. Declining does not affect the rest of the engagement.

  4. Step 4. No work proceeds without approval

    No change is built or billed without your written approval.

Our independence rules

We sell advice and we sell delivery, which is a conflict unless it is governed. These are the rules we hold ourselves to, published so you can hold us to them.

  • Our assessments are releasable to every bidder

    If you compete the build, the assessment and requirements we wrote are yours to publish to all bidders. No competitor is at an information disadvantage because you hired us first.

  • We do not bid on builds we specified

    Where we wrote the requirements or scored the vendors, we do not bid the resulting build. This can cost us the larger piece of work, and we accept that cost.

  • The free assessment obligates nothing

    It creates no obligation, no advantage in a later procurement, and no follow-up. Our pilot prices are published so any recommendation can be taken to another builder.

  • You can exclude our platform division at no consequence

    Where a project needs a service our platform division happens to offer, it is one option among others and always labelled as ours. Excluding it changes nothing about the engagement or its price.

  • Assessment data never crosses to the platform division

    What you tell us about your systems stays in the services engagement. It is never shared with the platform division, and it is never used to sell you anything.

These rules exist because of the shape of the engagement ladder: it starts with a free assessment and it can end with us building the system. Ask us about any of them before an agreement is signed.

Worked examples

The phases are easier to judge against a problem than in the abstract. These are written by us, to show how the method behaves on the ordinary problems a court has: the phone that will not stop, the policy that was adopted and then could not be operated. None of them describes an agency we have worked with, and we publish no named references until an agency has cleared one.

A municipal court with one clerk and a phone that will not stop

An illustrative scenario, not a client engagement.

A court of about 40,000 filings a year. Two thirds of the calls are the same four questions: when am I due, how much do I owe, can I pay online, do I have to come in.

How it runs
  1. Understand: two weeks. We listen to the calls with the clerks and count what the questions are.
  2. Decide: four pages rewritten in plain language, a payment link that works on a phone, and a self-help conversation for after hours. A full portal is not needed.
  3. Build: eight weeks, with the clerks reviewing every two weeks.
  4. Adopt: the clerks write the answers the assistant gives, because they are the ones who know them.
  5. Operate: the court self-hosts, with a support agreement for patches.
What gets measured
The measure agreed at the start is call volume on those four questions, reviewed at 90 days with the court doing its own counting.

An administrative office with an adopted AI policy and no way to operate it

An illustrative scenario, not a client engagement.

The policy was adopted on time. Six months later there is no approved-tool list, no way to vet the tool a court asks about, and no record of what is being used.

How it runs
  1. Understand: three weeks across a sample of courts, finding what is already in use.
  2. Decide: an approved-tool list, a vetting rubric a court can apply without central review, and a disclosure procedure.
  3. Build: the rubric and the register, plus role-based training material the courts can deliver themselves.
  4. Adopt: train the trainers in each region rather than the staff directly.
  5. Operate: the administrative office runs the register without us.
What gets measured
The measure is how many courts can answer, in writing, what AI tools they use and under what rule.

The safe first step

The readiness assessment is free, takes about 20 minutes, and returns a scored report you keep. It creates no obligation, no call, and no follow-up.

Start a conversationTake the readiness assessmentSee engagements and pricing