Published: Last updated:

Make or Buy

Make or Buy: build what differentiates, buy what the market solves

Buy the commodity, build only what differentiates, and enter every dependency consciously, with a costed exit path.

The first reflex is usually: "We'll buy everything and focus on our business." That is the wrong question. Make or Buy, the choice between custom development (Make) and purchase (Buy), is not a pure cost decision. It is a question of differentiation, lifetime cost, and sovereignty. Buying everything competitors also buy cannot beat the competition. Building everything in-house burns budget on problems the market has long solved better. This page gives no creed, but a method for the concrete case.

Four criteria drive the decision

It is not the licence price that decides, but four criteria, in this order:

  • Differentiation value: Is the process a real competitive advantage, unique, or proprietary? Only then does custom development pay off. Everything else is commodity.
  • Market availability: Are there at least three good vendors for the problem? A functioning market means: buy, don't build. The middle ground between buying and self-operating is covered in the Managed Services topic.
  • Internal capability over 10 years: Is the team in place to maintain, secure, and evolve the solution across its entire lifecycle, not just build it once?
  • Time to market: Must the system go live in four weeks? Then custom development is effectively off the table, no matter how differentiating the topic is.

These four criteria are the spine of the decision. Everything else (lifetime cost, lock-in, sovereignty) sharpens them but does not replace them.

The Wardley logic: Genesis, Product, Commodity

Behind criterion 1 sits Simon Wardley's evolution logic. Every capability moves over time through three stages, and the stage determines whether Make, Buy, or a pure utility is right:

  1. Genesis (Make): Novel, highly specialised solutions for problems where nothing yet exists on the market. This is where innovation lives, and only here is custom development justified.
  2. Product (Buy / SaaS): Established products for known problems. The focus shifts from code to integration and configuration.
  3. Commodity / Utility: Standard services like electricity or cloud infrastructure that are simply consumed. Building them in-house is pure waste.

The mistake is almost always the same: treating a commodity like genesis (building a CRM in-house), or treating a differentiating core process like a commodity (forcing a unique business model into a standard template). Wardley makes visible which stage a process is really in.

The decision flow

The following decision tree makes the four criteria actionable. The concrete process is run through it from top to bottom and lands on one of three verdicts: Buy, Make, or Buy with an exit path. The second branch is decisive. Differentiation alone does not justify a Make if the capability to maintain it for ten years is missing.

flowchart TD
    A["Assess the process"] --> B{"Differentiating<br/>core process?"}
    B -->|"No, commodity"| D["Buy:<br/>standard / SaaS"]
    B -->|"Yes"| C{"Capability for<br/>10 years of upkeep?"}
    C -->|"Yes"| E["Make: custom build"]
    C -->|"No"| F["Buy with<br/>exit path"]
    D --> G["Lifecycle cost<br/>calculation"]
    E --> G
    F --> G

Total cost over the lifecycle

"Make" looks cheap on the day of purchase, because there is no licence invoice. The fallacy lies in the time horizon. Custom development is only costed fairly by taking the lifetime cost over five to ten years, not the initial effort. On top of the initial costs come:

  • Maintenance and evolution. Code ages, requirements change.
  • Security patches. Every self-built component is an item that must be secured permanently.
  • People and knowledge. The solution stands or falls with people who carry it for years. Staff turnover is a real cost factor.
  • Platform and operations. Hosting, dependency updates, compliance.

The honest comparison is therefore not "development cost versus licence price", but cumulative effort for Make over five to ten years versus cumulative subscription and switching costs for Buy. The detailed cost categories and a worked lifecycle view are in the Total Cost of Ownership (TCO) topic. The technology view of the Buy side is deepened in Standardsoftware.

Vendor lock-in and the conscious exit

Buy quietly buys in a dependency. That is not an argument against Buy, but against unconscious Buy. Vendors can change contract terms unilaterally, raise prices, or bind access to the data to foreign law. Lock-in is legitimate as long as it is entered consciously and has a costed exit path:

  • Which data and interface standards secure the switch?
  • What does the exit actually cost, in money, time, and risk?
  • Is there a tested migration path, or only the hope of one?

Exactly these questions distinguish a sovereign Buy decision from a trap. The conscious exit is part of the decision, not a later problem. More on this in the Vendor Lock-in topic.

A conscious Buy decision also includes a sober assessment of the vendor itself before the dependency is entered: technological maturity, financial stability, and adherence to local compliance. A vendor that works today but is financially shaky merely pushes the risk into the future.

Three clear cases: Buy, Make, the dangerous middle

  • Buy wins, the commodity: Known problem, functioning market, no differentiation value. CRM, HR, mail, office. Here, building it in-house is a waste of resources. To select a commodity like CRM or ERP cleanly and vendor-neutrally, follow the method of independent technology selection; its applied form is available as a service: Independent software evaluation.
  • Make wins, the differentiator: A unique core process that stands out from the competition, and the capability to maintain it for ten years. Only when both hold true.
  • The dangerous middle, the customised standard: Standard software is bought and customised so heavily until it "fits perfectly". This is the riskiest path. The update capability of the standard is lost, and the maintenance costs of custom code remain. Both bills come due, the benefits of neither side. This middle is the most common real-world failure. It must be named as a trap before one walks into it.

Sovereignty as a decision criterion

For an organisation, Make or Buy is more than an economic decision: whoever buys a solution also decides who ends up holding control over their own data. This is exactly where digital sovereignty becomes a criterion of the choice. In Switzerland, "Buy" often equals "US SaaS", and the revised Swiss Federal Act on Data Protection (nFADP), the GDPR, and the US Cloud Act thus shift the Make-or-Buy question into the realm of sovereignty. Whoever buys from a US hyperscaler potentially binds their data to foreign law.

  • The Conference of Swiss Data Protection Commissioners (Privatim) has effectively heavily restricted the use of international cloud services by public bodies for especially sensitive data. The central argument is the Cloud Act, which can compel US vendors to hand over data even when the servers stand in Switzerland.
  • The Digitale Gesellschaft demands that public procurement be aligned consistently to sovereignty criteria and the open-source principle, away from ever-deeper integration into the Microsoft 365 universe. How the open-source idea can be anchored in procurement is covered in Public Code und SBOM.
  • With the European Sovereign Stack Standard (ES3), which builds on the EU Cloud Sovereignty Framework, sovereignty becomes measurable across nine dimensions, a maturity model that maps cleanly onto a decision matrix.

This shifts the calculus: build, self-hosting, or EU hosting can itself be the differentiator, not despite, but because of, sovereignty. Staying honest is part of it. A study by the City of Zurich and the Bern University of Applied Sciences concludes that the open-source alternative OpenDesk does not yet fully replace Microsoft 365. Sovereignty is an assessable criterion of the Make-or-Buy decision, not an automatism. This very weighing is le dot's positioning and our service Make-or-Buy and Vendor Management. Deep dive in the Digital Sovereignty topic.

References

Related topics

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.