Run a transparent paid pilot before building the full product

Sell a bounded outcome, not an imagined roadmap

A paid pilot tests whether a particular buyer will commit budget to a specific outcome under stated conditions. It can reveal more than a compliment or a waitlist signup, but it does not prove repeatable demand, retention, or scalable economics. A founder may deliver some steps manually during the pilot; that is useful only when the buyer knows which parts are manual and the result remains valuable.

Choose a narrow job with a clear start and finish: import one month of records, generate one report, or complete one onboarding workflow. Identify who will use it, who approves spending, what data is involved, and what would make the pilot unacceptable. If the workflow touches regulated, financial, health, employment, or sensitive personal information, get qualified advice and avoid using real data until access, security, and obligations are understood.

Write the offer before asking for money

Give the buyer a short written scope that covers:

• Outcome and exclusions: what the pilot will and will not do.
• Delivery method: current product state, manual services, dependencies, and customer responsibilities.
• Schedule: start, milestones, delivery date, and what happens if it slips.
• Price and payment: total amount, billing point, taxes or fees where applicable, and whether any amount is refundable.
• Acceptance: observable completion criteria and a way to report a problem.
• Data and access: data needed, permitted use, security handling, deletion/return, and who can access it.
• Exit: cancellation, refund, support window, and whether there is any obligation to continue.

Use clear-offer testing to check whether the buyer can explain these terms back. For business purchases, map the champion, budget owner, security review, procurement steps, and decision date with the B2B sales workflow. Do not call a research prototype “production ready,” describe a planned feature as available, or promise a date you cannot reasonably support. If you cannot define delivery, do not take money yet; ask for a non-binding interview or letter of intent instead.

Treat money and delivery as real obligations

Before selling, check the consumer, contract, tax, privacy, and payment rules for the seller’s and buyer’s locations and for the type of product. A U.S. FTC guide to the Mail, Internet, or Telephone Order Merchandise Rule explains shipment, delay-notice, and refund duties for covered merchandise orders. Its guide notes that services are outside that specific rule; it should not be generalized to software services or other jurisdictions. Contract and consumer obligations can still apply under other rules. Seek local professional advice when the pilot involves material sums, consumers, sensitive data, or uncertain delivery.

Keep a written record of what was promised and what was delivered. If a delay or scope change occurs, contact the buyer before the commitment is missed, explain options, and document the agreed change or cancellation. Never treat silence as acceptance when the terms or applicable rules require affirmative agreement.

Learn from delivery, not only the invoice

Track whether the buyer completed the intended workflow, time spent onboarding and supporting them, exceptions, manual labor, infrastructure and third-party cost, and whether the buyer would repeat or expand at the stated terms. Ask what would have prevented purchase and which result mattered enough to justify budget. Compare the actual delivery with the written success criteria.

After the pilot, decide: repeat with the same segment, revise scope or price, productize the manual step, or stop. Do not annualize one unusually supportive customer as if it represented a market. Use pricing guidance to form the next offer and measure product progress to define successful product behavior.