A paid pilot before building is a limited commercial test in which a customer pays for a clearly described outcome while you investigate whether the delivery approach works. It should have a defined scope, authorised inputs, an evaluation method and an end decision, rather than an open-ended promise to build whatever the customer requests.
Payment is useful evidence that someone can make a purchase. It is not proof of repeat demand, profitable delivery or a standard product that other customers will buy. A pilot can become bespoke consulting unless you track what is repeatable and what depends on one account.
Start with an outcome you can responsibly deliver
Choose a job narrow enough to complete within your actual capacity. State what the customer receives, which parts are manual and which capabilities do not yet exist. Do not sell automation while quietly relying on labour the customer would consider material.
Strategyzer's customer-testing guidance distinguishes customer statements from actions. A paid test adds an observable action, but the meaning of that action still depends on what was purchased.
A customer may be paying for your expertise, access to your time or a one-off deliverable. That can support a business, but it is different from evidence that a self-serve product will retain subscribers.
Use a pilot decision sheet
Complete this sheet with the customer before starting. It is an operating worksheet, not a legal agreement or a substitute for professional advice about commercial terms.
| Section | Question to resolve |
|---|---|
| Outcome | What specific result will the customer receive? |
| Scope | Which tasks, records and time period are included? |
| Inputs | Who supplies data and authorises its use? |
| Owner | Who reviews the work and approves decisions? |
| Evaluation | What observation determines whether the pilot was useful? |
| Commercial basis | What is charged, when, and for which work? |
| Change handling | What happens when the request exceeds scope? |
| Ending | How can the pilot stop, and what happens to access and records? |
| Next decision | What will both parties decide at the review? |
Do not leave ending arrangements for the day someone is disappointed. Clarify cancellation, refunds or completed work where applicable through appropriate terms before accepting payment.
Establish data access before promising the result
Ask for the minimum information needed. A redacted sample can reveal whether the proposed delivery is technically and operationally plausible. Do not assume that an enthusiastic user has authority to share all company records.
Identify where outputs will be stored, who can review them and how mistakes will be corrected. If sensitive material would require expertise or safeguards you do not have, choose another test. A pilot label does not reduce the consequences of mishandling information.
Prepare a fallback for missing inputs. The delivery should become visibly blocked rather than silently substituting guesses for evidence.
A hypothetical catalogue-cleanup pilot
Imagine a founder offering a catalogue-completeness review to a specialist parts wholesaler. This example is hypothetical. The customer supplies an authorised export for one supplier range, and the founder returns a list of missing identifiers and inconsistent descriptions linked to the original rows.
The pilot excludes judging technical compatibility, safety certification and contacting external suppliers. The wholesaler's catalogue manager decides whether the review helps staff prepare listings. The founder explains that the first review is partly manual and records the time spent matching identifiers and resolving ambiguous product names.
At review, the manager may find that the list helps but incoming supplier formats are too inconsistent for efficient delivery. The next paid step might be a setup service. It should not be presented as evidence that recurring software already works.
Evaluate two ledgers
Maintain a customer-value ledger containing the outcome, corrections, use in the actual workflow and the customer's assessment. Maintain a delivery ledger containing preparation time, tool costs, review effort and support interruptions.
The first ledger prevents you from optimising a process nobody values. The second prevents a successful result from hiding an unsustainable service.
Kevin Hale's YC-hosted pricing discussion separates cost, price and value. Keep those concepts distinct when reviewing the pilot. A satisfied customer and positive revenue can still coexist with delivery costs that make expansion impractical.
Decide what happens after the review
Offer a continuation only when it has a clear scope and the customer actively agrees. Ask what the next project would require and whether the benefit persists without founder attention at every step.
A paid pilot is a poor fit when procurement takes longer than the learning warrants, the customer expects a finished product you do not have or the meaningful outcome cannot be evaluated within the agreed period. A free research session or a different segment may be more appropriate.
Stop or redesign when the result cannot be assessed, authorised access is unavailable or each new request becomes a separate product. The useful finish is a documented decision, including the possibility that there should be no continuing engagement.