Custom AI Solutions: The Four Conditions

Search this and the answer you get is a balance. Here are the advantages of building, here are the advantages of buying, here is a paragraph recommending a hybrid, consider your unique business needs. Every page lands in the same place, which is no place, and the reason is structural: most of them are written by companies that would do the building.

A decision that comes out balanced every time is not a decision. So this page takes the other approach. Custom is the right answer under four specific conditions. Outside them, buying is cheaper, faster and less exposed, and the useful part of this question is being able to tell which side of that line you are on before anyone writes a proposal.

The four are not a scoring system and they are not weighted. One of them being clearly true is enough to justify building. None of them being true means the custom proposal in front of you is a more expensive route to something you can already buy.

Condition one: the capability is the product

If the thing the model does is what customers are paying you for, it cannot be a vendor's product on your invoice. Not because of quality, but because you cannot build a moat out of an API that your competitor can sign up for this afternoon.

The test is whether a customer would notice, and care, if you swapped the implementation for a competitor's. If the answer is no, this is infrastructure and you should buy the cheapest reliable version. If the answer is yes, you are looking at the one condition that genuinely cannot be outsourced, and the thing to protect is rarely the model anyway. It is the data you have and nobody else does, and the evaluation set that tells you whether a change made things better.

Most work that gets scoped as custom fails this test immediately. Support triage, document summarisation, meeting notes, lead scoring, first-draft content: all real, all valuable, none of them the product. Those are the cases where the market has already built what you were about to commission.

Condition two: the data cannot leave

Sometimes the constraint is not preference. Health records under a regulation with teeth, legal material under privilege, defence work, a contract that names where processing may happen, a customer whose own compliance team has to approve your subprocessors. In those cases the question of where inference runs is settled before anyone discusses features.

Be precise about which version you have, because the strong one is rarer than the conversation suggests. A written obligation about data residency or subprocessors is a hard constraint. Paid API terms now carry a contractual commitment not to train on what you send: Anthropic's commercial terms state plainly that Anthropic may not train models on customer content from the services, and that the customer retains all rights to its inputs. That alone satisfies a great many internal policies that sounded absolute when first stated.

What remains after that filter is the genuine case: the data physically may not reach a third party, so the model runs inside your boundary. That is a real reason to build, and it changes the shape of the cost rather than just the vendor, which the costing section below gets to.

Condition three: the workflow has no product-shaped equivalent

Packaged software encodes an assumption about how the work is done. When your process matches, you get years of somebody else's engineering for a subscription. When it does not, you get a tool everyone fights, and the fighting is invisible on the invoice.

The distinction worth drawing is between unusual and merely specific. A specific process is one the vendor's configuration can express: your fields, your stages, your approval rules. Unusual means the shape itself is different, which usually looks like one of a few patterns. Your data lives in a system the vendor has never integrated with and will not. The task requires a sequence of steps across several internal systems with your own rules deciding the order. Or the output has to land back inside a system of record that was written before anyone here had heard of a model.

Before accepting this one, do the boring check: take the top three vendors in the category and try to configure your actual process, with your actual data, in a trial. The number of custom projects that die once somebody does that is the main argument for doing it first.

Condition four: the volume has crossed over

This is the only condition that is arithmetic rather than judgement, and it is the one most often asserted without being calculated.

Per-seat and per-request pricing is a straight line. Your own deployment is a step: a fixed cost for the build, a fixed cost per month for the infrastructure and the person maintaining it, and a small cost per request on top. Below some volume the line is cheaper. Above it the step is. Everyone knows that in the abstract and almost nobody has found the crossing point for their own workload, which is a shame, because it is an afternoon of work and it frequently settles the whole argument.

Costing both sides against one workload

Here is how to do it properly. Take the workload you are actually arguing about, not a representative one, and get two numbers out of it.

Start with the per-request shape. Pull a realistic transcript from the task, including whatever context gets sent along with it, and count what one call really contains with a token counter. Then multiply it out at your expected volume in the LLM cost calculator. Two things usually surprise people here. The first is that a multi-step task resends its accumulated context on every step, because models are stateless underneath, so a late step costs a multiple of the first. The second is that the figure most people carry in their heads came from thinking about a single short message.

Then cost the other side on the same workload. Self-hosting a model means a machine with an accelerator attached, and that machine is billed whether or not a request arrives, which is the whole difference between the line and the step. Put the instance type and the hours you would actually run it through the AWS cost calculator, including storage and egress, and then add the parts that are not on the bill: the engineer who owns it, the on-call, and the model upgrade you will do in a year because the one you deployed stopped being state of the art.

Now you have two curves against one workload, and the crossover is a number rather than an opinion. Three results are common. It is far away, in which case buy and stop discussing it. It is close, in which case buy anyway, because the saving does not cover the risk of being wrong. Or you are already past it, which is the one case where the arithmetic has told you something, and it is worth noting that steady high volume is what gets you there, not peak volume, since idle accelerators are the expensive part of owning the step.

What the hybrid answer really means

Most pages recommend a mix and leave it there, which is unhelpful, because a mix can mean two very different things.

The useful version is a split by component. Buy the commodity parts of the pipeline and build only the piece that is yours. In practice that means using a provider's model through its API, and keeping your data preparation, your retrieval, your evaluation set and your orchestration as your own code. That split costs very little, keeps the provider replaceable, and means switching models later is a configuration change rather than a project.

The version to avoid is building a thin layer over an API and calling it a custom solution. If the only thing between your users and a provider is some prompt text and a web form, you have bought the capability and paid build prices for the wrapper. That is the most common shape of a disappointing custom AI project, and it is usually visible in the proposal if you ask what happens when the underlying model changes.

The fifth answer nobody in this market offers

Wait. Not forever, and not as an evasion, but as a position with a clear exit condition.

A capability that is novel and expensive this quarter has a way of arriving as a feature in software you already pay for. If what you want is on the obvious roadmap of a vendor you already use, commissioning it yourself buys you a few months of advantage and leaves you maintaining something that later ships for free. The right move then is to write down the condition under which you would stop waiting, with a date on it, so that waiting stays a decision rather than becoming a habit.

The other answer nobody offers is smaller. Build the narrowest version that touches real users, instrument it, and let a month of actual traffic answer the questions that the proposal was guessing at: what people really ask, how often it is wrong, and what the volume is. A month of that settles arguments no amount of strategy work can, and it is considerably cheaper than either option you were choosing between. Our writing on what AI strategy consulting is supposed to produce covers the decisions worth having settled before you get there, and the piece on what AI integration services do not quote covers the costs that land after the build is signed off.

Questions for whoever is proposing the build

Ask which of the four conditions applies, by name, and listen for whether the answer is a condition or an enthusiasm.

Ask what the crossover volume is for your workload, and what it was calculated from. An answer that does not include the cost of an idle accelerator has not been calculated.

Ask what stays yours. The data, the evaluation set and the orchestration should. If the answer is that the model weights stay yours, ask who is upgrading them next year and out of whose budget.

Ask which three products they evaluated first, and what specifically failed. A proposal that cannot name the alternatives it beat has not been compared with anything.

Ask what would make them tell you to buy instead. Everyone building should have an answer to that, and the ones who do are the ones worth working with.