Can we run a small pilot before committing to the full software project?

Yes. A pilot can be a standalone paid engagement with no automatic obligation to buy the full project. It should answer the riskiest decision question. Define representative samples, baseline, pass/stop/observe thresholds, deliverable assets, and expansion conditions first; otherwise it is merely a smaller project with the same uncertainty.

Pilot	Answers	Deliverables	Does not prove
Interactive prototype	Do users understand the workflow?	Journey, prototype, research, revisions	Performance, security, integrations, production stability
Technical proof of concept	Can the model, interface, device, or workload work?	Reproducible experiment, code sample, data and limitations	Adoption or full-system cost
Concierge/manual pilot	Do users value the result and can operations deliver it?	Service script, demand evidence, labor and exception record	Reliable automation at scale
Limited production MVP	Can one region, team, or cohort operate the complete loop?	Runnable product, monitoring, pilot data, transferable assets	Every region, peak, and workflow

When establishing communication, decisions, and change control, also compare Can we sign an NDA before discussing detailed software requirements?; the linked guidance adds context that should be considered in the same decision.

A prototype tests what to build, a PoC tests whether a technical proposition is feasible, and production MVP tests whether real operation works. Five people clicking a prototype do not prove load; laboratory accuracy does not prove willingness to pay. Prototype code should not enter production without appropriate redesign and acceptance.

The pilot charter states one primary hypothesis, target users, scenarios, baseline, sample, candidates, evaluation, pass/stop/observe gates, duration and budget, assets and rights, metric owner, and data return or deletion. Wavesteam derives sample and thresholds from task variety, error cost, and the intended decision; the client confirms business truth. A fixed sample number or percentage from another project is not a rule.

Evaluate the product and the supplier separately. Product evidence covers user outcome, technical performance, cost, risk, and operating burden. Supplier evidence covers requirement understanding, versions, tests, risk disclosure, response, and code/document quality. Good communication cannot rescue a product without value, and a good model result cannot excuse withheld assets.

At each review, provide accessible results, decisions, and remaining risk. The final demonstration uses client-selected authorized samples, not only supplier-curated successes. Contract the pilot separately, define whether output can enter production or be given to another team, and state third-party licenses, owner accounts, and full-project re-estimation.

There are four conclusions: expand within proven boundaries; run one more bounded test for a single gap; change route; or stop. Do not move the threshold after failure or sign the large contract because of sunk cost. Our cooperation guide describes paid demos and technical validation as available approaches; it does not promise that every pilot succeeds.