Build or buy internal software: decide layer by layer

The old build-or-buy question was asked one piece of software at a time, on cost and time: building was slow and expensive but fitted the need, buying was fast but made you bend to the tool. It was also asked as if the answer held for the whole IT estate. It does not, and it never did.

If you read one thing in this guide, read this: the decision is made layer by layer. What a vendor carries better than you is bought. Industry software depends on its price and on the rules it holds for you. What sets you apart is built. And the tool that builds that last layer belongs to the first one: you buy it.

What changed: building became possible, the rest did not move

Two movements are happening at once, and they do not contradict each other.

Building became practical where it was not. In the McKinsey study published in August 2026, 32 percent of respondents report that their organization decided against purchasing at least one software product or feature because it was able to build the functionality in-house using agentic coding tools (1,719 participants in 97 countries, fieldwork from May to June 2026).

And the price of what you buy keeps rising. In a Cigref survey of 54 chief digital officers published in May 2026, the cost of cloud and software services rose on average by 8.7 percent a year over three years, and 71 percent of respondents consider that trajectory hard or impossible to sustain.

Neither says you should build everything. AI lowered the cost of the first version of a piece of software, not the cost of its whole life: the rules that change, the data that accumulates, the changes that must not break anything. What moved is where building is worth it. To find it, you have to look at the IT estate in layers.

The three layers, and the rule for each

First layer: what the vendor carries better than you

Payroll, general accounting, email, customer relationship management in its standard form. What makes this software valuable is not the screen. It is what the vendor carries for you: rules that change every year, compliance that has to hold in several countries, security updates, support. Rebuilding it means taking that load back onto yourself, for a result that sets you apart from nobody.

The rule: buy. And adapt to the vendor's way of working, because that is precisely what you are paying for.

One nuance matters. This layer is not defined by how ordinary the function is, but by what the vendor carries. A small generic utility, with no rules or compliance behind it, can now be built in a few hours. Multi-country payroll cannot, even with AI, because what it costs is not the code.

Second layer: industry software

Software designed for your line of business: maintenance management, production planning, site management, the software of your regulated profession. It covers part of the way you work, not all of it. This is the layer where the decision is genuinely open.

The rule: it depends on two things, not one.

• The price, and where it is heading. What the licence costs today, and what it will cost at the next renewal. This is the layer where unilateral increases weigh most, because alternatives are few.
• The regulatory load the vendor holds for you. If the software carries rules specific to your industry, rules that change and that you would otherwise have to track yourself, it is worth more than its screen. If it mostly carries your way of working, and you already work around it, it is worth less than its price.

One question often settles it: what are you paying for, the rules or the screen?

Third layer: what sets you apart

The costing tool that combines your costs, your margins and your capacity constraints. The tracking that consolidates information scattered across several entities or several systems. The portal where your suppliers and partners submit their information in your format. What they share: the logic is yours, and no vendor carries it for you. Today this layer often lives in a shared spreadsheet, an email thread, an application nobody maintains any more, or a request waiting in the IT backlog.

The rule: build. No market product will do what sets you apart, by definition, and bending it to a generic tool costs you more than the software saves.

Example: an organization sorting its portfolio

Take a mid-sized organization reviewing its software, function by function. This is an illustration, not a customer case.

Human resources. Payroll sits on the first layer: it is bought, no discussion. Onboarding a new employee, across three entities, four approvals and equipment to order, is not covered by any market product without workarounds. It sits on the third.

Finance. General accounting sits on the first layer. Matching orders, receipts and invoices, with the tolerances the finance team set itself, lives in a spreadsheet. It sits on the third.

Operations. The maintenance management software sits on the second layer. It carries few regulatory rules, its licence goes up at every renewal, and the teams already export its data to a spreadsheet to do what it does not. It is up for review.

Sales. Customer relationship management sits on the first layer. The quote configurator, which applies your discount rules and your product combinations, sits on the third.

Two things come out of this review. The decision is made piece by piece, not function by function: every function has one foot on the first layer and one on the third. And the third layer was never empty: it was in spreadsheets, because building it was out of reach.

The two costly mistakes, and they mirror each other

Building on the layer you should buy. This is the mistake of rebuilding what the vendor used to carry, and taking back a load that does not set you apart. Many companies set out to train their own language model. In-house training has become marginal: you buy access to a model on the market, and you build what sits on top of it. The model was on the first layer.

Buying on the layer you should build. The opposite mistake, and a quieter one, because it looks like a reasonable decision. You buy a market product for a process that is yours, then configure it, extend it, have the vendor develop custom features, and end up exporting its data to a spreadsheet to do what it does not. You pay the licence for a product you have bent to your rules, and you still carry the complexity.

Building no longer means hiring a team

What held the third layer back was never the will to build. It was that building meant recruiting a team, waiting for months, and depending on whoever wrote the code. Several ways to build now exist. Each one is legitimate, and each one stops at a precise point.

The five questions to ask of any way to build

On the third layer, the question is no longer "can we afford to build it?" but "if we build it, will it last?". Five questions answer it, and they apply to an internal project as much as to any product.

1. Who approves what is produced, and can they read it? If only a developer reading code can say it is right, your capacity to build is your capacity to review.
2. What happens to the data already there when the application changes? That is the risky part of any change. An application that starts from zero at every change of structure does not last.
3. Can the build reach your production systems or your live data? The right answer is that it cannot by construction, not that it is prevented by a setting.
4. Where does the code live when it is done, and what does it need to keep running? In your repository, on infrastructure you choose, or on someone else's platform.
5. Who carries the changes a year from now? The need will change. If the answer is "whoever built it", the problem has only been postponed.

How fast the first version appears is not on the list. That is the part everyone can already do.

Checklist: where your need belongs

Build if

• The process is yours, and it will still matter in three years.
• It lives today in a shared spreadsheet, an email thread, or an application nobody maintains any more.
• The market product you tried had to be bent to your rules.
• The need will keep changing, and other versions will follow the first.
• Someone on the business side owns the need and can say whether the result is right.

Buy if

• The process is the same for you as for your competitors.
• The vendor carries rules, compliance or updates you would otherwise have to track yourself.
• You are willing to adopt its way of working, and it fits well enough.
• The price and where it is heading stay reasonable for what it carries for you.

Questions: the five asked most often, and their short answers

With AI, can't we just build everything? You can build far more than before, not everything. The first layer is worth what the vendor carries, the rules, the compliance, the updates, and AI does not take that off your hands. Building payroll is still a bad idea, even if code has become cheap.

What about maintenance? It is the real question of the third layer, and it is why the speed of the first version matters so little. The cost of software is in its changes: what has to change without breaking anything, and the data that has to be kept when the structure changes.

Do you need developers to build? Not necessarily. What you need is someone who owns the need and can say whether the result is right. If you have a technical team, it keeps control wherever it wants it. If you do not, the third layer no longer has to wait in the backlog.

What about the applications teams have already built with AI? That is the third layer building itself, without a frame. The need was real. What is missing is knowing what those applications do, where they run, and who will change them. The five questions above apply to them too.

What if our industry vendor raises its prices? That is exactly the moment to review the second layer. Not to rebuild everything, but to separate what the vendor genuinely carries for you from what you pay it for a screen.

Maleus: the tool that builds the third layer is something you buy

That is the turn that closes the decision. An AI software factory belongs to the first layer itself: it is a product you buy, because it carries what you do not want to carry, the whole delivery cycle. What you build with it is what sets you apart. You buy the capacity to build, and you build what is yours.

Maleus is an autonomous AI software factory for internal software. A team of AI specialists covers the full delivery cycle, one for each role: product, design, analysis, build, quality, data and deployment. The person who owns the need approves the specification, written in plain language, before anything is built, then accepts the result inside the running application.

The delivered application is complete, backend included, as standard code in your Git repository, on the infrastructure you choose. Each build runs isolated, with no standing access to your production systems, and every action is recorded. SOC 2-ready and ISO 27001-compatible.