Will someone pay for your vibe-coded SaaS? Run a bounded paid pilot

Test whether someone will pay for one clearly defined result, then check whether you can deliver it with support you can sustain. A small paid pilot can answer that question more directly than asking people whether they approve of AI-written code. It cannot establish that the software is secure, reliable at scale or ready for a subscription business.

For a low-risk web SaaS, start with a handful of customers, a one-time price, an explicit end date and a way to leave with their work. The pilot below is an original hypothetical procedure, not a claim about observed buyer behavior. If you still need suitable participants, first find people with a real upcoming task.

Make the offer small enough to inspect

Suppose you built a tool that turns a freelance designer’s scattered project tasks into a client handoff checklist. Your first paid offer could be:

For $30 once, I’ll help you turn one project’s task list into a checklist you can edit and export as CSV within seven days. It supports plain-text tasks and due dates. There is no automatic renewal. You keep your original list. If we cannot produce the agreed usable export by the deadline, I will refund the pilot fee. I answer support requests within one business day during the pilot.

Only make promises you can honor. Agree what “usable” means before payment: all supplied tasks present, due dates preserved, and a CSV the customer can open in their usual spreadsheet. Do not quietly change the outcome after discovering a limitation. Use a test project first, and ask customers to omit client secrets and personal data you do not need. Explain where their inputs go, how long you retain them and any manual access you need to help.

This is a paid service-assisted trial of a product. Say so. If you manually repair an export, the customer may still receive value, but the result does not prove independent software delivery.

Rehearse the awkward path before collecting money

An AI assistant saying the code looks good is insufficient evidence. GitHub documents that Copilot review can miss problems, raise false positives and suggest insecure code; its guidance calls for human review and testing. That is a limit of the review tool, not evidence that any particular app is defective. GitHub’s Copilot limitations and review guidance

Run a small rehearsal against your own test environment with invented task data:

These checks are examples for this product, not a complete security assessment. Get qualified review of authentication, permissions and data handling before taking real customer data. A tiny pilot does not make a known cross-account access bug acceptable. Do not promise immediate deletion from every backup unless that is how the system works.

At the point where your recovery promise is unclear, review the failure path with Josh Mohrer’s AI mentor ↗. Bring the supported task, an anonymized failure and the help you can realistically provide. The AI conversation helps structure the decision; it does not certify the implementation.

Keep payment separate from delivery

You can collect a fixed pilot payment with a hosted payment link without building a complete subscription system. Stripe documents Payment Links for one-time products as well as subscriptions. Configure the intended one-time offer and verify the actual payment before starting the paid work. Stripe Payment Links If you later generate a checkout per order in your own backend, rehearse a lost session-creation response and duplicate delivery attempts before you let buyers retry.

Write down the refund condition and how the customer requests it. Rehearse the refund flow in the provider’s test environment. In a real case, record whether the refund succeeded, remains pending or failed; initiating it is not proof the customer received the money. Stripe describes those states and notes that refunds go back to the original payment method. Stripe refund behavior

Keep a minimal ledger with participant IDs, the agreed result, payment status, output accepted, minutes of help, refund status and the next task date. Keep private project contents out of it. Ask the customer whether the export was usable when your software cannot observe that outcome.

Read five paid pilots without turning them into a forecast

Here is an invented batch after each seven-day delivery deadline. All five customers paid $30. Setup and administration took two hours in addition to the help below. For this example, brief orientation counts as help; a manual repair or completion of the customer’s output counts as a rescue.

The ledger says five purchases, four delivered results and three results without a rescue. Of the three successful customers whose next comparable task has arrived, one bought again. C is not yet eligible for that comparison. Five selected customers are far too few to estimate a dependable market conversion or retention rate.

For the five initial pilots only, the cash calculation is 5 × $30 − $30 = $120 after the refund, before payment fees, tax and infrastructure. Their help totals 240 minutes. Add 120 minutes of setup and administration: 360 minutes, or six hours. At an illustrative $25 per hour for your own time, that work costs $150. The initial batch is already $30 short of covering that time, before the other costs. A’s later order and its delivery costs belong in a separate batch. This may be worthwhile learning; it is not proof of profitable delivery.

A payment tests the offer. The accepted export tests delivery. A later purchase tests a narrower form of repeat demand. The second-real-job framework gives an API example of separating these events; your checklist product needs its own completion evidence.

Choose the next action from the failure

In this batch, inspect C’s repaired export and E’s failed one before recruiting twenty more customers. Ask B and D what their next task required and why they chose another route. You have no basis to blame their decisions on the development method, the price or a missing feature without hearing the reason.

Repeat the same narrow offer after fixing a reproducible delivery failure. Change the offer when customers consistently describe a different job. Expand only when you can state which outputs the product handles, how a failure is recovered and how much human work each delivery still requires. Keep the payment, delivery and repeat-use rows separate as the sample grows.