Specialist vs Generalist: The Domain Tax

Should we use a frontier general-purpose model via a hosted API, or build our own specialist? The frontier model has more capability today; the specialist has structural advantages that compound over years. This chapter is the disciplined analysis of when each is the right answer. The decision has four axes. Most discussions consider one and conclude prematurely.

Figure 1. Concept map for this episode: fight, desk translation, what to lock.

The build-vs-buy decision: four axes

The decision has four axes. Most discussions consider one and conclude prematurely. Axis 1: Cost at scale. A platform that issues 5,000 LLM calls per day at hosted-API prices pays a four-figure monthly bill. The same platform, self-hosting, pays the electricity and one-time GPU amortisation. Cross-over happens around a few hundred to a few thousand calls per day, depending on call complexity - below that, hosted is cheaper; above it, self-hosted is dramatically cheaper. Axis 2: Data sovereignty. Every hosted-API call sends prompt content to a third party. For platforms whose prompts contain user-identifying queries, position data, or proprietary analytics - finance is a textbook example - the sovereignty cost is non-monetary and often non-negotiable.

The structural moat of a proprietary corpus

The strongest argument for the specialist is rarely made cleanly: a fine-tune trained on your corpus is something no competitor can replicate, regardless of how much compute they have. Every platform that runs in production generates a corpus that is uniquely its own - production traces, user feedback, post-mortems, edge-case handling. This corpus is small compared to the public training data of frontier models but is uncorrelated with it. The fine-tune learns patterns that exist nowhere else. A competitor with ten times the compute and ten times the talent cannot replicate this corpus - they could buy the same base model, the same training infrastructure, the same talent, but they cannot buy what your platform's own interactions have generated. The moat is structural: it widens as the platform runs, regardless of any competitive action.

Apache-first licensing posture

A specialist programme is a long bet on an open-weight ecosystem. The bet pays off only if the bases remain redistributable. A discipline of Apache-first - every base model in the stack must carry Apache 2.0 or MIT - protects the long bet from licensing surprises. The discipline rejects bases that look attractive on capability but carry restrictive licenses (Llama's permissive-but-not-Apache license, Mistral's custom license, any "research only" base). The cost is occasionally giving up a few points of capability on a benchmark. The benefit is that every component of the stack can be shipped, audited, and modified without legal review. A single non-permissive base contaminates the whole stack - a LoRA adapter trained on a restrictive base inherits the restriction, a fine-tune that merges the adapter inherits it too, and so does anything distilled from that fine-tune. There is no clean exit from license contamination after the fact.

The economic case for narrow specialisation

Even within the self-hosted choice, there is a further decision: should the specialist be broad (a 70B model that does many things adequately) or narrow (a 7B model fine-tuned to do one domain very well)? The narrow specialist wins on every axis that matters for production: latency (a 7B model serves in milliseconds, a 70B model in seconds), cost (a 7B model fits one consumer GPU, a 70B model needs multiple data-centre GPUs), customisation (a 7B model can be fully fine-tuned on a single GPU), and iteration speed (a 7B model retrains in hours, not days).