A pilot is the moment a product stops being a demo and starts living inside somebody else's operation, on their floor, with their people, under their rules. It is the most informative thing that can happen to a young hardware product and one of the most dangerous, because a pilot that is not structured properly can run for a year, consume your entire engineering capacity, and end with a polite email saying the champion has moved to another role. Every hardware company has a story like that. The fix is unglamorous: put the terms in writing before the equipment goes through the door.
What a pilot is for
Both parties should be able to state the purpose in a sentence, and the sentences differ. Yours: prove the product performs in real conditions, learn what breaks, and convert this customer into a paying account with a reference. Theirs: find out whether this reduces a cost or a risk enough to justify a budget line, without committing to anything.
Those goals are compatible only if both are written down. When the purpose stays vague, the pilot becomes an indefinite free trial where the customer gets value and you get expenses — the extended demo a pilot often degrades into, covered from the sales side in closing your first pilot with a business customer.
Success criteria, agreed in writing
This is the single clause that decides whether a pilot ends. Without it, "success" is whatever the customer feels in the final meeting, and feelings are not a purchase order.
Good criteria are measurable with an instrument or a count, carry a threshold number and a measurement window, and were agreed with the customer before the pilot started. Examples of the shape:
- Unit operates unattended for 60 consecutive days with no more than two service interventions.
- Detection accuracy of at least 95 percent against the customer's existing manual inspection over 500 sampled parts.
- Setup by a trained operator in under 15 minutes, demonstrated by three different operators.
- Measured reduction of at least 20 percent in the target process time, averaged across the pilot period.
Include the counterpart too: what happens if the criteria are met. "If the criteria are satisfied, customer will issue a purchase order for at least X units within 30 days, or the parties will document why not." Even a soft commitment forces the conversation about budget authority to happen at the start, when it is still cheap to discover that your champion cannot actually buy anything.
Who owns the data and anything invented along the way
A pilot generates two valuable things beyond the product itself: operational data from the customer's process, and improvements to your product prompted by their environment. Both need owners named in the agreement.
On data, the workable structure is usually: the customer owns their raw operational data; you may use aggregated or de-identified data to improve the product; and neither side publishes anything identifying the other without written consent. Large customers run their own security review and may require that data never leave their network, which can force a real architecture change — find that out in week one. If the data covers individuals, privacy compliance for connected product data applies from the first day of the pilot, not from launch.
On IP, the default should be that you own your product and everything you develop in it, including changes inspired by the pilot. Customers occasionally propose joint ownership of anything created during the engagement, which sounds collegial and is a trap: jointly owned IP is hard to license, hard to sell, and complicates every future fundraise. If the customer is genuinely contributing invention, handle it as a defined deliverable with its own terms, following the reasoning in who owns the IP when a company develops your product.
Charge for it
Free pilots are worth exactly what the customer paid. A paid pilot changes the internal dynamics on the customer's side: someone had to justify the spend, which means someone with budget authority now has a stake in the outcome and will chase their own people to make it work.
Common structures:
| Model | Typical shape | Best when |
|---|---|---|
| Paid pilot fee | Fixed fee covering hardware, install, and support for a set period | Standard case; simplest to explain |
| Credited pilot | Fee applies against the first purchase order if they convert | Customer resists paying twice; keeps commitment intact |
| Equipment sale plus support | They buy the units outright at pilot pricing | Customer procurement cannot process a "pilot" |
| Cost-shared | They cover install, integration, and their own labor | Early product where you need the learning more than the revenue |
| Free | Only with a signed conversion commitment and a hard end date | Marquee logo you genuinely need as a reference |
Whatever the model, price it so the pilot covers your direct costs. A portfolio of free pilots is a straightforward way to run out of money while looking busy.
Install, training, and the human side
The pilot succeeds or fails on the floor, with the people who have to use it during a shift they are already busy with. Plan for that explicitly.
- Site survey before install. Power, network, mounting, ambient conditions, clearances. Most pilot delays are logistical, not technical.
- Name the operators. Train the people who will actually touch the product. A champion in an office cannot substitute for the technician on the line.
- Leave documentation behind. A one-page quick reference beats a manual nobody opens. If surviving a shift needs a fifty-page guide, that is a design finding.
- Define support response. Coverage hours, response time, who to contact, what counts as an emergency — in writing, so "the pilot is broken" at 11pm Saturday has an agreed answer.
- Schedule the check-ins, including a mid-pilot review at the halfway mark, where you catch a pilot that is quietly failing while there is still time to fix it.
Also decide what happens to the hardware at the end. If they do not convert, who removes it and ships it back? Equipment left in place indefinitely is how a pilot never formally ends.
Pilot purgatory, and how to avoid it
The characteristic failure mode is not rejection. It is a pilot that never concludes: no written criteria, an enthusiastic champion with no budget, procurement never involved, scope growing with "could it also do this," and a reason to extend every quarter. Meanwhile you support production equipment for free and cannot cite them as a customer.
Four defenses, all set up at the start:
- An end date in the agreement with a defined decision meeting, not an open-ended trial.
- A named economic buyer who is in the kickoff meeting. If nobody with budget will attend, you are running a science project for a curious employee.
- A change process. New requests are documented, priced, and either scheduled after the pilot or added with a revised timeline. Silent scope creep is how three months becomes eighteen.
- A written exit. What each side does if the criteria are not met, including removal, data deletion, and return of anything confidential.
What you should get out of it besides an order
Even a pilot that ends in "no" pays for itself if you extract the engineering value. Instrument the product, log every service call and operator complaint, and note every feature nobody touched and every workaround people invented. That evidence feeds the next design revision, the formal acceptance testing and handover criteria for the commercial release, and the service and support plan you need before deploying at scale. Across several sites at once, the practices in beta testing a hardware product apply too.
Projects House helps companies get products to the state where a customer pilot is worth running — reliable enough to leave on site, instrumented enough to learn from, and documented enough for someone else's technician to operate. If you have a pilot coming and want the product ready for it, tell us about it through the contact form.