--- title: "Make or buy for AI solutions: A decision guide for mid-sized companies" lang: en type: blog canonical: https://www.arocom.de/en/blog/make-or-buy-ai alternate: https://www.arocom.de/blog/make-or-buy-ki-loesungen author: "Axel Roth" published: 2026-04-28 last_updated: 2026-10-31 --- # Make or buy for AI solutions: A decision guide for mid-sized companies Whether a company buys AI features as a finished product or has them built individually comes down to four criteria: does the feature differentiate the company from competitors, how sensitive is the data, how deep must the integration into existing systems reach, and how long should the solution live. Buying wins for standard tasks, building wins for differentiating core processes. The most successful pattern in practice is a hybrid: rent standard models, own the integration layer built on open standards. A worked three-year calculation and a five-question checklist make the decision computable. ## Make or buy for AI solutions: A decision guide for mid-sized companies This question now reaches us weekly, in two variants. Variant one: "There are ready-made tools for this, why should we have anything built?" Variant two: "We don't want to be dependent, can't you build this for us?" Both reflexes are understandable, and both lead into expensive dead ends without proper examination. With AI, the question carries more weight than with classic software. The tools evolve faster, vendor pricing models are young and volatile, and the solution often carries exactly the data that makes up your business. A wrong decision here does not quietly correct itself in the budget, it grows with you. Four criteria bring order into the decision. ## The four criteria **1. Differentiation.** Does the AI feature handle something your competitors need in exactly the same way (summarising minutes, pre-sorting emails)? Then buy. Does it embody what sets you apart from competitors (your consulting logic, your pricing, your service process)? Then the logic belongs in your hands. An example: a technical wholesaler whose strength is fast, reliable quote calculation buys the minutes AI off the shelf and has the calculation assistant built individually. The other way round would be expensively wrong. **2. Data sovereignty.** The more sensitive the data (customer records, calculations, health data), the stronger the case for your own infrastructure, or at least European providers with clear contracts. A standard SaaS with US data processing is simply ruled out for some industries. An example: a supplier managing customer drawings under NDA must not load them into an arbitrary cloud tool. Here the NDA annex decides the architecture, not the feature set. **3. Integration depth.** A tool that works on its own can be rented without risk. A feature meant to reach deep into CRM, ERP or CMS becomes a permanent construction site as a third-party product. A rule of thumb from our projects: from the second system interface onwards, it pays to look at owning the integration layer. A typical pattern: the off-the-shelf service chatbot convinces in the demo, and after the vendor's second release change the ERP connection breaks and nobody in-house can repair it. **4. Lifespan.** For a year of bridging, you rent. For a process meant to carry the company for ten years, building pays off faster than the monthly rates suggest. An example: renting a document tool until the planned ERP migration is sensible. Building the quoting process that carries the business for the next decade on a cancellable subscription is not. ## The honest cost comparison | | Buy (SaaS) | Build (custom) | | --- | --- | --- | | Initial costs | low (subscription, onboarding) | high (project) | | Running costs | grow with users/usage | operations + inference, largely independent of user count | | Adaptability | limited to the vendor roadmap | full, but every adaptation costs | | Dependency | price, feature and exit risk | dependency on the service provider (solvable by contract) | | Time to value | days to weeks | weeks to months | | Typical tipping point | recalculate from ~20–50 users or 2+ integrations | pays off over 3+ years of operation | The most common calculation error sits in the second row: SaaS prices apply per user per month and grow accordingly. Custom solutions cost up front and then scale at almost no extra cost. With AI there is one peculiarity on top: inference costs (what each request costs in model usage) arise in both models, but the SaaS vendor hides them in the price. A simplified example calculation over three years shows what that means in numbers. The values are a rounded illustration, not a quote. An AI assistant SaaS for 25 users at 40 euros per user per month costs 12,000 euros a year, 36,000 euros over three years, price increases and paid add-on modules not included. A custom solution with comparable scope sits, as an example, at 45,000 euros for the build plus around 6,000 euros per year for operations and model costs, so about 63,000 euros over three years. By this calculation the SaaS is ahead, and that is exactly as far as list prices carry. The calculation flips as soon as one of three factors occurs: the user count grows towards 50, the vendor raises prices, or a second integration arrives that costs consulting days on the SaaS side. From there, the custom build pays off more strongly year by year. That is why this calculation with your own numbers belongs in writing in every decision paper. Two items are missing from the list prices of both columns and still belong in your calculation: the rollout (training, process adaptation, internal testing) and the ongoing maintenance of prompts and configuration. Both occur whether you buy or build, and both get reliably talked down in vendor conversations. ## What wins in practice: three hybrid approaches The pure make-or-buy question is often the wrong question in 2026. In our projects, hybrid approaches win. Honestly, each of them has a spot where it can fail, so we name both: 1. **Rent the model, own the integration.** The language model comes via API from OpenAI, Anthropic or a European provider and stays replaceable. The integration layer (connecting CMS, CRM, knowledge base, ideally via open standards like [MCP](https://www.arocom.de/en/knowledge/ai/mcp)) belongs to you. This approach fails where the integration layer is built without documentation and tests, and thus hangs on a single person or agency after all. 2. **Standard tools for standard tasks, a custom solution for the core process.** Office copilots for emails and minutes are bought. The AI-supported quoting process that carries your business is built. We see this model fail where nobody maintains the boundary: standard tools creep into the core process until a cancellable subscription is suddenly business-critical. 3. **Buy with an exit plan.** Where SaaS wins, data export and a termination scenario belong in the contract before you sign. This fails when the exit exists only on paper. A data export nobody has ever test-restored is not one. ## Five questions before the first vendor conversation Answer these five questions in writing before you talk to vendors or service providers. In writing, because verbal answers become astonishingly flexible in a sales conversation: 1. Which task should the solution take over, and how do we measure after twelve months whether it does? 2. Does this task differentiate us from competitors, or do they handle it just the same? 3. Which data flows in, how sensitive is it, and where may it be processed? 4. How many existing systems must the solution talk to, today and in three years? 5. What happens at exit after two years: who owns the data, prompts and integration code then? Our advice for a first step: take your most important planned AI feature and answer the five questions this week. The result usually carries the make-or-buy decision on its own. If you want a second opinion along the way, that is exactly what the [Future Check](https://www.arocom.de/en/future-check) is for. ### Can we switch from buy to make later? Yes, and that is exactly what the exit plan is for. The switch becomes realistic if you secure three things from the start: regular data exports in an open format, documented processes (what exactly the tool does functionally) and no exclusivity clauses in the contract. The most frequent switching reasons we encounter in conversations are price increases and standstill on the vendor roadmap. Whoever has prepared the switch contractually negotiates from a different position then. ### How do we avoid service-provider lock-in when building? Contractually and technically. Contractually, source code, documentation and infrastructure access belong to you, settled before building starts, not as later bargaining material. Technically, open standards help (such as MCP for AI integrations), widespread frameworks instead of homegrown exotics, and documentation a second team could continue with. The test question for your provider is: "What would another team need to take this over?" The answer says more than any reference list. ### What if the vendor demands double tomorrow? With SaaS that is a real scenario, especially when AI features get priced in after the fact. You can protect yourself contractually with price commitments over the term and practically with an exit plan that is kept current and rehearsed once, because the best negotiating position is credible switchability. With a custom solution, the price risk only hits the model costs, and models are replaceable via a clean provider abstraction.