Why Almost Every Published Answer Is Wrong on Purpose

Search build versus buy for AI and you will find two kinds of page. Software vendors publish a version where buying wins, because the total cost of ownership model conveniently omits the integration work and the per-seat escalation. Development firms publish a version where building wins, because differentiation and control are presented as though they always outweigh two years of maintenance. Neither is dishonest exactly. Both are written by people whose revenue depends on one answer, and both are read by buyers who can tell. The result is that the most commercially important decision in an AI programme is discussed almost entirely in bad faith.

We should be clear about our own position. HatsonTech is a build shop. We write custom software, we train and adapt models, we build retrieval systems, and we are paid when clients choose to build. That is exactly why this article is worth writing carefully: a framework that sometimes concludes buy is the only kind that is useful, and the branches below that end in buy something off the shelf and stop reading are meant literally. If your situation lands there, taking that advice will save you between three and twelve months.

The framework has six axes, and the honest version of the decision weighs all six rather than arguing from one. Is the capability a differentiator or a commodity. Where does the data already live. How deep is the integration. What do the regulators require and where may processing happen. What does each option cost over three years including escalation. And how expensive is it to change your mind later. None of these is decisive alone, but together they are usually unambiguous, and most of the ambiguity people feel comes from having considered only two of them.

One preliminary: get the cost model right before you score anything, because most build-versus-buy arguments are actually arguments about incomparable numbers. A build quote is usually a one-time figure while a licence is an annual one, and neither normally includes the operational run-rate. We set out the full spend structure, including the annual run-rate that both options carry, in what an AI project actually costs. Bring both options onto a three-year total and the conversation gets considerably shorter.

Axis One: Is the Capability a Differentiator or a Commodity

The first question is not technical. Does this capability change how you win business, or is it plumbing that every competitor also needs. Meeting transcription is plumbing. Grammar checking is plumbing. Generic document summarisation over public material is plumbing. Extraction of the twelve specific clauses that determine risk in your industry's contracts, scored against your firm's own risk appetite, is not plumbing, and no product will ever do it the way you need because the vendor's market is everyone rather than you. That distinction survives every change in model capability.

A useful test: write down what the capability would have to get wrong for a customer to notice and care. If the answer is nothing much, it is a commodity and you should buy the cheapest adequate option and spend the saved attention elsewhere. If the answer involves your specific domain knowledge, your specific document types, your specific decision rules, or a judgement your senior people currently make by hand, then a general-purpose product will get you to roughly 60 to 75 percent of the value and stop, and the remaining part is where the case for building lives.

Be honest about the middle, because that is where most real cases sit. A support assistant that answers from your own product documentation is not a differentiator in the abstract, but it becomes one when the documentation is 40,000 pages of regulated technical material in Turkish that no vendor has indexed. The capability is commodity; the corpus is not. That is a signal for the hybrid answer discussed further down rather than for either extreme. For the wider framing of which capabilities are worth pursuing at all, see our overview of AI for business.

Axis Two: Data Gravity and Where the Data Already Lives

Data has gravity. Whatever platform already holds most of your relevant data has a structural cost advantage in serving AI features over it, because the hardest part of any AI project is getting the data into a usable, permissioned, up-to-date state. If 80 percent or more of what the system must read already sits inside one vendor's product, and that vendor sells an AI module over it, that module starts with an advantage worth roughly the entire data engineering line of a custom build. That is a large head start and it should be weighed accordingly.

The picture inverts when the data is spread. If the relevant material sits across three or more systems, none of which belongs to the vendor whose module you are considering, then buying that module means building an integration and synchronisation layer anyway, and you will have paid a licence for the privilege. In our experience this is the single most common mistake in the buy direction: a product is chosen for its interface, and the customer then spends 8 to 20 person-weeks feeding it data from systems it was never designed to read.

There is a second gravity effect that people miss, which is where the data may be allowed to go. If the corpus cannot leave your network, a large share of the market disappears from consideration immediately, regardless of how good the products are, and the comparison becomes between a much smaller set of deployable products and a custom build. Establish this constraint before you shortlist anything. It is not unusual for a six-week product evaluation to end when someone finally reads the hosting terms.

Practically, measure gravity before you argue about it. Count where the documents actually are, in what volume, in what format, and how each system can be read. Then count how much of the total corpus each candidate approach can reach without new engineering. That number is more predictive than any feature comparison, and it is the same inventory you need before building anything, which is why we treat it as step one in preparing data for an AI project.

Axis Three: Integration Depth

A tool that people open in a browser and use on its own terms is cheap to adopt and easy to abandon. A capability that must sit inside an existing workflow, reading from and writing to systems of record, respecting entitlements, and appearing where people already work, is a different proposition. The deeper the required integration, the weaker the advantage of buying, because the integration effort is roughly constant across both options while only one of them also carries a licence fee.

Use write access as the dividing line. Read-only assistance is comparatively easy to buy: point a product at some content, let people ask questions, accept that it is a separate window. Anything that writes back into an ERP, updates a case record, triggers a workflow or files a document requires approval flows, reversibility, audit trails and a security review, and most off-the-shelf products expose only a partial version of what you need. As a planning figure we count 3 to 6 person-weeks per system either way, which means a four-system integration erases most plausible licence savings on its own.

There is a milder version of this axis worth checking: how much of the user's actual task the product covers. A product that handles the retrieval and the answer but not the four steps after it leaves the workflow half-automated, and half-automated workflows frequently deliver no measurable saving at all because the human still has to open everything. Map the whole task before comparing tools, using the same discipline described in how to scope an AI project, and score products against the end-to-end task rather than the demo.

Axis Four: Regulatory Constraints and Where Processing May Happen

Regulation rarely decides build versus buy on its own, but it eliminates options faster than any other axis. In Türkiye there is no dedicated AI law in force; the constraints come from existing instruments, principally Law No. 6698, together with the Turkish Penal Code, Law No. 5651 and the Turkish Commercial Code. What that means in practice is that the lawful basis under articles 5 and 6, the duty to inform under article 10, the right in article 11(g) not to be subject to a decision produced solely by automated processing, and the security obligations of article 12 all apply to whatever you choose, bought or built.

The KVKK has published guidance relevant to this decision, including its generative AI guide, listed on its Rehberler index, and a document on Etken Yapay Zekâ, its own term for agentic AI, published on 12 March 2026. Both are guidance rather than binding regulation, but both give a clear sense of what a regulator expects you to be able to explain about your system. A bought product can satisfy these requirements, but only if the vendor will tell you what you need to know, which is a contractual question rather than a technical one.

For organisations with EU exposure, the AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and became applicable on 2 August 2026. Following Regulation (EU) 2026/1744 of 8 July 2026, the Annex III standalone high-risk categories apply from 2 December 2027 and the Annex I product-embedded categories from 2 August 2028, while the Article 50 transparency obligations took effect on 2 August 2026 as scheduled. Several widely circulated compliance pages still say high-risk rules apply in full from August 2026; the European Commission's regulatory framework page is the reference to check against.

The practical consequence for this decision is narrow but sharp. If your workload lands in a high-risk category or touches special-category personal data, you will need documentation, logging, oversight design and testing evidence that you can produce on demand. Buying is fine if the vendor contractually supplies those artefacts; buying is a serious problem if they will not name their models or sub-processors. If the data cannot leave your network at all, the realistic options narrow to self-hosted products and custom builds, which we cover in on-premise and sovereign AI.

Axis Five: What Each Option Actually Costs Over Three Years

Compare three-year totals or do not compare at all. On the buy side, start from the per-seat licence. Our planning band for a serious enterprise AI product is roughly USD 20 to 80 per user per month, which at 120 seats is USD 28,800 to 115,200 a year, roughly TL 1.2 to 4.8 million. These are planning bands we own rather than quoted market rates, and the lira figures track the exchange rate. Then add the two things that are always underestimated: escalation and seat creep.

Escalation is real and rarely negotiated well. A reasonable planning assumption is 8 to 15 percent at each renewal, and separately 10 to 20 percent annual growth in seat count as the tool succeeds and more people want it. Compounded over three years, a 120-seat deployment at the middle of the band lands materially above the naive figure of three times year one. Add first-year professional services, which we plan at 15 to 40 percent of the first-year licence, and premium-tier charges for the things enterprises always end up needing, such as single sign-on, audit logging, data residency and an API.

On the build side, the three-year total is the build cost plus run-rate. Take a mid-size build at USD 60,000 to 130,000, add annual run-rate at 20 to 35 percent of build cost covering inference, hosting, human review, re-evaluation and maintenance, and a three-year total lands roughly at USD 96,000 to 267,000, or TL 4.0 to 11.2 million. The distribution matters as much as the total: building is front-loaded and then flat, buying is level and then rises. Which shape suits you is a real question and not only a finance one.

The crossover in our experience sits somewhere between 80 and 200 seats for a well-defined workflow, and below roughly 60 seats buying nearly always wins on cost alone. But cost should never be the only axis, because the cheapest three-year total for a capability that is genuinely a differentiator is still the wrong answer. Build the comparison, then read it alongside the other five axes rather than instead of them, and measure the result afterwards using the approach in measuring AI return on investment.

Axis Six: Switching Cost and Lock-In

Every option locks you in somehow; the question is how expensive it is to change your mind in year two. For a bought product, the exposure is concentrated in things you cannot take with you: the tuning you did inside the vendor's interface, the prompt library, the feedback you generated that improved their system rather than yours, the conversation history, and the embeddings you paid to compute. Ask before signing whether you can export all of those in an open format, and treat a vague answer as a specific answer.

For a build, the lock-in is different but not absent. You are exposed to the model provider you chose, to the frameworks in your stack, and above all to the small number of people who understand the system. That last one is the most underrated risk in the build direction, and it is mitigated by ordinary engineering discipline: documentation, an evaluation harness anyone can run, infrastructure as code, and a rule that no component may have exactly one person who understands it.

A practical way to score this axis is to write the exit plan before you commit, for both options, and count the weeks. For a bought product, how long to migrate away and what exactly would you lose. For a build, how long for a new team to become productive and what would they need. If either answer exceeds a quarter of a year, that is a real cost that belongs in the comparison. The same thinking applies to architectural choices inside a build, which is why we compare the durability of different approaches in RAG versus fine-tuning.

The Hybrid Middle: Buy the Platform, Build the Domain Layer

Most good answers are not at either end. The pattern that works most reliably is to buy the commodity infrastructure and build only the thin layer that encodes what makes your organisation different. Buy the vector database, the model access, the observability tooling, the document conversion service and the authentication. Build the chunking strategy that respects your document structure, the retrieval logic that understands your entity model, the domain prompts, the evaluation set, and the workflow integration. The bought parts are the ones a vendor can genuinely do better than you.

This shape has a specific economic property worth naming: it puts your money into the assets that keep their value. Your golden dataset, your labelled examples, your evaluation harness and your domain logic all survive a change of model, a change of vector database and a change of framework. Infrastructure you rented does not need to survive. Teams that get this the wrong way round spend heavily on infrastructure they could have rented and then have nothing durable when the vendor landscape shifts, which it does roughly annually.

The hybrid answer also changes what a good vendor relationship looks like. Instead of one supplier owning the outcome, you own the outcome and buy components, which means you need clearer interfaces and a modest amount of in-house capability to hold it together. That is typically one technically literate product owner and access to engineering, not a research team. If you cannot staff even that, the honest conclusion is closer to buy than to build, regardless of what the other axes say.

One caution: hybrid is not an excuse to avoid deciding. We have seen programmes that bought three platforms and built a thin layer over each, producing the cost of buying and the maintenance burden of building at once. The discipline is to name exactly one layer that is yours and to keep everything else replaceable. If you are unsure whether your domain layer is real or imaginary, a short pilot answers it faster than a strategy document, provided the pilot is run against the exit criteria in why AI pilots never reach production.

A Scored Rubric You Can Actually Fill In

Score each of the following from 0 to 5, where 5 means the statement is strongly true. Differentiation, weight 25: this capability changes how we win, and doing it better than competitors matters. Data gravity, weight 15: the relevant data is spread across systems that no single vendor owns. Integration depth, weight 15: the capability must read from and write to our systems of record. Regulatory constraint, weight 15: our data cannot leave our network, or we must produce documentation no vendor will contractually supply.

Three-year cost, weight 15: building is cheaper than buying over three years on our own seat count and escalation assumptions. Switching cost, weight 10: the lock-in and exit cost of the bought option is high and the exit plan exceeds one quarter. Capacity to operate, weight 5: we can staff an owner and hold the operational burden. Multiply each score by its weight, sum, then divide by 5 to get a total out of 100. The arithmetic is deliberately simple so that the argument happens over the scores rather than the formula.

Read the result as follows. Under 35: buy something off the shelf, run a two-week evaluation of three products, and stop reading. Between 35 and 60: hybrid, meaning buy the platform and build the domain layer, and expect the domain layer to be smaller than you think. Over 60: build, and budget for the run-rate and the owner from day one. Score it twice, once with the sponsor and once with the people who will operate the result, and treat any criterion where the two scores differ by more than two points as the thing to investigate before anything else. Whichever branch you land on, the questions in how to choose an AI development partner apply to product vendors just as much as to development firms.

When We Tell Clients to Buy

We say buy more often than a build shop is supposed to. Meeting transcription and summarisation: buy. Generic translation and drafting assistance: buy. Standard OCR of common form types: buy, unless the forms are unusual or the volume is very large. Customer support deflection over public documentation with fewer than about sixty agents: buy. A first internal chat assistant intended mainly to build organisational familiarity: buy, use it for two quarters, and let the real requirements emerge from what people actually try to do with it.

We say build when the corpus is proprietary and messy, when the judgement being automated is one your senior people currently make by hand, when four systems must be tied together, when the data cannot leave your network, or when the workflow is the product rather than an accessory to it. Those are the cases where the last 25 to 40 percent of the value is only reachable with work nobody will do on your behalf. Our own products sit in that category, which is why they exist as products rather than as configurations of something we bought.

In practice we score the rubric with clients before quoting, and we have walked away from work on the strength of it more than once. If your score lands under 35 we will say so, and we would rather do that in week one than deliver a competent system that a product could have replaced for a third of the money. If it lands over 60, our custom software development practice will scope it line by line, in person-weeks before money, and will tell you which parts of the platform you should be renting rather than paying us to build.