Scoping a Two-Week Paid AI Pilot as a Solo Builder

What you need to know

This guide starts one step after the hard part of winning work. Finding the buyer, choosing a niche and running an outbound motion are covered in our companion piece on landing your first AI consulting clients; what to charge per day and how to position yourself is covered in our guide to freelance AI engineer rates and positioning. Here the client has already said yes in principle. Everything that follows is about the gap between that yes and a signed, scoped, paid engagement — the gap where most solo builders lose money.

• A pilot answers exactly one question, yes or no. If you cannot write the question in a single sentence, you are not ready to price the work.
• Write the binary success criterion before the price and before the plan. It must cover quality and unit cost. A system that hits the accuracy bar at an unaffordable cost per task has failed.
• Build the evaluation harness before the solution. It is a deliverable in its own right, and it is frequently the most valuable thing the client keeps.
• The out-of-scope list and the dated access preconditions are the two clauses that save the engagement. Everything else in the document is administration.
• Price so that a "no" is still profitable. Your fee buys a decision, not a favourable decision.

What a pilot is actually for

A pilot exists to de-risk a decision. It is not a small product, it is not phase one of a build, and it is not a free sample with an invoice attached. Somebody inside the client organisation is trying to decide whether to commit real budget, real headcount and real political capital to an approach, and they do not have enough information to make that call. Your job for two weeks is to give them the missing information at a price far below the cost of guessing wrong.

That framing changes everything downstream. If the pilot's purpose is to answer a question, then the question is the centre of the document, not the technology. A well-formed pilot has four properties and only four: a defined problem, a fixed price, a working deliverable, and a clear path to expand. A proper proof of concept goes one step further — it has a defined scope and a binary success criterion, because it is a scoped technical answer to a specific question rather than an exploration of a space.

Here is the test. Write the question in one sentence, in the client's own language, and read it back to them. "Can a retrieval system route inbound support tickets to the correct queue accurately enough and cheaply enough that the triage team can stop doing it manually?" That is a question. "Explore how AI could improve our support operation" is a programme of work with no end condition, and if you price it as a pilot you will fund the difference out of your own weekends. If your one sentence needs an "and" in the middle that joins two genuinely different unknowns, you have two pilots, and you should say so and sell the more urgent one first.

There is a wider reason to be strict about this. Widely reported industry survey data on enterprise agent deployments makes uncomfortable reading: a large majority of agent pilots never reach production, and median time-to-value on agent deployments is reported at around five months. That is not an argument that clients are foolish. It is an argument that vague pilots produce vague results that nobody can act on, and that the pilots which convert are the ones designed backwards from the production decision. If you know on day one what "ship it" would require, you can design the two weeks to test the thing that would stop it — which is exactly what our guide on taking an agent pilot to production works through in detail.

Write the binary success criterion first

Before the price. Before the plan. Before you open an editor. The success criterion is the single sentence that determines whether the pilot passed, and it has to be answerable by running a script rather than by holding a meeting. If two reasonable people can look at the same output and disagree about whether the pilot succeeded, the criterion is not binary and you have built yourself an argument for week three.

Most clients will hand you an objective, not a criterion. Objectives are directional and unfalsifiable: improve support quality, make search better, reduce manual effort. Your first professional act is to convert the objective into something with a number, a dataset, an owner of the labels, and a threshold. The table below shows that conversion across four domains that come up constantly in independent work.

Domain	What the client says (vague objective)	What goes in the document (binary criterion)
Support routing	"Improve support quality"	On 200 held-out historical tickets, the system routes to the correct queue at or above 85% accuracy, measured against the client's own labels, at a cost at or below $0.004 per ticket
Document extraction	"Automate invoice processing"	On 300 frozen invoices spanning the client's five most common supplier formats, all six required fields are extracted with field-level accuracy at or above 97%, with a flagged-for-review rate at or below 12% and a cost at or below ₹1.50 per document
Internal search	"Make the knowledge base actually useful"	On 120 real queries drawn from search logs and answered by two internal reviewers, the correct source document appears in the top three results at or above 80% of the time, with p95 latency at or below 2.5 seconds and a cost at or below £0.01 per query
Sales-note summarisation	"Save the team time writing up calls"	On 100 held-out call transcripts, summaries score 4 or 5 on the client's own five-point rubric from two independent reviewers at or above 75% of the time, with zero fabricated commitments or figures in the sample, at a cost at or below £0.06 per call

Notice what every row on the right has in common. There is a fixed dataset with a size. There is a named owner of the ground truth, and it is the client, not you. There is a numeric threshold that was agreed before anyone saw a result. And there is a cost ceiling sitting alongside the quality bar.

Quality and unit cost are both part of the criterion

The most expensive failure mode in a two-week pilot is not missing the accuracy target. It is hitting the accuracy target with an architecture the client cannot afford to run. A pipeline that chains three model calls, a reranker and a self-critique pass will beat a single call on almost any quality metric, and it may cost fifteen times as much per task. If you present that as a pass and the client discovers the running cost in procurement, you have not de-risked their decision, you have moved the risk to a point where it is more embarrassing.

So put a unit-cost ceiling in the criterion and calculate it on day three, not day thirteen. The calculation is arithmetic, not modelling, and it takes twenty minutes. Our deeper treatments of LLM unit economics and cost per task go through the margin implications properly; for pilot purposes, the block below is the whole job.

WORKED COST-PER-TASK CHECK   (run this on day 3, not day 13)

  Tokens per ticket, measured from 50 real runs:
    retrieval + rerank context ......  1,200 input
    classification call .............  1,400 input /  120 output
    LLM-judge spot check (10% sample)    400 input /   60 output

  Model list price used (illustrative — confirm current pricing):
    input   $0.60 per 1M tokens
    output  $2.40 per 1M tokens

  Cost per ticket
    input  : (1,200 + 1,400 + 40) x 0.60 / 1,000,000  = $0.001584
    output : (120 + 6)            x 2.40 / 1,000,000  = $0.000302
    ------------------------------------------------------------
    total                                             ~ $0.0019

  At the client's stated 40,000 tickets/month:
    ~ $76/month   ~ £60   ~ ₹6,600

  Client's stated ceiling: $250/month
  VERDICT: PASS, with roughly 3x headroom for retries,
           volume growth and a future price change.

  If headroom is under 2x, say so in the report. A pilot that
  only passes at the current list price has not really passed.

Two disciplines make this number honest. First, measure tokens from real runs on the held-out set rather than estimating from a prompt you wrote. Second, include the things people forget: retries, the evaluation calls themselves if they will run in production, embedding refreshes, and the long tail of oversized inputs that blow the average. A full bill forecast is a separate exercise and belongs to phase two; for a two-week pilot, headroom of two to three times against a stated ceiling is the practical bar, and stating the headroom explicitly in the report is what stops the number being read as a promise.

The two-week shape

Two weeks is not an arbitrary number. Industry guidance converges on roughly two weeks for a working pilot, with two to four weeks of effort from a small senior team as the right cap. Beyond that the engagement stops being a pilot and starts being a project with a pilot's price attached. The shape below assumes ten working days and one person. It deliberately front-loads the evaluation harness and back-loads nothing that matters.

Days	What happens	What must exist by the end of it
1–2	Data and access. Get into the systems, pull the held-out set, agree and freeze it in writing, confirm the label owner and the rubric.	A frozen, hashed held-out set; working credentials; the criterion restated and countersigned
3–4	Evaluation harness first, then the smallest thing that could possibly work. One model, one data source, no cleverness.	A scoring script anyone can run; a baseline number, however bad; the day-three cost-per-task check
5–8	Iterate against the harness. Every change is measured. Kill anything that does not move the number, and log what you killed.	A run log with a numbered result per attempt; the best configuration and its cost profile
9–10	Hardening and handover artefacts. Freeze the code, write the result report, write the production-path note, record the walkthrough.	All deliverables in the client's hands; a clear PASS or FAIL against the criterion, with numbers

The harness deserves its own paragraph, because building it before the solution feels wrong to almost every engineer and is almost always right. Without it, days five to eight become vibes: you change a prompt, you look at four outputs, you decide it feels better, and by day nine you cannot tell anyone whether you improved anything. With it, every change produces a number and the report writes itself. It also happens to be the deliverable clients keep longest — long after your pipeline has been rewritten by their internal team, the frozen set and the scoring script are still what tells them whether the rewrite was an improvement. Our guide on building an LLM evaluation suite with golden sets and judges covers the construction properly; for a pilot, a golden set, a deterministic metric and a documented judge prompt are enough.

When access slips, and it will

Assume that at least one precondition will be late. Legal will not have signed the data-sharing addendum, the sandbox credentials will sit in someone's queue, the labelled tickets will turn out to live in a system the person you are talking to does not administer. This is normal, it is not malice, and it is entirely predictable — which is exactly why it belongs in the document rather than in an awkward phone call on day four.

The mechanism is simple. Every precondition gets a named date and a stated consequence. If a precondition is missed by more than a small agreed number of working days, the hard stop date moves out day for day. If it is missed by more than a larger agreed number, the engagement pauses and the balance falls due — because your calendar was reserved and the delay was not yours. Meanwhile, have a synthetic fallback ready: a small set of realistic examples you or the client can generate without production access, so days three and four are not dead. A pilot that spends its first week waiting is a pilot that will fail for reasons that have nothing to do with whether the idea was sound.

What goes in the document

The scope of work is not paperwork you produce after agreeing the deal. It is the deal. It should be short enough that a busy operations director reads all of it, specific enough that a sceptical finance approver can see exactly what they are buying, and blunt enough that the boundaries are impossible to misread. Two clauses do most of the protective work: the explicit out-of-scope list and the dated access preconditions. Everything else is good hygiene.

Below is a skeleton you can copy and fill in. Adapt the language to your own contracting practice and have someone qualified look at it before you use it commercially.

SCOPE OF WORK — AI PILOT
Client: [Legal entity]              Supplier: [Your legal entity]
Version: 1.0                        Date: [DD Mon YYYY]

1. THE QUESTION
   "Can [system] [do X] on [this data] well enough and cheaply
    enough for [named team] to adopt it?"
   One sentence. If it needs two, it is two pilots.

2. SUCCESS CRITERION (binary)
   On the frozen held-out set of [N] [items] supplied by the
   Client on or before [date], the system achieves:
     Quality   : >= [threshold] on [metric], scored against
                 [whose labels] using [rubric ref]
     Unit cost : <= [amount] per [unit] at [stated volume]
     Latency   : <= [N]s at p95            [optional]
   Measured by the harness in D2, runnable by either party,
   producing the same number.
   PASS = every threshold met.  FAIL = any threshold missed.

3. IN SCOPE
   - One use case: [name it]
   - One data source: [name it]
   - One model family: [name it]  (Supplier may substitute if
     the criterion and cost ceiling are unaffected)
   - Evaluation harness and result report

4. OUT OF SCOPE  (not included in this fee)
   - Production deployment, uptime commitments, on-call
   - Integration with any system not named in section 3
   - Any user interface beyond one internal review screen
   - Additional languages, regions, document classes or
     entity types
   - Data cleaning beyond [X] hours; migration of legacy records
   - End-user training, rollout or change management
   - Anything not written in section 3

5. CLIENT PRECONDITIONS (dated)
   P1. Read access to [system] granted by [date]
   P2. [N] labelled historical [items] delivered by [date]
   P3. Named decision-maker: [name, role, email]
   P4. Sandbox keys for [service] by [date]
   If any precondition slips by more than [3] working days the
   hard stop in section 8 moves out day for day. Past [10]
   working days the engagement pauses and the balance falls due.

6. DELIVERABLES
   D1. Working pilot system running in [environment]
   D2. Evaluation harness + frozen held-out set + scoring
       script (Client keeps this regardless of outcome)
   D3. Result report: PASS/FAIL against section 2, with numbers
   D4. Production-path note: what shipping would require, what
       running it would cost, what would break first
   D5. Repository handover + 60-minute recorded walkthrough

7. FEE AND PAYMENT
   Fixed fee: [amount], inclusive of all effort.
   [50]% on signature (engages the dates, non-refundable)
   [50]% on delivery of D1-D5, payable within [14] days
   The fee is NOT contingent on the criterion being met.
   Applicable taxes charged in addition, per invoice.

8. DATES
   Start: [date]        Hard stop: [date]
   The hard stop is a date, not a duration.

9. CHANGE CONTROL
   Any change to sections 2, 3 or 6 requires a written change
   request signed by the named decision-maker, priced separately,
   with its own effect on the hard stop date.
   New questions become new pilots.

10. IP, DATA AND CONFIDENTIALITY
    - Client data is processed only in [named environment], is
      not used to train any third-party model, and is deleted
      or returned by [date]
    - Client owns the deliverables; Supplier retains its
      pre-existing tools and generic know-how
    - The Client's own data-protection obligations apply to the
      data it supplies and are its responsibility
    - Publication: Supplier may describe this engagement as
      "[generic descriptor]" from [date], without naming the
      Client or disclosing figures, unless agreed otherwise
    Both parties to take their own legal advice on this section.

11. EXPANSION OPTION
    If the criterion is met, the Client may commission phase two
    at [indicative range], scoped separately, within [30] days.

Two notes on how to use it. First, the out-of-scope list should name the specific things this specific client has already hinted at wanting. Generic exclusions protect you legally; specific ones protect you conversationally, because they were read and agreed rather than skimmed. If in the first call somebody said "and eventually we'd want it in Hindi and Tamil too", that sentence belongs in section 4 verbatim. Second, resist the urge to soften section 5. Dated preconditions read as firm on the page and feel like relief in practice, because they give the client's own project manager something to escalate with internally.

Pricing it

Start with the honest market picture, then ignore most of it. As of September 2026, consultancy pricing guides commonly quote a scoped proof of concept on a single use case — one model, one data source, an evaluation harness — in the range of £15,000 to £40,000 as a fixed fee. In dollar terms, $20,000 to $50,000 is typical for an AI proof of concept or MVP with single-use-case delivery over four to eight weeks. Those are reported ranges from consultancy and agency pricing guides. They are not what a solo independent will be paid, and pretending otherwise will cost you the deal.

An agency's quoted band includes a brand, a contract vehicle procurement already trusts, professional indemnity cover, a bench, and the implicit promise that if the named engineer is hit by a bus, somebody else finishes the job. A solo builder sells none of that, and usually lands well below the band as a result. The ranges are still useful in two ways: they tell you the ceiling of what this category of work is worth to a buyer, and they stop you pricing at a number that signals you do not know what the work is.

Reason instead from effort and risk. Take your realistic days of effort — ten working days, plus one or two for the report and walkthrough. Multiply by the day rate you would accept for well-defined work in your speciality; the bands in our rates and positioning guide are the reference point. Then add a risk buffer of thirty to fifty per cent, because on a fixed price the unknowns are yours: the data will be worse than described, the access will be late, and something will need doing twice. Finally, sanity-check against a floor. If the fee is not worth two weeks of your calendar plus the opportunity cost of the work you turned down, do not take it at that price. Take it smaller, not cheaper.

Structure	When it fits	What it risks
Fixed price	Well-defined scope with a binary criterion — a document-processing automation, a migration off a legacy recommendation engine, a scoped assessment. The default for a pilot.	You absorb every unknown. Underestimate the data mess and your effective rate collapses. Needs a real change-control clause to survive.
Day rate	Genuinely open-ended discovery, or a client who cannot yet articulate the question. Also safer when the data is unseen and unsampled at signature.	Prices your time rather than the answer, so the client watches the clock rather than the outcome. Caps your upside for efficient work and invites micro-management.
Revenue share or outcome-linked	Rare at pilot stage. Occasionally sensible with a repeat client, on a measurable commercial metric, after you have already delivered something.	Gives you a financial stake in a favourable result, which compromises the measurement. Attribution is contested, payment is slow, and a first-time client has no track record to price against.

Fixed price wins for pilots because it prices the answer rather than your hours. The client is buying certainty about a decision, and a fixed fee makes the transaction match the value. It also aligns the incentives correctly: you are paid to reach a defensible conclusion quickly, not to occupy the calendar. Day rate is genuinely safer in one situation worth naming — when you have not seen a single row of the actual data before signing. If the client will not let you sample the data pre-contract, either price a one-day paid assessment first or bill the pilot by the day until the data is characterised.

Take a deposit. Fifty per cent on signature is standard and does two things: it engages the dates on both sides, and it filters out the buyer who was enthusiastic in the meeting and unfunded in reality. The balance falls due on delivery of the artefacts, not on the client's satisfaction with the answer, and the document should say so in those words.

Contracting across India and the UK

The commercial shape of the same pilot differs on either side of this market, and it is worth planning for before you quote. In the UK, most independents contract through a limited company, which affects how the client's procurement treats the engagement and what insurance or supplier onboarding they ask for. In India, independents work variously as sole proprietors, as an LLP, or through a private limited company, and the structure a client's finance team is comfortable paying often depends on whether the work crosses a border. Neither arrangement is inherently better; they carry different administrative burdens and different obligations, and the right answer depends on your circumstances. Get local advice from an accountant or a solicitor before you decide.

Two practical realities affect the pilot regardless of structure. First, cross-border invoicing takes longer than domestic invoicing — currency conversion, bank intermediaries and a purchase-order process that may not exist yet all add days or weeks. Assume the balance lands later than your terms say, and let the deposit rather than the balance fund the two weeks. Second, supplier onboarding at a larger client can take longer than the pilot itself; ask on the first call how a new supplier gets set up and start that process in parallel with the scoping conversation, not after signature. If you are weighing independent work against contract or fractional arrangements more broadly, our comparison of contract, permanent and fractional AI engineering across India and the UK sets out the trade-offs.

On data: agree in writing where the client's data will live, what it may be used for, how long you keep it and how it is destroyed or returned. The client's own data-protection obligations apply to the data it hands you, and those obligations are theirs to meet. Say that in the document and point both sides at their own counsel. This article is not legal or tax advice.

The clauses that stop scope creep

Scope creep in a pilot is rarely a land grab. It is a series of small, reasonable-sounding requests from people who do not know the shape of your fee: could it also handle the French invoices, could we see it on the mobile layout, could you take a quick look at why the old system is slow. Each one costs half a day. Four of them cost you the margin. The defence is structural, not personal, and it is four things.

1. A written change-request mechanism. Any change to the question, the scope list or the deliverables goes in writing, gets its own price, and moves the hard stop date. The point is not to say no; the point is to make the cost visible at the moment of asking. Most requests evaporate at that point, and the ones that survive are the ones worth doing.
2. One named decision-maker. A single person on the client side whose sign-off counts. Without this you get contradictory steers from three stakeholders and no way to resolve them. Name them in the document, in section 5, alongside the access dates.
3. A standing thirty-minute weekly checkpoint. Same slot, both weeks, with the decision-maker. Short, structured: the number so far, what changed, what is blocked, what is coming. It removes the ad-hoc "quick call" that eats an afternoon, and it means nobody is surprised on day ten.
4. New questions become new pilots. Say this sentence out loud in the kick-off and put it in the document. When somebody asks a genuinely interesting new question in week one — and they will — the answer is enthusiasm plus a separate scope: "That is a really good question, and it is a different one. Let me price it as a second pilot." That response protects the current engagement and sells the next one at the same time.

One more discipline that sits underneath all four: put a hard stop date in the document, not a duration. "Two weeks from kick-off" is elastic, because kick-off is elastic. A calendar date is not, and it makes the consequence of a late precondition arithmetic rather than negotiation.

Failing well

A pilot that returns "no" is a successful pilot if the client can act on the answer. This is the part most independents get wrong, usually because they are afraid the fee will feel unearned. It is not unearned: the client paid for a decision, and a well-evidenced no is a decision that has just saved them a great deal of money and several months. Treat it as a deliverable, not an apology.

This is precisely why your fee must not be contingent on the answer being yes. Contingency gives you a financial interest in a favourable result, and a measurement taken by someone with an interest in the outcome is not a measurement. Clients who understand evaluation know this. Say it plainly during scoping — "the fee is for the answer, whichever way it goes, because that is the only way the answer is worth anything" — and you will find it lands as a mark of seriousness rather than as a hedge.

The write-up is where a failed pilot earns the next engagement. A good one states the result against the criterion with the numbers, shows the best configuration you reached and what it cost, lists what you tried and discarded so nobody repeats it, and then does the genuinely valuable part: says what would have to be true for the answer to flip. Perhaps the labels were too inconsistent to learn from and a labelling exercise is the real first project. Perhaps accuracy was fine but only at four times the affordable cost, and the question becomes whether a smaller model with a narrower scope can close the gap. Both of those are scoped, sellable next engagements that the client now wants, and neither existed before you did the work.

Hand over the harness either way. The client keeps the frozen set and the scoring script, which means that when they revisit the question in six months — with better data, or a cheaper model — they can retest in an afternoon. Being the person who left them able to answer the question themselves is a considerably better position than being the person who left them with a demo.

Turning the pilot into a reference

A finished pilot is worth more than its fee if you can point at it afterwards, and worth exactly its fee if you cannot. Negotiate publication rights up front, in the scope document, while goodwill is high and nobody has anything to protect. Asking afterwards puts a legal team in the position of deciding whether to give something away for free, and the safe answer to that question is always no.

Ask for something modest and specific. Not the client's name, not their figures, not screenshots of their data — a generic descriptor and the shape of the work. "A two-week retrieval pilot for a mid-sized insurer's claims triage team" tells a future buyer everything they need and tells a competitor nothing. Pair it with the parts that are unambiguously yours: the harness design, the evaluation approach, the architecture reasoning, the cost method. Confidentiality and a credible public record are not in tension, provided you agree the boundary in advance and then describe the method rather than the customer.

The handover pack itself is the raw material. If you have written a result report with numbers, a production-path note and a recorded walkthrough, you already have the structure of a case study; what remains is stripping the identifying detail and rewriting it for a reader who was not in the room. Do that within a week of delivery, while the reasoning is fresh, and put the result somewhere a stranger can find it. A public profile that carries a handful of these — described honestly, anonymised properly, with the method visible and the client invisible — is what turns the next referral into a signed contract instead of a cautious conversation.

What goes wrong

The same handful of failures account for most pilots that turn into unpaid months. In rough order of frequency:

• The question was never one sentence. Everything downstream inherits the ambiguity, and there is no moment at which the work is finished.
• The success criterion was written after the results. At that point it is a negotiation, not a measurement, and the client is right to be sceptical.
• The harness came last. Days five to eight became impressions rather than numbers, and the report has adjectives where it needs figures.
• Cost was never measured. The pilot passed on quality, then died in procurement when somebody multiplied by monthly volume.
• Access slipped with no consequence attached. The two-week pilot became a five-week pilot at a two-week fee.
• No out-of-scope list. Four reasonable small requests removed the entire margin, and refusing the fifth made you look difficult.
• The deliverables were a demo. Nothing survived the engagement, so there was nothing to expand from and no reason to call you back.
• The fee was discounted for the logo. The rate anchored low, the scope did not, and the reference was worth less than the discount.

Every one of those is prevented by a document you can write in an afternoon. That is the whole argument of this guide: the difference between a two-week pilot and three months of unpaid drift is almost never technical. It is one sentence naming the question, one threshold that a script can check, one list of what you are not doing, and one date that does not move without a price attached.