Matter SettleAI engineering studio

The paid pilot

The paid pilot

A pilot is the first small piece of real work, with one clear deliverable. Fixed price, fixed scope, agreed in writing before anything starts. You judge the work in your own repository before you decide on anything bigger.

Start a conversation See a sample pilot scope

01 / What it is

A real deliverable, not a demo

A pilot builds one thing you can run: a pipeline, a service, a simulator or an evaluated LLM feature. It is small enough to finish and real enough to keep.

It is not a free trial, a slide deck or a proof of concept that ends up in a drawer. If the problem cannot be solved well, the pilot should show that early, and that is a useful result too.

Price and length depend on the problem, so both are set in the written scope. You know the price before you commit.

02 / In the written scope

What the scope says before work starts

The sample below shows each of these lines filled in for an invented buyer.

  1. The deliverable

    One thing that will exist at the end, described so both sides picture the same thing.

  2. What “done” means

    Checks that anyone can run at the end to see whether the deliverable works.

  3. What is out of scope

    The nearby work this pilot will not do, so nobody is surprised.

  4. What you provide

    Access, data and the time of one person who knows the problem.

  5. Price and length

    A fixed price and a fixed length, written down before anything starts.

  6. If something proves impossible

    What happens, who is told, and how the scope may change: only in writing.

03 / Step by step

The four steps of a pilot

  1. Step 01

    Scope it

    The deliverable, the checks for “done”, the price and the length, written down and agreed.

  2. Step 02

    Build it

    Each week ends with a version you can run in your own accounts. You talk to the engineer doing the work.

  3. Step 03

    Check it

    At the end, the “done” checks are run, and you see which pass.

  4. Step 04

    Decide

    Stop and keep everything the pilot produced, or scope the next piece of work the same way.

04 / Sample pilot scope

A sample pilot scope, with a note on every line

Example only: invented buyer, invented numbers. No real company, project, client or price is described here.

Pilot scope (example) Nightly supplier-feed pipeline for an invented online shop

  1. S1 / Buyer

    An invented online shop that sells household goods. Called “the buyer” below.

    Note

    A real scope names both parties. This one names nobody, on purpose.

  2. S2 / Problem

    Stock and price data arrive every night from three supplier feeds. One feed fails about twice a week, and a person repairs the import by hand the next morning.

    Note

    The problem is written in the buyer's words, with the cost it causes today. That is what the deliverable has to fix.

  3. S3 / Deliverable

    One pipeline that fetches all three feeds every night, checks each batch, writes clean tables to the buyer's database, and sends an alert when a check fails.

    Note

    One deliverable. Not a platform, not a model, not a dashboard.

  4. S4 / Done means
    • A failed fetch resumes from its checkpoint without downloading finished files again.
    • A batch with missing columns or negative stock counts is stopped, and the alert names the feed, the rows and the rule.
    • Running the same night twice gives the same tables.
    • The buyer's engineer can run the whole pipeline with one documented command.
    Note

    Each check can be run by someone who did not build the pipeline. “Works well” is not a check.

  5. S5 / Out of scope

    Sales forecasts, dashboards, and any change to the supplier feeds themselves.

    Note

    Saying what is left out stops the scope from growing quietly.

  6. S6 / Buyer provides

    Read access to the three feeds and a week of sample files; a database account; one person who knows what correct stock data looks like, for a 30-minute call each week.

    Note

    Without the right access, a pilot stalls. Listing it up front makes the first week useful.

  7. S7 / Weekly

    Each week, the buyer can run the current version in its own account.

    Note

    The buyer sees real progress, and can stop if it is not there.

  8. S8 / Code and accounts

    All code in the buyer's repository from the first commit, running in the buyer's cloud account.

    Note

    Nothing to hand over at the end, because nothing was ever held back.

  9. S9 / Price

    A fixed amount, stated here in a real scope.

    Note

    This example leaves the price out on purpose. It depends on the problem, and it is set in writing before anything starts.

  10. S10 / Length

    A fixed end date, stated here in a real scope.

    Note

    Left out for the same reason as the price.

  11. S11 / If something proves impossible

    If a feed's terms do not allow automated fetching, work on that feed stops and the buyer is told in writing. The scope changes only if both sides agree in writing.

    Note

    Problems are named when they are found, not at the end.

  12. S12 / After the pilot

    The buyer keeps the code, the tests and the runbook, and may stop with nothing more owed.

    Note

    Walking away has to be a real option, or the pilot is only a sales step.

Next

Want a scope like this for your problem?

Tell us what you are building in two or three sentences. If it fits, a short call comes next, then a written scope.

Start a conversation

Read next