The first paid step

A six week supervised pilot, from $5,000.

The point of a pilot is a decision, not a deployment. Six weeks from now you will have one workflow measured against a baseline you agreed before anything was built, and a written recommendation to deploy it or stop. If the number does not justify going further, the report says so, and finding that out will have cost you $5,000 rather than a year.

Duration
Six weeks NorthCape commercial decision, confirmed by a founder 27 July 2026
Price
From $5,000
Scope
One workflow
You end with
A measured decision

What you get

Six things, all of them yours at the end.

Every one of these is written into the scope document before you are invoiced, so the pilot is something you can hold us to rather than something you have to trust us on.

01

A baseline definition document

One page that says what the workflow costs today in time, turnaround or spend, how that figure was captured, and who signed off on it. Written and agreed in week one, before anything is built.

02

An agent running against your real work

Not a demo on sample data. The agent runs inside the tools your team already uses, on live work, in a supervised mode where nothing leaves the building without a person approving it.

03

Access to the supervision console

Where your team sees what the agent proposed, what it acted on, what it escalated and why. Named users, full history, yours to look at whenever you like during the pilot.

04

A measurement report against the agreed baseline

The same metric, captured the same way, before and after. Including the exception rate, because the proportion the agent could not handle is as informative as the proportion it could.

05

A written deploy or stop recommendation

Our recommendation in writing, with the reasoning, the risks and the cost of the next step. Stop is a recommendation we will make when the measurement supports it, and the report says why.

06

The code and configuration, handed over

Regardless of the decision. Repository, infrastructure definitions, prompts and integration configuration transfer to you at the end of week six whether you deploy with us, deploy without us, or stop.

The shape of it

Six weeks, and you know which weeks do what.

Six weeks end to end NorthCape commercial decision, confirmed by a founder 27 July 2026

Short enough that the answer arrives while the problem is still the one you care about, long enough that the agent runs on real work rather than a rehearsal.

  1. Week 1

    Baseline

    We sit with the people who do the work, watch the workflow run, and agree in writing what today costs and how it will be measured.

  2. Weeks 2 and 3

    Build

    The agent is built against your real data in your environment, with the approval gates set where your team says they belong.

  3. Week 4

    Supervised run

    The agent handles live work with a person approving every action. Every decision is logged, and the exceptions are the interesting part.

  4. Week 5

    Measure

    The same metric, captured the same way as the baseline. No new definition, no reframing, no comparison against a number nobody recorded.

  5. Week 6

    Report and decision

    You get the measurement report, the recommendation and the handover. Then you decide, with a number in front of you.

What is included and what is not

The second list is the important one.

A fixed price only means something if the boundary is written down. Here is ours, in the same words it appears in the scope document.

Included

  • One workflow, chosen together in the scoping call and named in the scope document
  • One integration set: the systems that workflow already touches
  • The supervised run on live work, with approval gates your team controls
  • Measurement against the agreed baseline, including the exception rate
  • The written report and the deploy or stop recommendation
  • Handover of the code and configuration at the end, either way

Not included

  • Additional workflows. A second workflow is a second pilot, priced separately.
  • Third-party licence costs. Any software you do not already hold is billed to you at cost.
  • Changes to your own systems. If a system needs work before it can be integrated, that is your team's or your vendor's, and we will say so before we start.
  • Production scale-out. Running the agent across the whole team is deployment, quoted after the pilot.
  • Ongoing support and optimisation. The pilot ends at the decision, not at an open-ended retainer.

How the baseline is agreed

The number is settled in week one, when neither of us knows the answer.

Week one is spent with the people who do the work, not with a stakeholder describing it. We watch the workflow run, count what it actually costs in time or turnaround or spend, and find out where the existing number already lives. Most teams are already tracking something usable, and a metric your business recorded before we arrived is worth more than a cleaner one we introduce.

Then we write it down: the metric, its definition, how it is captured, the period it covers and what would count as a good enough improvement to justify deployment. You sign that document before we build anything. Agreeing the target while both sides are still ignorant of the result is the entire mechanism, because after the fact everyone has a stake in where the line sits.

In week five the same metric is captured the same way, from the same source, over a comparable period. No new definition, no reframing, no comparison against a number nobody recorded. If the measurement turns out to be harder than week one assumed, we say that in the report rather than quietly substituting an easier one. That is why the case studies page publishes the method beside every result.

The decision criteria

One question, answered in writing in week six.

Did the agent move the agreed baseline metric far enough, at an exception rate your team can live with, to justify what it costs to deploy across the whole workflow?

The report answers that with three numbers and one recommendation: the baseline, the measured result, the proportion of work the agent could not handle without a person, and then deploy or stop. There is no fourth option where the answer is unclear and the engagement continues while we work it out.

  • Deploy when the measured movement clears the threshold you set in week one and the exception rate is one your team can absorb.
  • Stop when it does not, or when the exceptions turn out to be where the real work was. Recommending against a deployment is a normal outcome of this engagement, not an embarrassing one.
  • Either way you keep the baseline document, the measurement, the code and the configuration.

If the answer is deploy

The next step is quoted from what these six weeks find.

Deployment is a separate quote and never automatic. We do not publish a range for it, because the volume, the integrations and the exception rate that set the price are the things the pilot is measuring. The week six report gives you a costed recommendation for your workflow, against the baseline you agreed in week one.

Deployment project

Rolling the agent out across the whole workflow, with the integrations, the supervision model and the measurement running in production.

Ongoing optimisation

Optional. Monitoring the exception rate, tuning the agent as the work changes, and reporting against the same metric the pilot established.

What moves the price

Five things, and none of them are how big your company is.

How many workflows
One workflow is a pilot. Four related workflows sharing an integration cost less than four separate ones, and four unrelated ones cost more than four times one.
How many systems it has to reach
A workflow living entirely in one system is the cheap case. Every additional integration adds build time, and a system with no usable API adds considerably more.
Which deployment option
Running on infrastructure we operate is the least work. Your own cloud tenancy is more. Fully self-hosted on your hardware is the most, and is sometimes the only option that satisfies a data residency obligation.
How complex the approvals are
A single approval gate is straightforward. Conditional routing, delegated authority limits and multi-party sign-off are each real build work, and they are usually non-negotiable, so they are scoped rather than argued about.
Volume and how variable it is
Steady volume is easy to size. Volume that multiplies at end of month or end of financial year has to be built for the peak, not the average.

Security and trust sets out the deployment options each of these assumes.

Common questions

The six questions people ask before they sign.

Why is there no full price list?

Because the work is shaped per client, and a fixed tier would either overcharge the simple cases or lose money on the hard ones. The pilot has a real from-price because it has a real fixed scope. Beyond that we publish the variables that move a quote rather than a bracket we cannot stand behind.

Do you charge for the models and infrastructure?

They are passed through at cost where they are yours, and included where the agent runs on infrastructure we operate. Which of those applies is a deployment decision made with you during design, and it is stated in the scope before anything is built.

What if the pilot does not work?

Then the week six report says so, and we recommend stopping. That is a real outcome of this engagement, not a failure of it. You still keep the baseline document, the measurement, the code and a specific, evidenced answer to a question you would otherwise have argued about for a year. Finding out in six weeks for a fixed fee is the cheapest version of that answer available.

Who owns the code?

You do, at the end of week six, regardless of the decision. Repository, infrastructure definitions, prompts and integration configuration all transfer to you. There is no licence to keep paying to run what you already paid to have built, and nothing is held back to make leaving expensive.

What happens to our data?

It stays in Australia. The agent runs in your environment or in an Australian hosted environment we set up for you, inference runs on AWS Bedrock in Sydney, and nothing is used to train a model. Documents processed during the pilot do not leave the boundary agreed in week one. The security and trust page sets out the deployment options in full.

Can we stop part way through?

Yes. The pilot is invoiced in two parts, at the start and after the week four supervised run, so stopping after week three costs you the first invoice and nothing more. You keep everything produced up to that point. We would rather you stop early than sit through three weeks you have already decided against.

What does deployment cost after the pilot?

It is quoted separately and it is never automatic. We do not publish a range, because the volume, the integrations and the exception rate that set the price are exactly what these six weeks measure. The week six report gives you a costed recommendation for your workflow, against the baseline you agreed in week one. If the measured result does not justify the cost, the report says that instead.

Do you need access to our production systems?

Not in week one, and not always at all. The baseline work needs read access to whatever already records the metric. The build usually needs a sandbox or a test tenant. Production access, where it is needed, is scoped in writing, granted to named people, time limited and logged. If your policy is that no vendor touches production, the pilot is built to work inside that constraint.

Start here

Pick the workflow, agree the number, run it for six weeks.

Thirty minutes with Liam or Nick to find the work with the clearest return and agree what the baseline should be. If a pilot would not pay for itself, we will say so on the call rather than sell you one.

Prefer to read first? The sample scope is the document you would be signing.