Defensibility is how hard it is for a competitor to take your customers once they decide to try. You measure it by what the attacker must spend: money, time, or access it cannot buy. A product any developer can rebuild in three weeks has low defensibility, however good it looks.
Defensibility and moat describe one idea from two sides. A moat is the structure. Defensibility is the practical difficulty a competitor meets when it tries to pull a specific customer away. You test it customer by customer, not market by market.
An example. You sell bookkeeping software to 900 small firms, and each account holds three years of categorised transactions. Switching means exporting, re-importing, and re-checking that history. Budget eight hours of an accountant's time at 65 euros an hour, and the move costs that customer 520 euros. A rival charging 29 euros a month would have to give roughly 18 months free just to cover it, because 18 times 29 is 522 euros. That is defensibility you can put a figure on.
Sources include data that exists only because the customer used your product, integrations into systems they depend on, contracts, regulatory approvals, and distribution a competitor cannot buy access to.
The misunderstanding is equating defensibility with secrecy. Hiding your code protects little, because competitors copy the visible product, not the implementation. A second misunderstanding is timing: many founders write about defensibility as if it already exists at launch. On day one, almost nothing is defensible.
Foundor's generated plan raises defensibility in the competition section. The answer that holds up is specific: name what accumulates in your business over time, and what a competitor would have to spend to catch up.
