
Marc H.,
Too Long; Didn't Read
The build-vs-buy-vs-outsource decision almost never fails because of the wrong choice, but because of the missing process. 71% of internal builds are abandoned, hidden buy costs double the license price, and outsourcing rarely delivers the promised savings. The way out: don’t decide based on price or demo excitement, but on a 5-year total cost of ownership with a clear exit strategy.

Last week I sat down with a CIO. Third ERP module in four years. First built in-house: the team couldn’t deliver. Then bought: the vendor failed to implement half the promised features. Now outsourced, and the costs are spiraling out of control.
His conclusion: "Every option was wrong."
My conclusion: The options were not the problem. The decision-making process was.
Why all three options fail (when the process is missing)
The decision between Build, Buy, and Outsource follows a predictable pattern.
The Build scenario: The development team is excited. "We can do this ourselves, better and cheaper." Six months later, the scope has tripled, the budget is exhausted, and maintenance is consuming every spare capacity.
According to the Exclaimer Report 2025 (surveying more than 2,000 IT decision-makers): 71% of internal IT builds are eventually abandoned. Only 8% are completed on time. Only 11% stay within budget.
The Buy scenario: The demo was impressive. The price seemed fair. Then integration begins, and suddenly the project costs 150-200% more than the license fee. Training, customization, interfaces: the sticker price was only 40-60% of the actual costs.
The Outsource scenario: "We’ll outsource it and save 30%." Sounds logical. But hidden costs eat up to 20% of the outsourcing budget. Scope creep, contract changes, currency fluctuations. And the promised flexibility? You only get that if you have the right contract clauses from the start.

Figure: The three options promise a lot, but each has a hidden price
The real problem sits further upstream
The problem is not Build vs Buy vs Outsource. The problem is how the decision is made.
Five patterns explain almost every bad decision:
1. Demo-driven enthusiasm. Someone sees an impressive product demo. The team is convinced. The purchase is approved without modeling integration, maintenance, or long-term costs. Twelve months later, reality looks different.
2. The Not-Invented-Here effect. The technical team wants to build everything themselves. "We know our requirements best." Often true. But there are mature open-source solutions with hundreds of contributors and years of lead time.
3. Price instead of TCO. The cheapest option wins. But the first 12 months are misleading. The true costs appear in years 2-5: maintenance, updates, training, integration, exit. Forrester estimates that 80% of total software costs occur after the initial launch.
4. No exit strategy. You buy a tool, integrate it deeply into your processes, and have no plan for the case where the vendor doubles the prices. The 9.3% average SaaS price increase in 2024 says hello.
5. Emotion beats methodology. The CEO saw something at a conference. The CTO wants to build. The CFO wants the cheapest option. No structured evaluation, no weighted criteria, no shared decision framework.

Figure: On the left, the typical decision path; on the right, the structured approach
The question you should ask instead
Not: "Should we build, buy, or outsource?"
But: "What is this capability strategically worth, and what dependencies can we afford?"
Six questions prevent the majority of bad decisions:
Is this a competitive advantage? If yes: Build or Operate (run open source yourself). If no: Buy or Outsource, without a bad conscience.
Do we have the functional expertise now? Not technical skills. Functional domain knowledge. Does someone on the team understand the problem well enough to specify a solution?
Is there a mature open-source alternative? Keycloak for identity, PostgreSQL for databases, Kafka for messaging. These projects have years of lead time. Building it yourself here is a waste.
What is the 5-year TCO, honestly calculated? Not the license price. Everything: integration, maintenance, training, opportunity cost, exit.
How high is the acceptable dependency risk? Every vendor creates dependency. The question is not whether, but how much, and whether there is an exit path.
How urgent is the solution really? Buy needs 2-8 weeks for integration. Build needs 6-18 months. Sometimes speed is the decisive factor.

Figure: The six questions as a decision framework
The elephant in the room: AI is changing the equation
What most Build-vs-Buy discussions ignore: AI is shifting the rules on both sides.
Build is getting cheaper. AI-assisted development lowers the cost of custom software. What was a 12-month project two years ago can now be prototyped in weeks.
But Buy is becoming "stickier". AI platforms create new lock-in. Anyone who trains their processes on an AI solution faces high switching costs. The next generation of vendor dependency is called AI lock-in.
According to Deloitte, 83% of executives already use AI as part of their outsourced services. At the same time, the concrete benefits remain limited because governance and contract design for AI requirements are not yet mature.
Anyone making a sourcing decision in 2026 without factoring in AI is working with an outdated map.
The honest question
You are facing a Build-vs-Buy-vs-Outsource decision? Answer one question: Have you analyzed the decision, or have you reacted to a demo, a price, or a gut feeling?
If it’s the latter, you are in good company. But also in the company of those who will switch again in two years.
We help Swiss companies make these decisions in a structured and vendor-neutral way. Not because we have better answers, but because we ask better questions. Sourcing consulting →


