Custom AI model vs API: what UK startups should choose

Almost every AI product conversation we have with a UK founder arrives at the same fork within twenty minutes. Do we call somebody else’s model over an API, or do we build our own? The custom AI model vs API question sounds like an engineering detail. It is not. It sets your cost base, your gross margin, your fundraising story, and how defensible the company is three years out. Get it wrong in one direction and you burn eighteen months and a seed round training something that a five-line API call already does better. Get it wrong in the other and you ship a thin layer over a vendor who can delete your business with a pricing email. This is the honest version of that decision, written from projects we have actually shipped.

What custom AI model vs API really means

An API approach means you send a prompt to a model somebody else trained and hosts, and you pay per unit of text processed. A custom model means the weights are yours, whether you adapted an open-weight model to your data or trained something from scratch, and you run it on infrastructure you control. Everything else in this debate follows from that one difference: who owns the weights, and who pays for the compute.

That framing matters because the two are usually described as opposites when in practice they sit at opposite ends of a spectrum with several useful stops in between. Most of the AI products we build in 2026 land somewhere in the middle, and the founders who understand the middle make better decisions than the ones arguing about the two extremes.

The four options, not two

Hosted API. You call OpenAI, Anthropic, Google, or Mistral. No infrastructure, no machine learning team, best-in-class quality on general tasks from day one. You pay per token and you accept the vendor’s rate limits, terms, and roadmap.

API plus retrieval. The same hosted model, but you feed it your own documents and records at question time through a retrieval layer. This is the option that solves most problems founders think require a custom model. Your proprietary data shapes every answer, yet you never train anything.

Fine-tuned or adapted open-weight model. You take Llama, Mistral, Qwen, or similar, and you adapt it on your data using a technique such as LoRA. The weights are yours. You host it, typically on rented GPUs. This is what “custom model” means for roughly nine out of ten teams that genuinely need one.

Trained from scratch. You build a model from raw data with no pretrained base. Outside of a handful of well funded research-led companies, this is almost never the right call for a startup, and we have never once recommended it to a client.

When people argue about custom AI model vs API, they are usually imagining option one against option four. The real decision, most of the time, is between option two and option three.

When an API is the right answer

Start with the API. That is not a compromise position, it is the correct default for the large majority of AI products, and you should need a specific reason to leave it.

Use a hosted API when your product’s value is the workflow rather than the intelligence. If you are building a tool that reads contracts and pulls out renewal dates, the hard part is the ingestion, the review interface, the permissions model, and getting a legal team to trust the output. A frontier model already reads contracts better than anything you would train in your first year. Your moat is the workflow, the integrations, and the customer relationship, not the weights.

Use an API when your task is general language work. Summarising, drafting, classifying, extracting, translating, answering questions over documents you supply. General models are extraordinarily good at these, they improve every few months without you doing anything, and matching them with a small team is a losing race.

Use an API when you have no training data yet. This is the one founders most often talk themselves past. You cannot fine-tune your way out of having two hundred examples. Adapting a model meaningfully usually starts somewhere in the low thousands of well labelled examples, and the quality of the labels matters more than the quantity. If you are pre-launch, you do not have them. Ship on an API, collect real usage, and revisit in a year with data you actually earned.

Use an API when speed to market decides whether the company exists. An AI feature on a hosted model can be in front of users in weeks. The same feature on a self-hosted adapted model takes months and needs somebody on the team who has done it before. If you are racing to a funding milestone or a first ten customers, that gap is the whole game.

When a custom AI model earns its cost

There are real cases where a custom model is the correct answer, and they are more specific than most pitch decks suggest. In our experience four reasons hold up.

Your data is the product. If you have a proprietary dataset that nobody else can obtain, and the value of your product is a model that has genuinely internalised it, then the weights are the business. A company with a decade of specialist sensor readings, or claims histories, or annotated scans, is in a different position from a company with a clever prompt. If a competitor could reproduce your output by writing a better prompt against the same public model, you do not have a custom model case. You have a prompt.

The task is narrow, repetitive, and high volume. Frontier models are generalists, and you pay generalist prices on every single call. When you are running the same tightly defined classification millions of times a month, a much smaller adapted model can match or beat the big one on that one task while costing a fraction per call and responding faster. This is the most common genuinely sound reason we see. It is a unit-economics argument, not a capability argument.

Data cannot leave your infrastructure. Health, defence, legal, and parts of financial services sometimes have contractual or regulatory constraints that rule out sending data to a third-party endpoint, regardless of what the vendor’s terms say about training. Enterprise agreements and regional hosting solve this more often than founders assume, so test that first. When it genuinely cannot be solved, self-hosting an open-weight model is the way through.

Latency or offline operation is a hard requirement. A model that must run on a device, in a vehicle, on a factory floor, or with a strict response budget measured in tens of milliseconds, has to be small and local. That means your own weights.

Notice what is not on that list. “Our investors want AI IP” is not a reason. Neither is “the API is expensive”, until you have measured the bill and compared it against the fully loaded cost of running your own, which is the part of the custom AI model vs API comparison people get most wrong.

What each option costs in the UK in 2026

Here is what we see in practice across UK projects. These are Bluka build ranges, meaning the cost of designing, building, and shipping the AI portion of a product, not the whole app. Running costs are separate and depend entirely on volume.

Two things in that table surprise people.

The first is that retrieval is not cheap. Founders hear “we will just point it at our documents” and picture an afternoon’s work. Doing it properly means an ingestion pipeline, chunking decisions, an embedding strategy, a vector store, permissions so that user A never retrieves user B’s document, and a set of test cases so you can tell whether a change made answers better or worse. That last piece is the one skipped most often and the one that decides whether the product survives contact with real users.

The second is that self-hosting flips your cost curve rather than lowering it. API billing is variable and starts near zero, so it is cheap when you are small and grows with success. A self-hosted model means GPU capacity you pay for whether or not anybody uses the product that hour. At low volume that is far more expensive. There is a crossover point where the fixed cost becomes the cheaper option, and the entire economic case for a custom model rests on whether you will actually reach it. Model your volume honestly, including the possibility that you never get there, before you commit.

If you want the wider picture on what AI features cost to build, we broke the numbers down further in our guide to what it costs to add an AI chatbot to a UK app.

The hidden costs nobody prices in

Both paths carry bills that do not appear in anybody’s initial estimate.

On the API side, the surprise is usually the shape of the spend rather than the size. Retrieval-heavy products send far more text per request than founders expect, because every answer carries a stack of retrieved context. Agent-style features that loop, reason, and call tools can multiply the cost of a single user action several times over. And because billing scales with usage, a successful launch produces a bill that grows exactly as fast as your traffic. Put a spend cap and per-user rate limits in before launch, not after the first alarming invoice.

Vendor dependency is the other API cost, and it is strategic rather than financial. Prices change, models get deprecated, terms are revised, and a behaviour change in a model update can quietly break a prompt you tuned for months. The defence is cheap and worth doing on day one: keep your model calls behind a thin internal interface so switching provider is a configuration change rather than a rewrite, and keep an evaluation set you can run against any candidate model.

On the custom side, the hidden cost is people. Weights are not a one-off purchase. Somebody has to monitor quality, retrain as your data shifts, manage GPU capacity, handle incidents at three in the morning, and keep the serving stack patched. That is an ongoing salary line, and machine learning engineers are not cheap in London. Teams that budget for the training run and not the next three years of maintenance are the ones who end up quietly migrating back to an API eighteen months later, having spent the difference twice.

The third hidden cost applies to both and is the one we argue about most: evaluation. If you cannot measure whether your AI output is getting better or worse, you cannot improve it, and you cannot tell whether the expensive option is actually buying you anything. Building an evaluation set of real cases with known good answers is unglamorous, it is usually the first thing cut from scope, and it is the difference between a product that improves and one that just changes. We cover this and related traps in the AI development pitfalls UK founders hit.

Data, privacy, and UK regulation

Every founder asks whether their data trains the vendor’s next model. On the major business tiers the answer is no by default, and the terms say so, but read them for the product you are actually on rather than the one in the marketing page, because consumer and free tiers often differ from business ones. If your contracts with your own customers promise that their data stays in a given jurisdiction, check where the API endpoint you are calling actually runs, since regional hosting exists but is usually something you have to select rather than something you get automatically.

Under UK GDPR, sending personal data to a model provider makes that provider a processor and you the controller. You need a processing agreement, you need it recorded in your ROPA, and if the processing is high risk you need a DPIA before you launch rather than after. The ICO’s guidance on AI and data protection is the practical reference here and is written for people who are not lawyers. If your product serves EU users, the EU AI Act applies on top, with obligations that depend on how your system is classified, and transparency duties that catch a lot of ordinary consumer products.

Self-hosting removes the third-party transfer question entirely, which is genuinely simpler in regulated sectors. It does not remove your obligations. You still need a lawful basis, you still owe data subjects their rights over training data, and you are now also responsible for securing the infrastructure the model runs on. For the broader compliance picture on consumer products, see our guide to UK GDPR for consumer apps.

How we make this call with clients

We run the same sequence on every AI project, and it takes about a week rather than a quarter.

Define the task narrowly enough to test. Not “AI for customer support” but “classify an inbound email into one of nine categories and draft a reply for a human to approve.” Vague tasks cannot be evaluated, and unevaluated tasks cannot be decided on evidence.

Build an evaluation set before you build the feature. Fifty to two hundred real cases with agreed correct answers. This is the week that pays for itself several times over in an AI project, and the one clients most often want to skip.

Ship on a hosted API first, always. You will learn more from two weeks of real usage than from two months of planning, and the evaluation set tells you exactly how well the cheap option performs. Frequently it performs well enough that the conversation ends there, which saves everybody a great deal of money.

Measure the real bill at real volume. Not a spreadsheet estimate, the actual invoice from a month of genuine traffic. Then compare it against fully loaded self-hosting, GPU capacity plus the engineer who keeps it alive. If the API bill is not yet painful, you have your answer for another year.

Move to a custom model only when one of the four reasons applies and the numbers support it. When that day comes, move to an adapted open-weight model, not a from-scratch build, and keep the API path warm as a fallback while you prove the new one matches your evaluation scores.

That sequence has a useful property: every step produces something shippable, and no step commits you to the expensive path before you have evidence. If you are weighing this decision now and want a second opinion on which side of it you belong, tell us about your project and we will give you a straight answer, including when the answer is that you do not need us.

What to do next

If you are pre-launch with no training data, the decision is already made. Build on a hosted API, put your engineering effort into the workflow around the model, and keep your calls behind an interface you can swap. Revisit in twelve months with real usage data.

If you are live and the API bill is growing faster than revenue, you have a unit-economics problem rather than an architecture problem. Look first at prompt size, retrieval volume, caching, and whether a smaller model from the same vendor handles most of your traffic. Those changes routinely cut a bill substantially and take days rather than months.

If you are in a regulated sector, or your data genuinely is the product, or you run one narrow task at very high volume, then a custom model is likely correct. Budget for the people as well as the training, start from open weights, and hold yourself to matching your evaluation scores before you cut the API loose.

The custom AI model vs API question is worth taking seriously, and it is also worth not answering too early. Most companies that get this right did so by deferring the expensive decision until they had the evidence to make it cheaply. For the wider view on choosing a build partner for this kind of work, our guide to choosing an AI app development company in the UK covers what to ask and what should end the conversation.