# The best model is rarely the moat. Why I keep model providers replaceable and invest in context, workflow, evaluation, trust, and the speed of learning. - **Canonical URL:** https://vidhata.me/notes/the-best-model-is-rarely-the-moat - **Author:** Vidhatanand V. (Vid) - **Role:** Fractional CTO and AI Systems Architect **Published:** 01 Sep 2026 | **Reading time:** 9 minute read ## Why I hold this position Model progress is real, fast, and widely distributed. That is exactly why I am cautious about building a product identity around temporary access to one model. If competitors can call the same intelligence next week, the durable advantage has to live somewhere else. For me, the moat is usually the system around the model: proprietary context, operating data, workflow fit, evaluation, tools, trust, distribution, and the speed at which the product learns from real use. The model matters. It is simply not the whole product. ## I start with a capability, not a provider. A product needs capabilities such as classify intent, retrieve evidence, draft a response, transcribe speech, detect an object, or render an image. A provider supplies one implementation of that capability. When product logic, tool use, and provider-specific APIs are fused together, every model change becomes a product rewrite. I prefer typed capability contracts and adapters. The contract defines inputs, outputs, errors, budgets, latency expectations, and evaluation fixtures. Providers can then compete behind the boundary. This does not make switching free, but it keeps the cost visible and prevents a vendor response shape from becoming the architecture of the company. ## The right model depends on the workload. Leaderboard position is not an operating plan. A model that wins a broad benchmark may be too slow, expensive, memory-hungry, or inconsistent for the product path that matters. A smaller local model may be better for private classification. A cloud model may be justified for a difficult synthesis step. A deterministic method may outperform both when the problem is rules or geometry. I have used local model tiers, quantisation, reusable local APIs, and cloud escalation paths because workloads differ. The decision should consider quality, latency, memory, concurrency, privacy, cost, connectivity, and support. A model is selected for a job inside a system, not crowned in isolation. ## Evaluation belongs to the product team. Providers improve their models against broad targets. Your product has narrower promises. The evaluation set should reflect your users, edge cases, tools, data, and failure costs. It should include examples that look plausible but are wrong, because those are often the outputs most likely to escape casual review. Owning evaluation also changes vendor conversations. The team can compare providers against the same fixtures, measure regression, and decide when a cheaper or faster model is good enough. Without that discipline, model selection becomes a sequence of demos and opinions. ## The learning loop is more defensible than the model call. A product becomes difficult to copy when it understands the work better through use. It captures better context, preserves decisions, learns which recommendations were accepted, improves operator tools, and shortens the distance between failure and correction. Those assets compound even as models change. So I do not minimise model quality. I put it in proportion. Use the strongest suitable intelligence, but keep the product promise in your own contracts, evidence, workflow, and relationships. That is where technical choice turns into an advantage the next model release does not erase. ## What I take into the next build - Name product capabilities before selecting provider APIs. - Evaluate models against your workload, failure cost, and operating constraints. - Keep provider switching visible through adapters, budgets, and fixtures. - Invest in the context and learning loop that compound through real use. ## Continue reading [All Fractional CTO field notes](https://vidhata.me/notes) ## Work with Vid Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).