A free report that finds an alarming number can sell software quickly. It can also persuade a customer to buy the wrong remedy. The crucial question is how the number was produced, what it establishes and what action follows from it. Diagnosis deserves a better standard than whatever generates the most frightened clicks.
A useful free diagnostic creates qualified demand by revealing a real, bounded problem and showing enough evidence for the reader to judge it. The paid offer then delivers a distinct remedy, workflow or maintained service. The diagnosis should remain truthful and useful when the reader declines to buy. Otherwise the free tool is an advertisement disguised as an assessment.
For a small software business, this can be an effective way to connect education with buying intent. A prospect learns whether the problem applies to their own work instead of merely reading a broad promise. The founder learns which customers have the supported problem and whether they will pay for the next step. Neither benefit appears automatically because a page offers a free score.
Choose a finding that changes a decision
Start with the customer’s decision, then identify the observation that can inform it. A hypothetical merchant deciding whether to review supplier prices may benefit from a report that identifies mismatched price records. A generic “store health” score could combine unrelated issues without telling the merchant what to do first.
The finding needs a defined scope. Which files or records are examined? What time period do they cover? What fields are required? What condition produces a flag? What does the flag mean? A discrepancy between two prices does not necessarily establish an error. One price may include tax, shipping or a temporary promotion that the other omits.
That distinction should be visible in the report. For example, “These eight product rows differ from the supplier price column in the uploaded file” is an observation. “Your supplier overcharged you” is a causal conclusion requiring additional evidence. “You can recover $900” adds another unsupported step unless eligibility, process and actual recovery have been established.
The diagnostic can still be useful without resolving everything. It might reduce a long catalog to a manageable set of records that deserve review. The report should identify the review needed and preserve the underlying comparison. A smaller reliable finding can help the customer more than a dramatic sum assembled from questionable assumptions.
Market research guidance from the SBA distinguishes broad information from direct investigation of the intended audience. A diagnostic belongs in that direct relationship: it can help expose a specific workflow and its constraints. It does not independently prove market demand, and the founder should not substitute diagnostic downloads for actual payment evidence. SBA market research guidance.
Separate observation, interpretation and proposed action
A diagnostic becomes easier to trust when its layers can be inspected. Observation describes the supplied record. Interpretation explains why the observation might matter. Proposed action identifies a possible next step. Each layer can have a different degree of certainty.
Suppose a merchant uploads two hypothetical catalog files. The diagnostic observes that one supplier cost changed from $12 to $15. If the merchant’s selling price remains $20, the simple price-minus-cost spread falls from $8 to $5. That arithmetic is established under the given numbers. It does not include payment fees, shipping, returns or other expenses, and it does not establish total profit.
The interpretation is that this product may deserve a margin review. The action might be to confirm the new cost and consider changing price, negotiating supply or retiring the product. The diagnostic should not automatically choose a price increase without understanding demand, contractual obligations and customer expectations.
Show the calculation where it changes the decision. A merchant should be able to trace the flag to a product, source file, timestamp and comparison rule. Where an AI system contributes interpretation, keep that contribution distinct from deterministic arithmetic. Fluent language can make a tentative explanation sound more certain than the supporting records allow.
The explainability chapter develops how to present evidence and uncertainty. In a free diagnostic, that work also prevents the sales process from overstating what the product knows.
Define the paid boundary before promoting the free tool
The free and paid offers should have different jobs. The free diagnostic might inspect one authorized sample and produce a report. The paid service might monitor recurring changes, integrate with the customer’s workflow, maintain history or support reviewed corrections. The customer should understand the difference before investing time in setup.
A poor boundary makes the free result deliberately incomplete in ways that confuse the buyer. Hiding the relevant rows while displaying a frightening total prevents inspection. Requiring payment to learn whether the product supports the customer’s format turns qualification into a toll. A diagnostic should provide enough information to assess its own credibility.
Paid work can legitimately begin where effort, continuing responsibility or richer capability begins. For example, a report may identify possible mismatches for free, while maintaining scheduled comparisons and delivering change history requires a subscription. The initial finding retains value even when the customer performs the review manually.
The promise should state which remedy is actually available. If the paid step is a consulting service delivered by a person, describe that service. If automation is incomplete, do not imply immediate self-service resolution. A clear boundary protects support capacity because buyers enter with a realistic understanding of what will happen next.
The concierge MVP chapter examines selling a manually delivered result before automation. A free diagnosis can precede that model, provided the manual delivery and its limits remain explicit.
Ask for only the data the finding needs
A diagnostic that needs product costs should not casually request customer identities, entire order histories or unrestricted account access. Data collection affects both trust and operating risk. Narrow inputs make the tool easier to explain and can reduce the work required to safeguard, delete and support the resulting records.
Begin by listing required fields and their purpose. Product identifier may be needed to match rows. Supplier cost may be needed for comparison. Customer names may be irrelevant. If a sample file can establish the finding, offer that path before requesting a full integration. Demonstration data can let a visitor examine the report without sharing any real business information.
Explain retention in practical terms. Does the system delete the sample after producing the report? Does it retain a result for the visitor to retrieve? Does the founder intend to use records for product improvement? Those are different purposes and should not be blurred into a vague statement that data helps improve the service.
The ICO’s current guidance identifies minimisation, purpose limitation, storage limitation and accountability among UK GDPR principles. Its authority is jurisdiction-specific; it does not establish every legal obligation for every diagnostic. It supports a clear design principle: collect and keep information for a defined purpose, and determine the applicable requirements before processing personal data. ICO data protection principles.
The free offer should remain free of surprising commitments. Submitting a file for analysis is not automatically permission to send it to unrelated partners or enroll the visitor in an indefinite marketing sequence. Match follow-up and data use to the permission actually given.
Build a diagnostic that can say nothing is wrong
A trustworthy tool must be able to return a clean or inconclusive result. If every input generates a problem and a purchase recommendation, the system is optimizing a sales outcome rather than evaluating a condition. Include cases where the expected answer is that the supplied data does not establish a supported problem.
The distinction between clean and inconclusive is useful. “No mismatches were found among valid comparable rows” differs from “The supplier cost field was missing, so comparison could not be completed.” A tool that labels both outcomes healthy creates false reassurance. A tool that labels both dangerous creates false urgency.
For the hypothetical catalog diagnostic, evaluation cases should include matching rows, genuine discrepancies, duplicate identifiers, missing columns, different currencies, tax differences and stale records. They should also include malformed files and unrelated content. Determine expected outcomes before tuning the system to produce attractive reports.
OpenAI’s evaluation guidance recommends task-specific cases, edge and adversarial coverage, and calibration of automated graders with human judgments. That supports an evaluation process rather than a universal score threshold. A diagnostic’s acceptance criteria need to reflect the actual harm of a false flag, missed problem or misleading explanation. OpenAI evaluation best practices.
Keep a protected set of cases separate from development examples. Repeatedly tuning the tool against the same samples can create apparent improvement that disappears on unfamiliar inputs. When the product changes, rerun the meaningful cases and inspect the failures. An appealing report design cannot compensate for incorrect classification.
Treat uploads as data with limits
Uploaded material can contain more than the fields the developer expects. A spreadsheet might include hidden tabs, formulas, unexpected encodings or confidential notes. An AI-assisted diagnostic can also encounter text that attempts to redirect the system’s behavior. The fact that a visitor voluntarily submitted a file does not make every instruction inside it authoritative.
Use a defined intake process. Validate format and size, extract only needed fields, reject unsupported content and keep credentials outside the model’s reach. If interpretation uses external material, maintain a clear boundary between that material and the application’s instructions. A report should not gain authority to send messages, change prices or expose records simply because an uploaded cell asks it to.
OWASP describes indirect prompt injection through external files and websites and recommends least privilege and controls around consequential operations. These mitigations reduce risk; they do not establish that a diagnostic is immune to attack. OWASP prompt injection guidance.
A free diagnostic usually needs preparation authority rather than commitment authority. It can report a possible issue without changing the merchant’s store. If a later paid workflow includes corrections, introduce a separate reviewed action path. The safe-write chapter explains why preview, approval and verification belong beside such changes.
Measure qualification after the report
Diagnostic completion is an intermediate event. Track whether the visitor belongs to the intended segment, receives a valid result, understands it and has a supported reason to consider the paid offer. A thousand completed reports can be less useful than a smaller set of relevant evaluations if most inputs come from people who cannot use the remedy.
Define the denominator for each rate. Report completion among started submissions differs from valid diagnoses among supported submissions. Paid conversion among all visitors differs from paid conversion among qualified users who received a supported finding. Show counts beside rates when the sample is small.
A hypothetical test might yield thirty submissions, twenty valid comparisons, ten supported findings and two paid pilots. These numbers describe one possible funnel; they are not a benchmark. The founder would investigate why ten submissions were invalid, whether the ten findings were useful and whether the two paid pilots achieved the promised result. Celebrating the largest number would miss the work needed to improve the process.
Non-purchase can be informative. The user may solve the issue manually, lack budget, prefer another workflow or decide the flagged problem is too infrequent to warrant monitoring. That evidence can change the paid offer. It should not automatically prompt stronger urgency or more alarming language.
Include the cost of being helpful for free
Free diagnosis has delivery costs. Compute, storage, third-party calls, abuse handling, report generation and support all consume resources. A manually reviewed result may be especially valuable, but its labor should appear in the acquisition budget. Otherwise the funnel can look profitable only because the operator’s time disappears from the calculation.
Consider an explicitly hypothetical test of twenty valid reports. If each costs $1 in services and requires ten minutes of review, direct service cost is $20 and review takes about 3.3 hours. At a planning value of $30 per hour, the review represents approximately $100. If two customers buy, the diagnostic portion of acquisition cost is about $60 per buyer before content, outreach and other sales work.
The result may be acceptable if the paid customers receive sustained value and produce sufficient contribution. It may be unsustainable if most buyers cancel after a single report or require expensive remediation. A free diagnosis can reveal a one-time job that is better sold as a paid report than as a subscription. Let the customer’s recurrence determine the model.
Put an operating limit around the free service. A file-size boundary, supported-format rule or finite review allowance can be reasonable when clearly explained. If demand exceeds capacity, change the offer or delivery process. Quietly reducing accuracy to maintain a promotional promise transfers the cost to the customer.
Keep the report useful when the sale fails
The best test of the diagnostic’s integrity is the non-buyer’s experience. Can the person inspect the result, understand its limits and take an appropriate next step without purchasing? If yes, the tool has delivered value and may establish credibility even when the current offer does not fit.
Provide a proportionate manual path when possible. A discrepancy report can explain how to verify source dates or compare a flagged row. It need not give away an entire maintained service to be useful. It should avoid creating dependence by obscuring the original observation or implying that only the vendor can interpret it.
This also improves research quality. Users who understand the finding can explain why they do or do not want the remedy. Users confronted with a mysterious score mostly respond to the presentation. Clear reports help the founder learn about the underlying job rather than the effectiveness of a fear-based message.
Review claims periodically. If the paid product changes, update the free tool’s recommendation boundary. If a field becomes unavailable or a platform rule changes, disable the affected diagnosis until it can be interpreted correctly. A marketing asset that remains online after its assumptions fail can continue attracting customers to an unsupported promise.
What Would We Do at Salars?
A proposed Salars diagnostic would begin with one merchant question that can be answered from narrow, authorized inputs. Supplier Margin Guard is a candidate idea, not an operating product with measured savings. A first experiment might compare supported supplier-price files and show rows requiring review. It would explicitly distinguish arithmetic from a recommendation about the business.
The report would include source columns, timestamps, comparison rules and known exclusions. It would allow clean and inconclusive results. Demonstration data would let readers understand the output before sharing real records. Data retention and follow-up would be described beside the submission step.
Before promoting it, we would evaluate normal, missing, conflicting and adversarial inputs. The test would measure useful findings, valid comparisons, qualified paid pilots and delivery effort. Cases in which merchants prefer a manual solution would remain part of the evidence. They might favor a report business rather than recurring software.
The paid offer could become maintained monitoring or a reviewed correction workflow if customers demonstrate that need. That development remains conditional on observed demand, appropriate data access and acceptable economics. No sale should require the diagnostic to exaggerate the problem.
The free report earns its place when a merchant can make a better decision after reading it. The paid product earns its place when it reliably carries the next part of that work.
Explore the AI Software Factory series and the wider AI section.
Sources
- SBA, Plan your business: audience-specific research guidance.
- ICO, Data protection principles: jurisdiction-specific data-handling principles.
- OpenAI, Evaluation best practices: evaluation design and grader calibration.
- OWASP, Prompt injection: risks from external content and privilege controls.
Passages checked October 7, 2026. All merchant data, funnel counts and cost examples are hypothetical. Salars diagnostic and software names are proposals.
Loading comments…