A competitor can reproduce the screen that took you three months to build. That does not mean they can reproduce the business behind it. They might lack a reliable path to the buyer, the rules that make an exception safe, the integration that fits an existing process, or evidence that the result deserves to be trusted. They might also reproduce all of those more easily than you expect. Calling them a moat before testing that possibility hides the important question.
A software advantage matters when it changes the buyer’s choice and remains expensive for a plausible rival to reproduce. Visible code is one input to that advantage. It is not a sufficient explanation of it. This article examines how to test a claimed defense rather than compiling a list of fashionable assets. The AI Software Factory series, within our AI guides, builds toward maintained products; a product deserves further investment only when its economics and buyer value survive a realistic alternative.
Name the rival before naming the moat
Imagine a proposed purchasing tool that flags discrepancies between an invoice and a supplier quote. Its founder says the advantage is an AI matching engine. That statement leaves out the rival. A well-funded procurement platform might already have the customer relationships and data access to add matching. A small consultant might perform the same job with spreadsheets and a service contract. A capable customer might improve their own process. Each alternative attacks a different part of the business.
Write one credible rival scenario rather than an imaginary company that has unlimited resources and no constraints. Describe its existing audience, technical capacity, access to the necessary inputs, ability to support exceptions, and reason to enter the market. A large incumbent may have reach but little interest in a narrow segment today. That lack of interest can change if the segment becomes more profitable. A specialist may have deep knowledge but limited distribution. Those differences create hypotheses to investigate, not automatic protection.
Next describe the buyer’s comparison. A purchasing manager might prefer an established platform despite weaker matching because it already has approval from their security team. Another might choose a specialist because the incumbent cannot handle a particular invoice format. Your claim must say which customer chooses you, for which job, at what full cost, and why the alternative fails to deliver the same outcome. “We use better models” rarely answers those questions by itself.
A useful defense therefore has two tests. First, does the alleged advantage change the customer’s outcome or decision? Second, what would the named rival need to spend, learn, negotiate, or reliably maintain to reproduce it? A long list of assets can fail the first test. A feature buyers love can fail the second. Keep both failures visible rather than combining them into a reassuring score.
Separate a head start from a durable advantage
A working release can provide a valuable head start. It gives the founder a chance to learn from real use while a competitor is still building. But the advantage may expire as soon as the rival finishes a comparable implementation. That is still useful if the founder converts the time into better distribution, deeper operational understanding, or more reliable delivery. The initial lead should not be described as permanent.
Distinguish four states in an advantage register: proposed, observed locally, repeated, and threatened. Proposed means the mechanism is plausible but untested. Observed locally means a customer decision or operational result supports it in one setting. Repeated means similar evidence exists across relevant customers and conditions. Threatened means a new alternative or changed platform condition may reduce it. These are working categories for management, not a scientific scale or industry standard.
For example, suppose three hypothetical pilot customers finish invoice checks faster with the tool. That would support usefulness in those pilots if the comparison is measured honestly. It would not establish that a rival cannot copy the feature. If buyers also report that a documented exception process was decisive, the next investigation concerns that process: how much judgment it requires, which cases it covers, and whether another provider already offers it. Evidence for value is not automatically evidence for defensibility.
Set a review date for every material claim. A platform can introduce a bundled feature; a supplier can change an interface; a distribution partner can terminate access. An advantage that depends on external conditions needs a trigger for reconsideration. The management task is to notice erosion early enough to respond, rather than preserve the word moat in a presentation after its mechanism disappears.
Test workflow knowledge through exceptions
Workflow knowledge can be difficult to reproduce when it includes reliable handling of unusual but consequential cases. The invoice tool might recognize that a freight charge appears separately on one supplier’s documents, that a credit arrives in the next accounting period, or that a substituted part needs human approval. The durable asset would be the tested interpretation and resolution process, not merely a prompt containing a few domain terms.
Prove that knowledge with cases whose correct outcomes are established independently of the implementation. Hold back examples that were not used while developing the rules. Include near matches that should remain unresolved, legitimate price changes that should not trigger accusations, and missing inputs that require a request for clarification. A tool that finds more discrepancies by flagging everything has not necessarily improved the buyer’s job. Count review effort and harmful false conclusions alongside discoveries. Define a false conclusion as a claimed discrepancy that the established answer does not support, and distinguish it from a case the tool correctly leaves unresolved.
A rival may learn these cases quickly through a domain expert. Ask how many genuinely different rules exist, how frequently they change, and whether customers can explain them during onboarding. A hundred recorded variations might collapse into six ordinary rules. Conversely, a small number of situations may require years of contextual judgment. Do not use the size of a case archive as a substitute for understanding the difficulty of the task.
Knowledge also has carrying costs. Someone must notice changed business rules, determine who may approve an exception, retire obsolete examples, and test updates. A neglected rule library becomes a liability. The advantage is a maintained capacity to reach sound decisions under defined conditions. Its budget belongs in the product’s operating costs, including specialist review and the cost of stopping when the evidence is insufficient.
Ask whether distribution can be transferred
An audience can help a new product reach buyers, but a large audience is not necessarily a relevant one. A newsletter about entrepreneurship may contain few people who own a procurement process. A small professional association may contain exactly the decision makers needed. The asset is a dependable route to qualified buyers who can adopt and keep using the product, as explained in software distribution strategy.
Test the route separately from the product. Record the eligible audience, how many people receive the offer, how many have the problem, how many can supply usable inputs, and how many reach a meaningful outcome. Those steps reveal whether the supposed distribution advantage actually reduces the cost of acquiring an appropriate customer. Treat illustrative funnels as assumptions until measured. Reach, clicks, purchases, and retained use answer different questions.
Then test whether a rival can use the same route. A public directory is available to others. A paid advertisement is an auction rather than an exclusive relationship. A trusted introduction may be harder to reproduce, but its owner may serve several vendors. A partnership can support a durable position when its incentives, service responsibilities, and renewal terms align; the mere existence of a partner logo does not establish that position.
Distribution has concentration risk. If one channel supplies most customers, a policy change or damaged relationship can remove the advantage. Keep the buyer relationship useful beyond that initial channel through honest onboarding, dependable service, and permission-based communication. Do not assume you can export marketplace customer information or contact it for unrelated purposes. The commercial relationship and the applicable permissions must support the next action.
Make trust a set of observable commitments
Trust becomes commercially useful when it reduces uncertainty about an important purchase. For software, that might mean a clear permission request, a traceable explanation, a predictable response to an incident, or evidence that a promised task was completed. A polished design can help someone understand those commitments, but it cannot replace performance. The local guide to trust, speed, and proximity makes the same practical distinction: an advantage must alter a customer’s outcome and cover its delivery cost.
The purchasing tool could present the original invoice line beside its interpretation, name unresolved assumptions, and require approval before changing a record. A rival can copy that interface. It may take longer to reproduce the operating history, trained support practice, and documented recovery process behind it. Even then, the incumbent may possess stronger evidence. Compare the full service rather than assuming a newcomer’s transparency is unique. The software trust capital guide examines the delivery practices behind those commitments; here the question is how difficult their useful results are for a rival to reproduce.
The voluntary NIST AI Risk Management Framework offers a vocabulary for managing AI risks. It is not a certification that a product deserves buyer trust. The official page, checked October 7, 2026, says AI RMF 1.0 is being revised and identifies a critical-infrastructure profile publication as a concept note. Referencing a framework can organize work; the customer still needs evidence about this product, this use, and this operator.
Avoid converting a limited history into an absolute promise. A tool may have processed a defined set of tests correctly while remaining untested on new suppliers. Describe the tested scope and the escalation path. Being willing to refuse an unsupported case can strengthen trust, but it can also reduce market size. That tradeoff belongs in the economic assessment rather than being hidden behind claims that the software handles everything.
Distinguish useful integration from hostage taking
An integration can create real value by eliminating repeated imports, reconciling records, and fitting approvals into the buyer’s existing system. Once the customer depends on those benefits, switching requires effort. Some of that effort reflects legitimate configuration and migration work. Some reflects unnecessarily trapped information. The latter can produce short-term retention while damaging referrals, procurement confidence, and the operator’s reputation.
Describe the useful asset in concrete terms. A customer might have mapped fifty supplier identifiers and verified their approval roles. Recreating those mappings has a cost. Your product can still provide an export and a documented migration path. A buyer may choose to remain because the service works well, not because cancellation destroys access to their records. The economic case should survive a fair exit.
Compare switching cost with switching benefit. If a rival saves $20 each month, a one-day migration may delay the move. If the current product causes expensive errors, the same migration may be worthwhile immediately. A switching-cost estimate without the buyer’s alternative benefit says little. It also changes as the customer grows, an integration breaks, or a competing provider offers migration assistance.
Dependencies can reverse the advantage. An integration that took months to build may become standard through a platform update. An API restriction may make it unreliable or prohibit a planned use. Document which permissions, vendor policies, and contracts the connection depends on. Technical access is only one requirement. The right to use data and the ability to maintain the service must persist as well.
Treat data rights as part of the asset
A database is not defensible merely because competitors lack a copy. Ask whether its contents are relevant, accurate, sufficiently representative, current, and usable for the intended purpose. A collection of sensitive documents may increase risk faster than it improves decisions. A small library of verified, permitted cases may contribute more than a huge pile of unstructured records. The next article examines a solved-problem data moat in more detail.
Keep customer delivery, product improvement, and external publication separate in the permission analysis. Receiving an invoice to perform a service does not automatically establish permission to reuse it for a different training or marketing purpose. Applicable requirements depend on the data, role, contracts, jurisdiction, and proposed use. This article supplies decision questions rather than a legal conclusion for every arrangement.
The UK Information Commissioner’s Office lists principles including purpose limitation, data minimisation, storage limitation, security, and accountability in its data protection principles guidance. That guidance is specific to its legal context; it is not a complete global compliance checklist. The business implication here is narrower: a data strategy needs an articulated purpose and defensible handling rules, rather than an assumption that everything observed should be retained forever.
Assess what happens when a customer leaves or asks for a permitted deletion. If the alleged moat collapses when unauthorized records are removed, it was not a sound asset. If retained derived examples remain useful, explain how their provenance and allowed uses are established. Removing obvious names alone is not proof of anonymity. Legal and technical review may be needed before a dataset can responsibly support a broader use.
Calculate the cost of keeping the advantage
Consider an illustrative specialist product earning $6,000 monthly revenue. Suppose direct hosting and transaction costs are $600, routine support costs $1,200, and maintaining its exception library requires $1,400 of specialist time. That leaves $2,800 before other overhead, acquisition spending, taxes, and owner compensation not already included. Calling the library a moat does not make its maintenance free. The figures are hypothetical and demonstrate accounting boundaries rather than Salars results.
Now suppose a cheaper competitor causes price pressure. At $4,800 revenue with the same costs, the remaining amount falls to $1,600. The founder could reduce specialist review, but doing so might destroy the quality that justified the product. Alternatively, a narrower segment might support the price because the exception handling matters more. The right response depends on evidence about that segment, not a desire to defend the original market definition.
Estimate the rival’s reproduction burden without pretending to know its private costs. Use scenarios: it could hire a specialist, partner with an agency, acquire a tool, or add a basic feature to an existing product. Ask which path would let it serve your customers adequately. A rival does not need your entire implementation if a simpler substitute meets the buyer’s requirement. The relevant threshold is sufficient buyer value, not technical parity.
Also examine the founder’s own dependency. If only one person can resolve every exception, the company has expertise but fragile capacity. Documenting and testing that expertise may make it easier to reproduce internally and eventually externally. That is a sensible tradeoff when it improves continuity and reduces costly mistakes. Secrecy that prevents dependable delivery is not automatically better business protection.
Run a bounded challenge to the strongest claim
Choose the one advantage most responsible for the investment decision. If the claim is superior exception handling, compare the product with a credible baseline on protected cases. If it is distribution, test a relevant offer through the existing channel. If it is trust, ask buyers what evidence would make the purchase acceptable and observe their response to that evidence. These are proposed tests; no test described here has been executed as a Salars result.
Write the failure condition beforehand. For instance, a proposed exception-handling trial might fail if the baseline reaches equally correct decisions with comparable review effort, or if the product produces unsupported conclusions in high-consequence cases. A distribution claim might weaken if most inquiries fall outside the intended segment. Establish a budget and stop date so uncertainty does not become an excuse for indefinite spending.
Do not let the team that built the feature define every evaluation outcome after seeing the results. Use independently established answers where possible, preserve cases that were not used for development, and record exclusions. A result may support a narrow claim for one input family while rejecting the broader marketing promise. Preserve that distinction. A useful local finding is better than an unsupported universal conclusion.
The decision after the challenge can be invest, narrow, maintain, or stop. Investment is appropriate when the mechanism delivers value, appears costly to reproduce under the named scenario, and supports viable maintenance economics. Narrowing can preserve a useful advantage for a smaller buyer group. Maintenance can be sufficient when growth would exceed support capacity. Stopping is reasonable when the alleged defense adds cost without changing the customer’s choice.
What Would We Do at Salars?
We would keep a proposed advantage register for any candidate app before describing it as defensible. Supplier Margin Guard, for example, remains a proposal, not an operating business with verified customers or outcomes. Its register would name a specific purchasing workflow, a credible existing alternative, the costly failure it seeks to prevent, and the evidence needed to justify claims about speed, accuracy, or adoption.
We would first test a narrow combination: permissioned inputs, a transparent comparison, an unresolved-case queue, and a dependable human review path. We would not assume that model selection or a collection of supplier documents establishes a moat. The proposal would need to show why a buyer prefers the whole service and what maintaining that preference costs. Cases used for improvement would require documented allowed uses and a retention policy suited to the purpose.
A monthly review would ask what the buyer can now obtain elsewhere, which external dependency changed, and whether the strongest claim still has supporting evidence. If a platform supplies the core function adequately, we would consider narrowing the product or integrating with that platform rather than insisting on an obsolete differentiation story. We would carry verified findings into the product decision and leave untested assumptions visibly untested.
The practical goal would be a business that continues to earn preference through a maintained outcome. That can include defensible workflow knowledge, a relevant route to buyers, and reliable commitments. It may also include valuable code. We would fund the combination only when evidence shows that it serves customers and leaves enough resources to keep serving them responsibly.
Sources
- NIST AI Risk Management Framework: voluntary framework and current revision/concept-note status, checked October 7, 2026.
- ICO data protection principles: UK-context principles relevant to evaluating a proposed data asset; jurisdiction and use require separate assessment.
The rival scenarios, advantage register, financial example, and proposed Salars tests are original decision exercises. They are not reported experiments, legal determinations, or measured commercial results.
Loading comments…