AI & Product Engineering
If AI Can Rebuild Your App, What Is Your Moat?
A copied interface raises a useful product question: which parts of your advantage survive when implementing the visible features becomes easier?
Rommel Clarino 3 min read
At a glance
Separate the software someone can reproduce from the service customers depend on. Distribution, trusted operating history, useful information, and embedded workflows are candidates for durable advantage, but each needs evidence. A moat is a claim to examine through customer behavior, not a label to add to a pitch.
A short post leaves a large question open
On October 25, 2026, Jack Dorsey posted a short assertion about the absence of a moat. Michael Saylor replied by framing Bitcoin as one. The posts attracted a discussion about defensibility, but Dorsey's original message does not name an AI company or explain which market he meant. The question explored here is my interpretation of that opening, rather than a claim about his intent.
For a software builder, it is a useful question to ask even without the social debate: if another team could reproduce the visible application quickly, what would still make customers choose yours? The answer needs to survive a more demanding comparison than two screenshots.
jack (@jack) on X
The brief claim that prompted the discussion. The product argument below is independent analysis.
A feature and a functioning service have different boundaries
Imagine a fictional appointment product for a neighborhood clinic. A competitor reproduces its calendar, patient form, and confirmation screen. That is meaningful competitive pressure. It still leaves questions about importing existing records, handling scheduling exceptions, training staff, and supporting the clinic when a reminder fails.
Those responsibilities are opportunities to earn preference. They are not automatically defensible advantages. A competitor can improve its support or build integrations too. The useful exercise is to identify which part of the service customers demonstrably value and how difficult it would be to replace that part.
Ask for evidence behind each advantage
A defensibility worksheet should connect an asset to an observable reason that a customer chooses or stays with the service. The examples below are hypotheses to investigate, not facts about a particular company.
| Candidate advantage | Evidence to look for | What could weaken it |
|---|---|---|
| Distribution | Repeatable access to relevant customers | Dependence on one changing acquisition channel |
| Workflow integration | Users complete important work across connected systems | A replacement makes the same workflow easier |
| Trusted operation | Customers cite dependable service and response | Repeated failures or weak recovery |
| Useful information | Permissioned inputs improve a measured outcome | The same outcome is available from common inputs |
| Participation | The service becomes more useful through active participants | Users receive little value from the wider network |
Control of information should still respect the customer
In the clinic example, reliable exports and clear migration paths can support trust even though they reduce friction for leaving. Making the data difficult to retrieve may retain an account temporarily, but that is different from making the service worth renewing. Distinguish a costly exit from a strong reason to stay.
The same scrutiny applies to network arguments. Reproducing code does not by itself reproduce a network's participants, operating history, or economic relationships. Equally, invoking a network does not demonstrate that those relationships make a specific product more useful. Saylor's response raises a comparison; it does not resolve every security or product question about it.
Build where customers can notice the difference
Choose one frequently repeated customer task and ask what would make a substitute meaningfully worse. Then look for evidence: completion quality, operational reliability, time spent repairing mistakes, or a reason customers give when renewing. Keep implementation speed in the comparison, because a rival that ships useful improvements faster can change the answer.
My recommendation is to treat defensibility as a continuing product investigation. Improve the work customers depend on, measure the preference you believe you have earned, and revisit it as alternatives improve. The useful response to easier software reproduction is a more precise account of why your service deserves to exist.