Print the architecture diagram. Take a pen. Cross out the box in the middle, the one with the model provider’s name on it, and everything that connects directly to it.

Now look at what is left standing on the page.

That is the exercise, and it takes about four minutes. The first time we did it, the remaining diagram was noticeably thin, and there was a silence in the room that told me everybody had reached the same conclusion at the same speed.

Whatever survives that pen is the company. Whatever falls over was rented, and rented on terms set by somebody else.

What survives

Six things, in rough order of how hard they are to reproduce.

The data you accumulated by operating. Not licensed data, which your competitor can license too. The record of what your product suggested, what the user accepted, what they corrected it to, and what turned out to be right three weeks later. This exists only because you ran, it is impossible to buy, and it is the reason the same architecture in your hands and a competitor’s hands produce different products after eighteen months.

The integrations. Reaching into the systems where work already lives, reading real state, writing back correctly, handling the version of that system from four years ago that your customer still runs. It is slow, tedious, unrewarding work. It is a moat for exactly those reasons.

The evaluation harness and the golden set. This one surprises people, and it should not. That spreadsheet from yesterday encodes months of accumulated domain judgment about what a correct answer looks like in your specific field, contributed by practitioners, refined by incidents. A competitor with unlimited engineering cannot generate it. They have to earn it the same way you did, and it takes the same amount of time.

The workflow state. Approvals, audit trails, who saw what and when, what happens when the approver is away. This is the difference between a capability and something a business can actually operate, and it is the substance of what makes a product hard to remove.

The regulatory position. Certifications you hold, agreements you have signed, jurisdictions you can serve. These take months of elapsed time that cannot be compressed with money or effort. Tomorrow’s subject.

Cost engineering. A twenty point gross margin advantage over a competitor selling something similar is a strategic asset, not a finance detail. It lets you price lower, spend more on acquisition, or survive a downturn that removes them. Routing, caching and context discipline are not housekeeping. Compounded, they are a moat.

What does not survive

It is worth being blunt about the things founders describe as differentiation which are not.

Prompts. A prompt is copyable in one screenshot and can be obsoleted by one model update. Prompt engineering is a skill, and skills are not moats. If your defensibility discussion involves the phrase our prompts, there is no defensibility discussion.

Feature sets. Parity now takes weeks rather than quarters. A feature list is a snapshot of who shipped most recently.

Being early. Being early is a head start. Head starts are valuable and they expire. The question is what you converted the head start into while you had it, and for a lot of companies the honest answer is more features.

Your choice of model. Whatever you picked, your competitor can pick it too, this afternoon.

Design for portability, deliberately

The practical consequence is an abstraction layer between your application and whichever provider serves your inference. Not for architectural elegance. For three concrete reasons: you can move if pricing changes, you can route between tiers for margin as described in Lesson 7, and you can keep operating if a provider has an incident during your customer’s business hours.

There is a real cost and it should be stated rather than glossed. An abstraction that reduces every provider to a common denominator throws away the distinctive capabilities that made you choose one in the first place. Providers differentiate, and the differentiated parts are frequently the useful parts.

The rule I have settled on is to abstract the interface but not the capability. Standardize how you call, log, retry and measure, so that swapping is an engineering task rather than an archaeology project. Then, where a specific provider capability genuinely gives your product something, use it deliberately and write down what you would lose and what the fallback is. A dependency you have chosen and documented is a decision. A dependency you drifted into is a liability that surfaces during a pricing negotiation you did not expect to have.

The uncomfortable version of the exercise

Sometimes you cross out the box and very little remains. At month six that is completely normal and not a cause for alarm. You have not had time to accumulate anything yet.

At month thirty it is the most important fact about your company, and it will not be fixed by shipping faster.

The move is to treat the moat as a deliverable rather than a hope. Pick the two items from the surviving list that are most achievable in your situation, put them on the roadmap with dates and owners, and protect that work from the customer request that arrives on Thursday. Data capture is usually the cheapest and highest return, because it costs almost nothing to log and cannot be reconstructed retrospectively. Integrations are next, because they are pure elapsed time and the earlier you start the further ahead you are.

Nobody will ask you for this work. No customer will thank you for it. It is the difference between a company and a very good implementation.

Ask what you would have to rebuild if you switched model providers on Monday. Whatever is left is the company.

Tomorrow: the security questionnaire, and why trust has a lead time.