“Yes, I would use that” is an encouraging sentence. It leaves the important conditions unstated: at what price, with which data, through what purchasing process, and instead of what current method?
A buyer’s commitment to a defined offer answers more than their reaction to an idea. Yet even payment has a scope. One paid pilot demonstrates that one buyer accepted particular terms. It does not prove that strangers will subscribe, that delivery will be profitable, or that customers will remain.
The title’s word “prove” therefore needs a careful meaning. Before building substantial software, a team can obtain stronger evidence that people will pay for a bounded result. It cannot eliminate all commercial uncertainty.
This chapter of The AI Software Factory, within the SalarsNet AI section, describes a proposed validation process. It separates interest, purchasing authority, payment, delivery, and continued value so that each observation supports the decision it actually addresses.
Define what you are asking the buyer to purchase
An idea is difficult to buy because its result and obligations remain vague. A bounded offer names the customer, task, input, output, delivery time, price, review conditions, and limits.
For a hypothetical supplier-file service, the offer could be to transform one specified file into an agreed format, flag ambiguous records for review, and return an inspectable output by a stated date. It would exclude automatic import into a live inventory system and promise no unsupported accuracy rate.
That offer can be delivered manually or with existing tools. The buyer is purchasing the result under clear terms. The team is learning whether the result matters and what delivery requires before committing to an automated product.
The offer should match a recent problem episode. If the customer cannot identify the task or input, the trial may test curiosity rather than operational value. Pain qualification supplies the problem brief; validation adds a commercial commitment.
Avoid making the offer so small that it no longer tests the intended value. A free report about the problem may attract interest without showing willingness to pay for its solution. A paid task unrelated to the eventual product can produce revenue without validating the proposed promise.
Identify the user, buyer, and approver
The person who performs the task may value the solution but lack authority to purchase it. The owner may approve spending while an accountant or manager controls the data needed for delivery.
Ask how an ordinary purchase of this kind happens. Who evaluates it? Who approves it? Which budget pays? What information or terms are required? The goal is to understand the process, not pressure a participant to act beyond their authority.
A commitment from the correct buyer is stronger than enthusiasm from someone outside the purchasing process. A commitment still depends on the offer’s conditions. If it requires an unapproved integration or data sharing arrangement, resolve that condition before treating the trial as executable.
NSF describes I-Corps as experiential customer discovery for assessing inventions’ market potential. That provides a useful institutional example of learning beyond technical feasibility. It does not prescribe a universal interview count or make a particular pilot statistically conclusive. About I-Corps.
Document purchasing conditions alongside the problem. They may explain why a seemingly useful app cannot be adopted, or why a simpler reviewed service can be tried sooner.
Choose a commitment that fits the uncertainty
Different commitments answer different questions. Sharing a redacted input can support feasibility discovery. Reserving a trial date can show effort and interest. Signing a bounded agreement can clarify authority and terms. Paying can demonstrate willingness to exchange money for the offer.
A refundable deposit is not identical to a completed purchase. A letter of intent is not revenue. A heavily discounted pilot may show interest at the discounted terms without establishing a sustainable price. Keep the distinctions visible.
Do not manufacture obstacles merely to make a test look rigorous. The commitment should resemble a legitimate step toward the customer receiving value. Asking for unnecessary sensitive data or a burdensome contract can test tolerance for your process rather than demand for the result.
For a service that can be delivered safely now, a paid bounded pilot may be appropriate. For a product requiring further development, a transparent reservation or expression of interest may be useful if its limitations are clearly explained. Do not imply that unavailable software is ready.
The next decision should follow the evidence level. Interest can justify another discovery conversation. A paid pilot can justify learning about delivery. Repeated paid use can support a stronger product decision. No single step substitutes for all the others.
Write the test before presenting the offer
A proposed validation record should state the segment, offer, price, channel, permitted delivery method, capacity, end date, and decision criteria. It should also state what would make the team stop.
The baseline is the customer’s current method, not an imagined world in which they have no alternative. Ask what the pilot would replace and what work would remain. A result that adds another review step may have less value than the builder expects.
Set outcomes that can be observed: an authorized buyer accepts the terms, provides suitable input, receives the result, uses it for the stated task, and decides whether to continue. The exact conditions depend on the offer; they are proposed operational criteria, not universal scientific thresholds.
Preserve refusals, delays, and conditional responses. A record containing only successful buyers can conceal the cost of finding them or the reasons others decline. If the segment changes midway, record the change rather than pooling unlike responses.
No test described in this article has been executed. Real buyer records, offers, payments, and delivery outcomes would be required before making a local validation claim.
Keep the offer honest
A prospective customer needs to know what exists, what will be done manually, and what remains uncertain. Manual delivery can be a sensible validation method. Concealing it can create false expectations about speed, scale, and reliability.
State the limits where they affect the decision. If the output requires customer review, explain what they should review. If ambiguous data will be flagged rather than guessed, describe that behavior. If the service cannot accept certain inputs, say so before taking the order.
Do not advertise measured savings, accuracy, or return on investment without supporting evidence. A hypothetical estimate can help frame a conversation if labeled as an estimate, but it should not become a claim of proven results.
Payment terms, refunds, cancellation, data handling, and applicable legal requirements need appropriate current review before an actual offer. The proposed process here does not supply jurisdiction-specific contract or consumer-law advice.
The concierge MVP chapter develops manual delivery in detail. Its commercial honesty matters because a customer is evaluating a result they may depend on, not merely participating in the builder’s learning exercise.
Observe the customer’s effort as well as the payment
A buyer can pay and then never provide the input. They can receive the result and never use it. They can use it once because a friendly relationship makes the trial easy, then return to the prior method.
These outcomes should remain separate. Payment supports willingness to buy the offer. Input completion reveals onboarding conditions. Use reveals whether the result fits the task. Continued use adds evidence about recurring value.
Track the handoff points. Where does progress pause? Does the customer understand what to supply? Are the required records available? Does someone else need to approve the output? Is the result easy to inspect and incorporate?
An onboarding failure can be a product problem, a segment mismatch, or a misunderstanding in the offer. Investigate the cause before concluding that demand is absent. Equally, do not excuse every failure as onboarding when the customer has no meaningful reason to use the result.
A useful post-delivery conversation asks what happened with the output. Did it replace work? Did it require corrections? Which parts were useful? What would make the next occurrence worth paying for? Recent behavior provides firmer evidence than another abstract question about whether the idea is good.
Include the delivery economics
A pilot can sell while revealing an unsustainable delivery model. Count the work honestly: preparation, customer communication, input cleanup, output generation, review, corrections, and support.
Suppose an illustrative pilot charges $120. Direct external expenses are assumed to be $10, and delivery uses three hours valued at $30 per hour. The contribution before acquisition and fixed overhead is $20. If delivery uses five hours, the same illustration becomes negative $40.
Those figures are hypothetical. They do not state current market prices, wages, or Salars results. They show why a paid pilot validates something narrower than a profitable automated business.
Identify which work could plausibly disappear through automation and which remains judgment or customer support. Do not assume all manual hours become zero after coding. Input ambiguity, purchasing questions, and exception review may persist.
The SBA’s break-even guidance links fixed costs to price less variable cost. A software model must classify costs carefully and include customer-related labor where it varies with delivery. Startup costs and break-even analysis.
A pilot with poor contribution can still produce useful information. The decision might be to raise the price, narrow the promise, improve the intake, offer a service, or close the candidate. Calling the pilot validated without reporting the burden hides the information it was meant to reveal.
Interpret refusals without inventing motives
A refusal can reveal price sensitivity, low urgency, an adequate alternative, lack of authority, or distrust of the offer. It can also reflect timing or an unrelated constraint.
Ask for clarification when appropriate, but do not force the buyer into a preferred explanation. “Too expensive” can mean the result has little value, the budget is unavailable, or the buyer does not believe the promise. Those conditions require different responses.
Record the explanation as the person’s explanation. If you infer another cause, label the inference separately. A founder can easily reinterpret every refusal as evidence that better marketing will solve the problem.
Compare refusals within the intended segment. If buyers with the same task repeatedly prefer their current method, examine that alternative more carefully. If the people declining never experience the task, the channel may be reaching the wrong audience.
The customer interview chapter explains how to investigate behavior without leading people. Validation benefits from the same discipline, while preserving the added significance of a defined purchasing decision.
Avoid the friendly-customer illusion
Friends, partners, and existing business relationships can help a team reach its first trial. Their cooperation may also make the trial easier than an ordinary purchase.
Describe that context. A customer who knows the builder may tolerate delays, accept manual help, or pay partly to support the project. Their feedback can be valuable without proving independent demand.
A later trial should test transfer to a customer who does not rely on that relationship. Keep the offer, segment, and delivery boundaries comparable enough to understand what changed. If the second buyer requires substantially different work, the product’s repeatability remains uncertain.
Do not tune the promise endlessly to satisfy each person and then combine all purchases as validation of one product. A portfolio of custom projects can be a legitimate service business. It is different from repeated sales of a common software promise.
The first-app segment discussed in best first app helps define which customer differences matter. Validation should reveal where the common promise holds and where it breaks.
Preserve a fair comparison across offers
Changing the segment, price, promise, and channel at the same time can produce a sale without revealing which change mattered. Early discovery does not need laboratory purity, but its record should make the changes visible.
If the first offer fails, choose the next revision because it addresses a specific explanation. A clearer input requirement might address onboarding confusion. A narrower output might reduce delivery cost. A different channel might reach the purchasing role that the first channel missed. Record the reason before seeing the next response.
Keep later trial cases separate when assessing a revised offer. Results used to reshape the promise are development evidence; fresh buyers under the revised conditions can test whether the improvement transfers. A small sample still supports only a local conclusion, and differences between buyers may explain part of the result.
Stop the comparison when the authorized time or delivery capacity is exhausted, when necessary inputs cannot be obtained responsibly, or when further trials would not change the immediate decision. Continuing indefinitely can create obligations without resolving the original uncertainty.
The useful output is an honest account of which offer was presented to which buyer and what followed. That record prevents a successful custom exception from quietly becoming a claim about a repeatable product.
Decide what the evidence justifies
At the end of a bounded trial, write a decision statement. It should describe the offer, buyer context, observed commitments, delivery results, costs, and remaining uncertainties.
A narrow supported conclusion might be that one authorized buyer paid for a specified result and used it successfully under recorded conditions. A broader claim about recurring demand needs repeated evidence. A claim about scalable automation needs technical and delivery evidence. A claim about retention needs time.
Keep these conclusions separate. They allow progress without pretending all uncertainty has disappeared. The team can choose the next investment because one important question has been answered.
Close or revise the candidate when the offer fails for a consequential reason: buyers prefer an adequate alternative, delivery requires more labor than the accepted price supports, required data are inaccessible, or the result does not fit the task. Do not keep the project alive solely because the prototype is appealing.
A useful decision can be to continue with a service before software. It can also be to stop. The test’s purpose is to improve the choice, not to ensure every idea survives.
What Would We Do at Salars?
A proposed Salars validation would take one problem brief into a bounded offer for a reachable, authorized buyer. A supplier-file transformation could be a candidate if actual recent records establish the need and permitted sample data are available.
The offer would state the output, inputs, price, delivery time, review boundary, and exclusions. The team would record refusals and conditional responses alongside purchases. It would not collect payment for an unavailable product while implying that it already operates.
Delivery would begin with existing tools and human review where appropriate. The team would measure its work, inspect the customer’s use of the result, and ask whether a repeat occurrence would justify another purchase. Those observations would guide the decision about automation.
This is proposed work. No Salars buyer, payment, delivery saving, or retention result is asserted here. The next investment would depend on what an actual bounded trial established.
A payment test leaves the builder with a precise sentence about what a buyer purchased and what happened afterward. That sentence is a stronger foundation for software than applause for an idea.
Sources
- National Science Foundation: About I-Corps, official description of experiential customer discovery and market-potential assessment.
- U.S. Small Business Administration: Startup costs and break-even analysis, official cost framework informing the illustrative delivery calculation.
Sources inspected October 7, 2026. The offer protocol and Salars application are proposals, and the financial example is hypothetical. No payment test or commercial effectiveness experiment was executed for this article.
Loading comments…