A promising app name can conceal several different businesses. Supplier Margin Guard could mean comparing documents, forecasting purchase prices, negotiating with suppliers, or automatically disputing charges. Merchant Revenue Guard could mean reconciling records, retrying payments, monitoring margins, or recommending marketing changes. Choosing a name before choosing the job makes the opportunity look clearer than it is.
The first Salars candidates should be tested as narrow buyer-job hypotheses, with explicit evidence gaps and bounded next commitments. None of the named apps in this article is established as an operating Salars business, available product, or source of measured customer results. This chapter compares proposed tests within the AI Software Factory series and our AI guides, rather than declaring a product roadmap already validated.
Compare jobs rather than ambitious names
A useful shortlist identifies who experiences a problem, what they do now, which failure matters, what information is available, and which outcome a small service could deliver. The names can help organize discussion after those conditions are defined. They should not supply an implied promise of protected margin or recovered revenue that the first workflow cannot support.
For this proposed shortlist, Supplier Margin Guard would begin as a quote-to-invoice comparison for a defined purchasing workflow. Merchant Revenue Guard would begin as a reconciliation check across eligible order and payment exports. A third candidate, Catalog Import Check, would assess a defined file against a destination schema before import. These are working scopes introduced here, not verified product specifications or existing offerings.
The best first app guide explains why a narrow beachhead can be more manageable than a large market. This shortlist applies that principle to named Salars hypotheses. A candidate would deserve further attention when its problem, inputs, and next experiment fit actual capabilities and resources. Market size alone would not settle the choice.
Do not rank the candidates as though their commercial facts are already known. Buyer access, willingness to pay, input rights, compatibility, support burden, and recurring need are unresolved. The comparison should identify the next evidence needed for each, and which test can most efficiently change the investment decision.
Specify Supplier Margin Guard’s first hypothesis
The proposed buyer would be an operator who has responsibility for checking supplier invoices against agreed quote terms. The narrow job would be to identify documented differences and unresolved relationships for human review. The service would not initially negotiate, accuse a supplier, or change accounting records. A legitimate approved change could explain a difference, so discrepancy would not automatically mean loss.
The hypothesis would be that a traceable comparison reduces a costly review step under a defined input family. Inputs might include line identifiers, quantities, prices, relevant terms, and the corresponding documents. Before assuming feasibility, verify which fields exist, how they are represented, and what information a reviewer needs to establish the answer. A missing identifier can make the task ambiguous rather than merely harder to code.
The largest early evidence gaps would concern the frequency and consequence of the job, access to appropriately handled documents, existing alternatives, and willingness to pay for the bounded result. A purchasing operator might already use a satisfactory accounting feature. Another might need a specialist because terms cannot be interpreted safely by a general tool. Those possibilities belong in the brief before development.
A proposed first test would inspect independently created fixtures and interview eligible operators about their current process under an appropriate authorized arrangement. A later permitted concierge comparison could test delivery and payment. The test would establish baseline review effort, independent answers, legitimate-change counterexamples, budget, and stop date. No interview, payment, or completed comparison is reported here.
Specify Merchant Revenue Guard’s first hypothesis
The proposed buyer would be a merchant or finance operator responsible for reconciling order and payment records. The first job would be identifying unmatched or inconsistent records under a documented export scope. It would not promise recovered revenue or automatically issue refunds. An unmatched record can reflect timing, incomplete input, or a legitimate adjustment rather than a financial error.
The hypothesis would be that a clear review queue helps the operator resolve a recurring reconciliation task with less unnecessary investigation. The product would show source references and uncertainty. It would distinguish a supported match, a supported mismatch, and insufficient evidence. That distinction protects the buyer from treating an attractive total as money they can collect.
The early gaps would include export compatibility, identifier relationships, permitted data handling, existing platform features, review cost, and the buyer’s actual next action. If every flagged case requires a different specialist judgment, the software might be an assisted service rather than a self-service subscription. That can still be useful, but its price and support model would differ.
A proposed compatibility test would use eligible fixtures with missing records, timing differences, duplicate identifiers, legitimate refunds, and mismatched prefixes. A separate buyer test would assess whether the traceable queue is valued at real terms. The two results would remain separate: compatibility does not establish demand, and willingness to try does not establish reliable delivery.
Specify Catalog Import Check’s first hypothesis
The third proposed candidate would help an operator determine whether a file meets a defined destination schema before import. It would identify missing fields, invalid values, duplicate relationships requiring review, and unsupported conditions. Its first scope would be one documented import family, rather than every commerce platform and file format.
The hypothesis would be that a clear preflight result prevents avoidable import attempts and reduces the effort of interpreting technical errors. The tool would not merge products automatically or guarantee an error-free catalog. A technically valid file could still contain incorrect business information. The offer would explain what validation checks and what it leaves to the operator.
The evidence gaps would include how often the job occurs, whether the destination already provides an adequate checker, how much review time is actually saved, and whether buyers prefer a one-time job to ongoing access. A migration task might be valuable and infrequent. A subscription could be poorly matched even if the tool works technically.
A proposed test would compare the current destination error process with a clear preflight report on independently answered cases. Include inputs that pass syntax but fail the business relationship, and inputs correctly rejected as unsupported. Observe whether an eligible operator can act on the report without bespoke explanation. A favorable local result would justify only the tested input family and assistance model.
Use one evidence matrix without inventing scores
A first comparison would record buyer accessibility, current alternative, task recurrence, input feasibility, allowed handling, consequence of a wrong result, required reviewer expertise, delivery cost, and the next test. Unknown would remain unknown. The matrix would organize uncertainty rather than supply simulated market data or a numerical winner unsupported by observations.
The software opportunity score guide can help structure that review. A score should remain a summary of evidence and assumptions, not authority to build. If input access is unresolved, a high severity score does not make a live integration appropriate. If a buyer can solve the job with a standard setting, an impressive technical demo does not create a commercial reason to switch.
Supplier Margin Guard might require more domain interpretation than Catalog Import Check under these proposed scopes. Merchant Revenue Guard might depend on more careful timing and identifier reconciliation. Those are hypotheses about the design, not measured comparative burdens. A reviewer would inspect actual permitted examples before choosing the relative implementation or support budget.
Record counterevidence beside each attractive mechanism. An adequate existing checker, rare need, unavailable document, unclear buyer authority, or high-cost exception could reject or narrow the candidate. A shortlist that only describes upside is a naming exercise. A useful shortlist tells the operator which observation could make them stop.
Separate technical, buyer, and economic tests
A technical test asks whether the proposed behavior can be delivered under defined inputs and constraints. A buyer test asks whether eligible people value the outcome at real terms. An economic test asks whether delivery, acquisition, maintenance, and support fit a sustainable boundary. Passing one does not automatically pass the others.
The validate before coding guide develops that sequence. Coding can be useful early when technical uncertainty controls the decision, but a complete interface is unnecessary when the unresolved question is whether anyone needs the job. Conversely, enthusiastic interviews do not resolve a missing-data condition. Choose the next activity according to the uncertainty it can actually answer.
NSF’s I-Corps overview describes customer discovery as part of assessing an invention’s market potential. It supports a learning process, not a universal interview count or guarantee of commercial success. A Salars candidate would need its own bounded questions, appropriate participants, and evidence interpretation.
The SBA’s business planning guidance also considers demand, alternatives, and direct research. A public complaint can prepare a question for an interview or test. It cannot stand in for payment, repeat use, or viable support economics. Proposed Opportunity Radar would preserve those distinctions rather than mark the shortlist validated because it found relevant posts.
Build protected cases around the consequences
For Supplier Margin Guard, a harmful error could be presenting a legitimate charge as unsupported. For Merchant Revenue Guard, it could be implying that a refund should be repeated. For Catalog Import Check, it could be encouraging a destructive merge or declaring an unsupported file safe. The evaluation should include those cases rather than only successful demonstrations.
Establish correct answers independently where possible, retain unresolved cases honestly, and separate development examples from protected assessment. The OpenAI evaluation best practices recommend task-specific evaluation and human calibration. They do not supply a universal threshold for these proposed apps. Acceptance should reflect the buyer’s job and the consequence of a wrong conclusion.
Measure review effort and appropriate refusal alongside completion. A candidate that completes every file by guessing can appear productive while failing the promise. A candidate that refuses too many ordinary files may be safe in a narrow sense but commercially unhelpful. The decision requires the separate categories and the actual workload rather than one blended score.
A simulated evaluation can support behavior under its defined cases. It does not establish real customer outcomes or demand. A later pilot would need permitted inputs, clear assistance, operating coverage, and an outcome record. Keep the path from design to simulation to observation visible so the product page cannot inherit confidence from an unexecuted test plan.
Compare the next commitment with its alternatives
Suppose a hypothetical shortlist budget allows $600 of direct spending and twelve owner hours. A $150 compatibility check using three hours could fit, leaving $450 and nine hours under the stated boundary. A broader build requiring $1,000 and twenty hours would not fit. The correct next step might be a smaller test or deferral, even if the broader idea remains interesting.
These figures are illustrative limits, not Salars budgets or standard experiment costs. The software capital allocation guide compares the next dollar and hour with existing obligations and alternatives. A new candidate should compete with improving a current product or preserving capacity, rather than receive automatic funding because it has a name in the series.
Protect maintenance and support reserves. A concierge pilot can create obligations even before a hosted app exists. Someone must review outputs, answer questions, and resolve an error. Include that work in the proposed test and limit the number of simultaneous participants accordingly. A free pilot is not free to operate, and a paid pilot does not remove the duty to deliver the agreed scope.
Choose one test with the greatest plausible decision value under the current uncertainty. If all three candidates lack buyer evidence, three backends may be a poor allocation. If one has an independently documented buyer job but uncertain compatibility, its small technical test could deserve priority. The ordering would follow evidence available at the time, not a fixed declaration of which name should win.
Define the decision after each test
Before execution, state whether the result could justify continuing, narrowing, revising, pausing, or stopping. A compatibility failure might reject an input family while leaving another eligible family worth investigation. A buyer who values an assisted report but not a subscription might support a service test. A high support burden might require a different price or a narrower promise.
Set a stop date and a total resource ceiling. A test should not become an open-ended rescue project when the first result disappoints. Any follow-up needs a specific remaining question and a new bounded decision. Preserve counterexamples and limitations rather than delete them to keep the candidate attractive.
The proposed Opportunity Radar guide connects these findings to provenance and evidence maturity. Radar would receive the actual execution record, including deviations from the plan. A pending test remains a proposal. A completed test supports only what its observations and design establish. A positive result does not automatically authorize production.
If a candidate advances to a pilot, define the service and operating gate separately. The app would need appropriate access, data handling, billing, diagnostics, support, and recovery. The first user outcome matters more than a public launch announcement. The shortlist should remain a queue of evidence-backed decisions rather than a promise to ship every proposed app.
Keep the shortlist dated and revisable
Each candidate would have an owner, evidence date, current question, and revalidation trigger. A new vendor feature could remove the need. A changed export could alter feasibility. A buyer interview could reveal a different role or a less frequent job. Update the record when those conditions change rather than preserve the original ranking out of loyalty to the name.
A deferred candidate would state what could bring it back. A rejected candidate would retain the scoped reason and permitted supporting evidence. Neither status would justify retaining unnecessary customer material or continuing an exposed prototype indefinitely. The shortlist would remain a decision instrument with a maintenance budget, not a permanent catalog of future promises.
What Would We Do at Salars?
We would begin by selecting one narrow operator job and confirming what is known directly. Supplier Margin Guard, Merchant Revenue Guard, and Catalog Import Check would remain hypotheses until their respective buyer, input, delivery, and economic questions are tested. No current Salars customer, product availability, revenue recovery, retained use, or market demand is established here.
We would prepare a bounded plan with a baseline, independent success criteria, protected cases, counterexamples, budget, and stopping conditions. We would separate technical compatibility from buyer acceptance and maintained economics. Interviews, outreach, and private-data handling would follow the actual authorization and applicable arrangement rather than occur automatically because a discovery system found a lead.
If the first test rejected the broad idea, we would preserve the scoped lesson and consider a narrower job only when evidence supports it. If it supported a useful next increment, we would compare that increment with other uses of the resources. Proposed Salars Forge would coordinate an accepted delivery stage, but neither Forge nor Radar is claimed as implemented.
The desired outcome would be one justified next commitment, not three hurried launches. A candidate can earn priority because it resolves an important buyer job under workable conditions. It can also leave the shortlist because the alternative already works, the required inputs are unavailable, or delivery costs exceed the value. Both outcomes would make the software factory more disciplined.
Sources
- NSF I-Corps overview: customer discovery and market-potential learning, not guaranteed demand or a universal interview threshold.
- SBA Plan your business: demand, alternatives, and direct research questions.
- OpenAI evaluation best practices: task-specific tests and human calibration.
Sources checked October 7, 2026. App scopes, budget arithmetic, tests, and prioritization are proposals or hypothetical examples. No executed customer test, measured app outcome, established market ranking, or available Salars product is asserted.
Loading comments…