This guide is for a CTO, VP Engineering or founder who wants a fixed-price contract for an AI feature but is unsure how to scope work whose output quality is probabilistic, and for a procurement or legal reviewer turning an AI vendor's proposal into a statement of work with enforceable acceptance criteria. It assumes you have already weighed outsourcing itself and the general dedicated team vs fixed price choice, and are now scoping an AI-specific engagement through a dedicated development team or an offshore development center.
In this guide
- Why can't you just write acceptance tests for an AI project today?
- The three-zone scope split
- From spike to signed acceptance clause
- Where AI fits in fixed-price AI project scoping
- What delivery record exists, and what does not
- Alternatives: who writes the scope split and the acceptance clause
- Limits of this guide
- Frequently asked questions
- Next step
Why can't you just write acceptance tests for an AI project today?
A fixed-price contract for ordinary software rests on one assumption: the buyer and the supplier can agree today on what "done" looks like, and write a test for it. An AI feature breaks that assumption for the part of the system that depends on model behavior. A classification model, a retrieval pipeline or an agent does not produce the same output for the same input every time, and its real failure modes are usually unknown until it has been run against real data. Pricing the whole project as if it were deterministic either prices in a large risk buffer the buyer pays for whether or not it is needed, or produces a scope so narrow that passing it proves nothing about whether the feature actually works. The fix is not to abandon fixed price; it is to decide, deliverable by deliverable, which parts can be priced now and which parts need a short, separately priced discovery spike first.
The three-zone scope split
| Zone | What it covers | Pricing | Why |
|---|---|---|---|
| Zone 1: deterministic build | Data ingestion, APIs, the retrieval or serving pipeline, the UI around the model, logging and monitoring plumbing | Fixed price now | Behavior is specifiable and testable without seeing the model run on real data |
| Zone 2: model behavior and evaluation | Choosing and testing a model or prompt approach, building the evaluation set, setting the pass-rate threshold | Priced discovery spike first, then fixed price once the spike produces a baseline | Quality and failure modes cannot be specified honestly before a spike has run the candidate approach against representative cases |
| Zone 3: ongoing tuning | Prompt or model updates after launch in response to drift, new data or new failure cases found in production | Outside the fixed-price boundary: milestone-based, retainer or KPI-linked terms | Tuning is open-ended by nature; forcing it into a closed fixed-price scope creates the same dispute risk a fixed-price contract is meant to avoid |
A buyer who cannot yet produce 10-20 representative input-output examples for the feature is, by definition, still in Zone 2 and is not ready to fix a price for the whole project; that evidence gap is what the discovery spike exists to close.
From spike to signed acceptance clause
-
Run the spike before fixing the model-behavior price
A short, separately priced discovery spike builds a first version against real or realistic data and produces the evidence Zone 1 never can: whether the approach is viable at all, and what it actually gets wrong.
-
Turn the spike's failures into the evaluation set
The cases the spike got wrong, plus a sample of cases it got right, become the versioned evaluation set the final contract is tested against; a synthetic set the vendor invented is a weaker substitute when real or realistic data exists.
-
Set the pass-rate threshold to the risk, not to a round number
A customer-facing or compliance-sensitive feature needs a higher bar and human review of failures; an internal, low-stakes tool can accept a looser one. Write the threshold and the review step into the contract before the build phase starts, not after.
-
Name who owns the evaluation set and the scoring logic after the engagement ends
An evaluation set is reusable test infrastructure, not a throwaway artifact; the contract should state who keeps it and can re-run it later.
-
Fix the price for Zones 1 and 2 only once the spike and the evaluation set exist
Zone 3 stays outside the fixed-price boundary, on whichever of Netbase's other commercial models fits an open-ended tuning relationship.
-
Write the failed-case escalation path into the acceptance clause
State what happens when a milestone's pass rate falls short: a defined remediation window, a partial acceptance with named exceptions, or a renegotiation trigger, agreed before the milestone is tested, not during the dispute.
Where AI fits in fixed-price AI project scoping
Netbase works with the major commercial and open-source AI tools and models, chosen per project rather than standardized on one vendor's stack; this is also why an acceptance clause should name an evaluation set and a pass-rate threshold rather than a specific model's claimed accuracy, since the model behind a feature can change over its life.
-
In delivered work
Retrieval-augmented knowledge assistants, document AI and MLOps pipelines
These engagements used the same discovery-before-fixed-price pattern this guide describes, for clients that are not named; no count, duration or result is published for them.
What delivery record exists, and what does not
Netbase's own six-step delivery lifecycle names discovery and strategic alignment as its first step and team assembly and architecture planning as its second, run before agile execution starts, on every engagement regardless of whether the work includes an AI component; a discovery spike for an AI feature is this same first step applied to work whose quality cannot yet be specified without first testing it. Fixed-price is Netbase's primary commercial model, with milestone-based, monthly team retainer and KPI-linked terms also offered for scope that cannot be fixed up front, which is exactly the Zone 3 pattern this guide describes for ongoing model tuning. The anonymised retrieval-augmented, document AI and MLOps engagements referenced above ran under this same discovery-first, fixed-price-first practice.
What does not exist. No published Netbase record states an eval-set size, a pass-rate threshold, a spike duration or a price for any engagement; the scope-split and acceptance-clause method above is a framework, drawn in part from published AI-delivery practice outside Netbase, not a benchmarked Netbase outcome, and no figure is claimed for it as a Netbase result.
Alternatives: who writes the scope split and the acceptance clause
| Route | Strength | Choose it when |
|---|---|---|
| Your own technical team | Deepest knowledge of the product and the acceptable-risk bar for the feature | Someone in-house has already scoped a probabilistic system's acceptance criteria before |
| A vendor's standard fixed-price template | Fast to sign | The AI component is small and low-stakes enough that a generic deterministic-software template does not misprice the risk |
| A consulting delivery partner that runs the spike itself | The spike's output, the evaluation set and the final acceptance clause come from the same team that then builds the feature, so the evidence carries straight into the signed scope | You want the discovery work and the delivery work governed by one accountable party instead of a hand-off between a scoping consultant and a separate build vendor |
In Netbase custom development, the client owns the IP created for the work, and most projects run on fixed-price contracts agreed after discovery, with milestone-based, monthly team retainer and KPI-linked terms also offered where they fit the scope better. The offer sits in dedicated development teams and the offshore development center model, extended with the scope-split and acceptance-clause practice this guide describes; the AI knowledge assistant solution and professional services industry page cover an adjacent delivery shape.
Limits of this guide
- No price, eval-set size, pass-rate threshold or spike duration is published as a Netbase figure; the ranges and rationale cited below come from outside sources, not from a Netbase benchmark.
- The three-zone split is a starting framework; a complex engagement sometimes needs more than one spike, one per model-behavior component, rather than a single discovery phase for the whole project.
- This guide does not cover the separate questions of IP and data-handling clauses for an offshore AI engagement, which protecting IP when outsourcing and the general release readiness and acceptance checklist for non-AI deliverables already address.
Plan the next step with a Netbase consultant
Frequently asked questions
Only when every part of it falls in Zone 1: no new model behavior is being built or meaningfully changed, so there is nothing a spike would need to test; most new AI features include at least some Zone 2 work.
External guidance puts a practical floor around 50-150 cases drawn from real or realistic data for most business features, large enough to catch uneven failure patterns without making the spike itself a large project; a handful of hand-picked examples is rarely enough to set a trustworthy threshold.
The buyer, together with the scoring logic used to grade it, for the same reason the buyer owns the rest of the custom work it pays for: without it, every later change to the model or prompts has to be re-trusted on faith instead of re-tested.
The contract should say so before the milestone is tested: a defined remediation window, partial acceptance with named exceptions, or a renegotiation trigger, so the conversation at that point is about executing an agreed process, not negotiating one from scratch.
Next step
Tell us which part of your AI feature is still Zone 2 and we will book a solution review to scope the discovery spike and the acceptance clause together. You can also read how to hire an offshore AI engineering team in Vietnam to run that spike, or browse more Netbase insights.
Related services and solutions
An AI-augmented dedicated development team in Vietnam that answers for results
Netbase provides dedicated development teams from Vietnam for product companies and enterprises to add engineering capacity without losing control. Teams of 3 to 30 people work only on your product, use AI-assisted engineering under review, report to a named account manager and project manager, typically start within one to two weeks after discovery, and the IP they create is yours.
Learn More
AI knowledge assistant: answers from company knowledge, with sources and access control
An AI knowledge assistant is an internal tool that answers employees' questions from your company's own documents and systems, cites the source behind every answer and shows each person only what they may see. Netbase offers it as a growth capability, designed with retrieval, evaluation and human review from the first pilot, and has delivered one for an unnamed client.
Learn More
Work with Netbase remotely
Every Netbase engagement is delivered remotely, so clients in any country and any industry can work with us; Netbase has worked with clients in 80 countries. Contracts and invoices are issued by Netbase JSC, and payment is made by bank transfer to Netbase JSC's company account or PayPal Business. Talk to the CEO, Huy Nguyen (David), on WhatsApp or by email.
Discuss a project
Netbase JSC helps organizations design, build, modernize, and operate digital products and AI-enabled business systems.project@netbasejsc.com
+84 937 869 689
91 Nguyen Chi Thanh, Dong Da, Hanoi, Vietnam
Get in touch
Tell us what you want to build, modernize, or operate.