When to Charge for a Startup Pilot

Charge for a pilot when a customer wants a business result, will use the work in a real workflow, and can agree to a bounded scope. A paid pilot does not need to be expensive. It needs a price, a decision-maker, a success measure, and an end date. If you cannot name those four things, keep the engagement as discovery or decline it.

Key takeaways

• A pilot is an experiment with a customer, not an open-ended promise to build whatever they ask for.
• Ask for payment when the customer expects usable work or a measurable result.
• Keep the scope small enough that you can deliver it manually and still learn what should become product.
• Treat a request that only works for one customer as a decision point, not an automatic roadmap item.

Start with the customer decision

Before discussing price, ask what the customer is deciding. Are they trying to see whether your product can reduce a specific delay, replace a manual step, or help a team reach a defined result? Or are they simply curious about an unfinished idea?

The first case can support a pilot. The second is usually a conversation, a prototype review, or a short research session. Charging for a pilot does not turn every prospect into a customer. It forces both sides to make the work concrete.

In a Stripe Atlas Q&A, Close cofounder Steli Efti argues that early enterprise pilots should be paid, including when the product is unfinished, because payment tests buying intent rather than polite interest. He also recommends keeping refundable pilot money separate until the customer is satisfied. Treat that as a practitioner recommendation, not an accounting rule; use terms that fit your business and get professional advice when the contract or revenue treatment is consequential. Stripe's Q&A with Steli Efti explains the reasoning.

Write a pilot that can end

Put the agreement in a short document or email before work starts. It should answer five questions:

1. Who is the customer owner with authority to continue or stop the pilot?
2. What single workflow or outcome are you testing?
3. What will you provide, and what will the customer provide?
4. What evidence will count as a useful result?
5. What happens on the end date: renew, expand, pause, or stop?

For example, a founder building scheduling software might offer a four-week pilot for one location. The customer supplies the current booking process and one operations contact. The pilot tests whether the team can cut the time spent confirming appointments. At the end, the two sides review the result and decide whether to continue on a paid plan.

That is very different from saying, "We will customize the product until it works for you." The first offer creates evidence. The second can become unpaid product management for one account.

Keep the first delivery manual on purpose

Early pilots often require work that will not scale: setup calls, hand-cleaned data, direct support, or a manual step behind the product. That can be useful when it helps you learn which part of the result customers value. Y Combinator advises founders to do direct, manual work for early customers while they are still learning what to build, rather than building a large process before that learning exists. YC's essential startup advice makes the same case for launching, talking to users, and iterating.

Make the manual part visible to yourself. After each pilot, record:

• the customer problem and the trigger that made it urgent;
• the work you did by hand;
• the part the customer used or mentioned most;
• the request that fell outside the agreed scope; and
• the reason the customer continued, paused, or said no.

Those notes tell you whether the pilot is teaching you a repeatable product or merely keeping one customer happy.

Do not let one pilot rewrite the product

A good customer can still ask for the wrong thing for your company. When a request appears, ask whether several similar customers have the same need, whether serving it changes your costs or business model, and whether it makes the core offer clearer.

YC partner Michael Seibel makes this distinction plainly: a customer need can point to a larger opportunity, or it can pull a startup into solving a one-off problem. His guidance on choosing customers recommends evaluating the size of the group, the economics, and the fit with the problem you chose to solve.

Use that test before agreeing to custom work. If the request is useful only to this account, offer it as a separately priced service if that business makes sense, or say no. If it repeats across the right customers, add it to the product hypothesis and test it again.

When a free pilot is reasonable

A free pilot can make sense when you are deliberately buying learning and the cost is capped. Keep it short and make the exchange explicit: access to a defined workflow, structured feedback, permission to study the results, and a scheduled decision at the end.

Do not call something a free pilot when the customer expects production support, custom features, or an indefinite rollout. That is a paid engagement with an uncomfortable price conversation delayed.

FAQ

How much should I charge for a first pilot?

Charge enough that the customer has to make a real decision and that you can afford the delivery work. The exact number depends on the value, scope, and buyer. Keep the offer simple: one price for one bounded result, with no extra tiers until you understand the pattern.

Should a pilot be refundable?

It can be, if that reduces the customer's risk and the terms are clear. Write down what counts as a refund, who decides, and when the decision happens. Do not spend the payment as if it were a completed contract before you know whether the customer will continue.

What if the customer asks for features before paying?

Ask which outcome the feature is meant to create. If a smaller manual workaround can test that outcome during the pilot, use it. If the request changes the product for one customer only, keep it out of the pilot unless you deliberately choose a custom-services business.

Wrap up

Write the smallest pilot offer you could send today: one customer, one workflow, one price, one success measure, and one end date. Use the customer response to decide what to build next. If you want help pressure-testing the scope, bring the offer to buildpurdue's cohort.