Most build-vs-buy comparisons do the math cleanly — and miss precisely the axis on which the most expensive mistakes happen later. Build vs. buy is the question of whether you have software built for you (build = custom software) or purchase it ready-made (buy = off-the-shelf software/SaaS). Practically every framework decides this along three axes — cost, differentiation, time to market. The fourth is almost always missing: the law. Data sovereignty, vendor lock-in, and GDPR responsibility can hardly be corrected after the fact — unlike a price tag — and then cost a multiple. This article makes the fourth axis as concrete and decidable as the other three. (As of January 2026. Professional summary, not legal advice for the individual case.)
By Leon Lotz, business lawyer & developer.
What does build vs. buy mean for software?
“Build vs. buy” — often framed in the German mid-market as a make-or-buy decision or as a choice between custom and off-the-shelf software — describes two routes to the same function:
- Build = custom software, in-house development. You have a solution tailored exactly to your process. You own the code, the data, and the roadmap.
- Buy = off-the-shelf software, SaaS, COTS (commercial off-the-shelf). You rent or buy a finished solution shared by many customers. You adapt your process to the software.
Between the two lies a third, often overlooked option: partner / hybrid — buy what is common, build what is your own, and integrate the two cleanly. More on that below.
The familiar rule of thumb is: “Buy the common, build the unique.” It is correct — but incomplete. Because whether a solution is “common” is determined not only by its function, but also by who ultimately answers for your data.
The four decision axes — the framework
A sound decision stands on four legs. You know the first three from every guide. The fourth is the real lever — and it is executed cleanly in almost no comparison.
Axis 1: Strategic differentiation
The core question: Is this process your competitive advantage — or just a mandatory chore?
No one should build their own accounting or email software. These are solved problems; finished products are proven, cheaper, and better. Build only where your approach sets you apart from competitors — where an off-the-shelf solution would force you into someone else’s logic that you would have to keep adapting to indefinitely. Anyone who squeezes their core process into a standard tool pays for that compromise every working week.
Axis 2: Total cost of ownership (TCO)
The most common error in reasoning is comparing purchase prices. What matters is the total cost over three to five years.
With buy/SaaS, that means not only the license fees — which rise with every user and every pricing round — but also implementation, interfaces, training, and the creeping surcharge for modules you never originally needed.
With build, the bulk of the cost only comes after launch. As an industry benchmark, ongoing maintenance and further development run at roughly 15–20% of the original development cost per year — and considerably more for regulated or business-critical systems. Over the lifecycle, by far the larger share of total cost — in IEEE and industry analyses frequently 50–80% — falls on the phase after first delivery, not on development itself.
Key takeaway: The purchase price is the tip of the iceberg. The TCO is the rest.
These figures are orientation benchmarks from the industry, not guaranteed values for your project — the real range depends on complexity, regulation, and code quality.
The purchase price is visible; the total cost over three to five years is not. Across the lifecycle, the larger share lies below the waterline.
Axis 3: Time to market & in-house competence
Buy almost always wins on speed: a SaaS is productive tomorrow, an in-house build takes weeks to months. When the window of time decides business success, that is a strong argument for buying.
The counter-question concerns in-house competence: do you have the team to maintain an in-house build over years — or are you buying, with build, a permanent dependency on a service provider? Both are solvable (clean code, clear usage rights, documented handover), but it must be considered contractually from the very start.
Axis 4: Law, data protection & data sovereignty
This is where what no cost model captures is decided. SaaS lock-in and data outflow are not merely a business risk — they are a legal risk. Four points:
Data processing on your behalf (Art. 28 GDPR). As soon as a SaaS provider processes personal data on your behalf, a data processing agreement under Art. 28 GDPR is mandatory. You remain the controller — the obligation lies with you, not the provider. If the DPA is missing or incomplete, you face fines under Art. 83(4) GDPR of up to EUR 10 million or 2% of worldwide annual turnover. With an in-house build, you process the data yourself and can implement privacy by design (Art. 25 GDPR) from the very first line of code, rather than having to fight for it after the fact.
Vendor lock-in as a legal matter — the EU Data Act. Dependence on a cloud provider has recently become regulated. The EU Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025 and obliges providers of data processing services to grant effective switching and portability rights. The central lever: from 12 January 2027, switching charges are fully prohibited (until then, only cost-based charges, phased down, are permitted). Vendor lock-in is therefore no longer purely a matter of negotiation, but an enforceable right — one that you nonetheless need to be aware of and anchor contractually. How to avoid lock-in specifically with AI services, I cover in the article on AI vendor lock-in.
Third-country transfer — CLOUD Act vs. Art. 48 GDPR. Most large SaaS providers are US companies. The US CLOUD Act obliges them to hand over data when ordered to by US authorities — even when the servers are located in the EU. Art. 48 GDPR, however, prohibits exactly that, unless a mutual legal assistance treaty applies. This is a genuine, irresolvable conflict of norms: the European Data Protection Board considers disclosure on the basis of a US order alone to be inadmissible in principle. In practice, the transfer can be safeguarded through the EU-US Data Privacy Framework and standard contractual clauses — but the residual risk remains, and an EU server location under European control (or, indeed, the in-house build) is the more robust answer.
EU AI Act, if the software contains AI. If AI is part of the solution, deployer and provider obligations under the AI Regulation come into play as well. These obligations are no longer a distant prospect: the prohibitions on certain AI practices (Art. 5) have applied since 2 February 2025, and the obligations for general-purpose AI models since 2 August 2025. More on that in the article on the EU AI Act obligations for deployers.
Core point: With buy, you delegate the function — but not the responsibility. You remain the GDPR controller.
Build vs. buy: the decision matrix in direct comparison
| Criterion | Build (custom) | Buy (SaaS/off-the-shelf) | Partner / hybrid |
|---|---|---|---|
| Acquisition cost | high (project budget) | low (subscription/license) | medium |
| TCO over 3–5 years | predictable, declines proportionally | rises with users/pricing rounds | mixed, controllable |
| Time to market | slow (weeks–months) | very fast | medium |
| Process fit / adaptability | maximal (1:1 with the process) | limited (you adapt) | high in the core area |
| Scalability | depends on architecture | high, but license-coupled | high |
| Data sovereignty / privacy | full control, privacy by design (Art. 25) | depends on the provider | selectively controllable |
| Vendor lock-in / exit | low (own code) | high — Data Act eases it from 2027 | reduced |
| GDPR controllership | yours, technically implementable | yours, DPA under Art. 28 mandatory | yours, distributed contractually |
| Competitive advantage | high (differentiation) | low (everyone uses the same) | high in the core area |
The compliance rows — data sovereignty, lock-in/exit, GDPR controllership — are the ones missing from most comparison tables. They are often what tips the scale.
When build is the right choice
Building pays off when several of these points apply:
- The process is your competitive advantage — no standard tool maps it cleanly.
- You pay per user and the license costs scale uncomfortably with growth.
- You juggle several tools with manual bridges in between.
- Data protection or industry regulation demands full control over the data flows.
- You want data sovereignty and no dependence on a US provider and its pricing roadmap.
Typical scenarios: the specialized industry workflow tool, the platform with its own business model, the solution with especially sensitive data (health, client/attorney data, personal profiles).
When buy / SaaS is the right choice
Buying is superior when:
- It is a standard process (accounting, email, a common CRM, ticketing).
- Time to market decides success.
- You lack the team to maintain an in-house build.
- The function is not a differentiator and you process no special data.
- A provider with an EU server location, a DPA, and a clean exit is available.
The practical tip: even with buy, the DPA, the server location, and the exit clause belong before the signature — not in the middle of a crisis.
The third option: partner / hybrid
The most honest answer is often not an either/or decision. Buy 80–90% as standard, build the decisive 10–20% yourself, and integrate both through clean interfaces. That way you only pay custom-build costs where they secure your edge, and you draw on the market’s maturity for the rest.
Co-development (joint development with a service provider who transfers the rights to you) and managed services also fall under this heading. The hybrid route is usually the smartest one both economically and legally — provided the interfaces and data flows are thought through from the start. This exact cut — what is worth building, what to buy, and how the two interlock with legal certainty — is what I accompany in custom software development.
Decision checklist for the mid-market
To tick off before deciding:
- Is this process differentiation or a mandatory chore?
- TCO calculated over 3–5 years — not just acquisition?
- How critical is time to market really?
- Do we have the team for maintenance/further development (with build)?
- Is personal data processed → is a DPA under Art. 28 in place and complete?
- Server location and third-country transfer (CLOUD Act) checked?
- Exit strategy and data portability secured contractually (Data Act)?
- Does the solution contain AI → AI Act obligations clarified?
Anyone who can answer all eight has already made half the decision.
Conclusion: the decision belongs on four legs, not two
Build vs. buy is neither a pure cost calculation nor a pure question of speed. Anyone who weighs only cost, differentiation, and time to market overlooks the axis on which the most expensive mistakes happen: the law. Data sovereignty, vendor lock-in, and GDPR responsibility all weigh in — and, unlike the purchase price, they can hardly be corrected after the fact. The best choice is often hybrid: buy the common, build the unique — and underpin both with a sound legal foundation.
Frequently asked questions (FAQ)
What does build vs. buy (make or buy) mean for software? Build means having software developed individually; buy means purchasing a finished off-the-shelf or SaaS solution. In the German mid-market this is often framed as a make-or-buy decision or as a choice between custom and off-the-shelf software. A third option is the hybrid partner route.
When is custom software (build) worth it? When the process is your competitive advantage, no standard tool maps it, license costs scale uncomfortably, or data protection and regulation demand full control over the data flows. Rule of thumb: build the unique, buy the common.
What does custom software vs. SaaS cost — and what are the hidden costs? What matters is the TCO over 3–5 years, not the purchase price. With build, the bulk comes after launch — as a benchmark, 15–20% of development cost per year for maintenance. With SaaS, license costs rise with user numbers and pricing rounds, on top of implementation and interfaces.
Do I need a data processing agreement under Art. 28 GDPR for SaaS? Yes — as soon as the provider processes personal data on your behalf, a data processing agreement under Art. 28 GDPR is mandatory. You remain the controller. If the DPA is missing, you face fines of up to EUR 10 million or 2% of worldwide annual turnover (Art. 83(4) GDPR).
What does the EU Data Act say about vendor lock-in? The EU Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025 and requires cloud providers to grant effective switching and portability rights. From 12 January 2027, switching charges are fully prohibited. Vendor lock-in thus becomes an enforceable legal right — one you should anchor contractually.
Sources — as of 14.01.2026
- EU Data Act — applicable from 12 Sep 2025, switching-charge ban from 12 Jan 2027 (Anwaltskanzlei Schutt): https://anwaltskanzlei-schutt.de/it-recht/eu-data-act-geltung-ab-12-09-2025-was-unternehmen-jetzt-umsetzen-muessen/
- EU Data Act — cloud switching & deadlines (Deloitte Legal): https://www.deloittelegal.de/dl/en/services/legal/perspectives/cloud-switching-eu-data-act.html
- EU Data Act — Switching charges fully prohibited from 12.01.2027 (Latham & Watkins): https://www.lw.com/en/insights/eu-data-act-significant-new-switching-requirements-due-to-take-effect-for-data-processing-services
- EU Data Act — enforcement & national sanction regimes (DLA Piper): https://www.dlapiper.com/en/insights/publications/2025/10/data-act-implementation
- EU AI Act — prohibitions (Art. 5) from 02 Feb 2025, GPAI obligations from 02 Aug 2025 (European Commission): https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Art. 28 GDPR — DPA obligation & fine for non-compliance (DataGuard): https://www.dataguard.de/blog/der-auftragsverarbeitungsvertrag-avv/
- CLOUD Act vs. Art. 48 GDPR — conflict of norms & EDPB assessment (idgard): https://www.idgard.com/de/blog/us-cloud-act-vs-datenschutz/
- CLOUD Act — access by US authorities to data in the EU (LfD Niedersachsen): https://datenschutz.nibis.de/2020/09/07/der-cloud-act-zugriff-von-us-behoerden-auf-daten-in-der-eu/
- Software maintenance cost 15–20% p.a. / lifecycle share (scnsoft): https://www.scnsoft.com/software-development/maintenance-and-support/costs
- Software maintenance as a share of TCO (IEEE reference, idealink): https://idealink.tech/blog/software-development-maintenance-true-cost-equation
Note: Legal deadlines and the DPF status are volatile; before making binding decisions, check primary sources (EUR-Lex, the GDPR text) and the current status. This article is a professional summary and is general information, not legal advice for the individual case.
Leon Lotz
Leon Lotz is a business lawyer and founder of MusketierSoftware. He combines legal depth with real software craft.
