Make or Buy 2.0: How AI Changes the Question

Part 3: Make or Buy 2.0: How AI Changes the Question

In Part 2, we outlined the Greenfield architecture, while deliberately sidestepping one question: if AI makes custom development cheaper, why buy platforms at all? We saved that discussion for this part because it is the most uncomfortable one in the series. Here, we have to push back against a hype cycle that, frankly, consultants like us could profit from quite comfortably.

Right now, the same sentence comes up in every second executive conversation: “With AI, we’ll just build it ourselves.” It is usually said with a mix of excitement and relief – finally escaping license dependency, finally getting software tailored exactly to the company’s own processes. We completely understand the appeal. And still, our honest answer is almost always: maybe. But should you really? And more importantly: what exactly?

A disclosure upfront, in our own interest: we could easily go with the flow here. Custom development means project work, and project work feeds consulting firms far more reliably than the sober advice to stick with standard software. That is precisely why we approach this topic with particular caution. What follows is not the hype version. It is the calculation we make even when it argues against our own pipeline.

The Old Logic – and Why It Worked for So Long

For nearly two decades, the make-or-buy question was surprisingly easy to answer. Custom development was expensive, slow, and risky: you needed a development team, a project plan, a testing concept and in the end, you got software that only your company understood and only your company could maintain. Standard software, by contrast, was cheaper, faster to deploy, and came with an upgrade path: the vendor handled ongoing development, security, integrations, and regulatory changes.

That logic was not wrong. It was correct for more than twenty years – and honestly, it remained correct longer than the headlines now suggest. Anyone who internalized “buy instead of build” as a rule of thumb made the right decision in the vast majority of cases. The only issue is that rules of thumb eventually expire – and the assumptions underlying this one have only recently started to shift.

One distinction matters here, because it often gets blurred in the debate: the difference between the availability of tools and their practical usefulness. AI coding assistants have existed since 2022, and with ChatGPT the topic reached executive suites by late 2022. For clearly defined, narrowly scoped development tasks, productivity gains became measurable quite early. But being useful for simple tasks is not the same as being useful for complex environments. For production-adjacent, deeply intertwined mid-market business processes, the benefits are only now becoming reliable in day-to-day operations – and even then, unevenly. Anyone redrawing the make-or-buy boundary today should base it on practical suitability for the specific use case, not on the date of the first press release.

What AI Actually Changes – and What It Doesn’t

An honest assessment starts with a separation: AI materially changes one part of the make-or-buy equation – and leaves another part almost untouched. Understanding the difference is the whole game.

• Build Costs Are Falling – but Later Than the Hype Claimed

The effect is real, but it is recent and uneven. For years, more was promised than delivered. Only recently have we started seeing efficiency gains – both in our own projects and with clients – that genuinely hold up in daily operations. For clearly defined, well-contained tasks, the gains can be substantial. For complex business logic, much less so.

And the gross numbers are misleading. A large share of the typing effort that AI saves is reinvested into review, correction, and rework. There is still a net gain – just rarely on the scale implied by the headlines. What has truly changed is the threshold for the first draft: prototypes that would never have been built before due to effort constraints can now emerge in days.

The underlying picture is a simple curve. For a long time, the point at which custom development became cheaper than standard software sat far to the right: you needed a high degree of specialization and a large user base before building your own solution made economic sense. That point has only recently shifted noticeably to the left – more slowly than announcements suggested, and it is still moving. Cases that would clearly have fallen on the “buy” side not long ago are now genuine toss-ups.

• The Make-or-Buy Boundary Is Shifting

AI-assisted low-code tools create a second shift – more subtle, but potentially more consequential. Development is moving closer to where the process actually happens: into the business departments themselves. Procurement teams build supplier evaluation tools. Manufacturing creates small setup-time apps. Sales develops quote configurators. No IT ticket, no waiting time – ideally days instead of months. For speed, this is a blessing. For architecture, this is exactly where things become dangerous – more on that shortly.

• What AI Does Not Change: Operations, Maintenance, Responsibility

And here lies the core point that the hype regularly skips over: build costs were never the real problem of custom development. The real problem starts after go-live.

Software must be operated, maintained, adapted to new interfaces, hardened against security vulnerabilities, and adjusted to regulatory changes. Someone needs to understand it five years from now. These are exactly the cost categories AI barely reduces today – and in some cases even increases, because faster development simply creates more software that needs to be maintained.

This is not just consultant caution. Industry research shows the same pattern. The DORA Report 2024, for example, found clear perceived productivity gains from AI, while also showing that higher AI usage tended to correlate with lower delivery stability and reduced deployment performance. The Stack Overflow Developer Survey 2025 found that more than four out of five developers use AI tools while confidence in the correctness of the results is declining. Writing code faster does not automatically mean delivering better systems. Review, verification, and accountability do not disappear; they merely shift.

→ AI makes custom development cheaper. It does not make it smarter.

What makes custom development smart is not the tool, but two things: architecture and governance. They determine whether cheaper development becomes an advantage – or simply accelerates uncontrolled sprawl. And they form the thread running through the rest of this article.

When Custom Development Truly Makes Sense Today

As build costs decline, the threshold for choosing custom development shifts – but it does not disappear. In our view, there are four areas where custom development now pays off faster and more convincingly than it did only a few years ago.

The first is differentiating processes that no standard solution can adequately represent the processes through which a company genuinely competes in the market. A configurator reflecting unique product logic. Pricing mechanisms embedding years of industry expertise. In these cases, forcing differentiation into a standard software corset can be strategically negligent.

The second is specialized workflows with a small user base, where standard licensing models never really made economic sense. This is exactly where custom development used to be too expensive and standard software too oversized – and where the lower development threshold now changes the equation.

The third area is proprietary data intelligence: analytics and models built on a company’s own data that create competitive advantage.

And the fourth is rapid experimentation: ideas you want to test before knowing whether they will work. In the past, this required launching a formal project. Today, you can build a prototype and learn.

When Standard Software Still Wins

As important as the shifted boundary is, the picture on the other side remains equally clear. There are still areas where standard software is the right answer – arguably more clearly than ever. Nobody should build accounting, payroll, or classic CRM functionality themselves. These processes are largely the same everywhere, tested millions of times, and covered by market solutions at price points no internal team can realistically beat.

The same applies to compliance-heavy domains where vendors assume responsibility for regulatory conformity – from tax law to privacy documentation. It also applies to functions with strong economies of scale, where a broad market finances continuous innovation that no single company could support alone. And to areas with extensive supplier and partner ecosystems, where interoperability with standards is worth more than any tailored customization.

Six Questions Before Every Make-or-Buy Decision

The real make-or-buy evaluation no longer starts with the question of whether something can be built – with AI, almost anything can. It starts with six different questions:

1. Does this process actually differentiate us in the market?

2. How many users does it affect?

3. How long will the solution live?

4. What regulatory risks does it create?

5. How deeply is it connected to core systems?

6. Who will operate, secure, document, and evolve it five years from now?

Only once these questions are answered does AI-assisted custom development become a management decision rather than a technical impulse.

One of these questions, however, is not merely one factor among six. It is the gate all the others must pass through: operational ownership.

No matter how differentiating a process may be, it does not justify custom development unless maintenance, security, monitoring, and business ownership are clearly assigned. Without an owner, budget, and documentation, even the most elegant custom solution eventually becomes another liability.

Which brings us to the uncomfortable part.

The Four Debts of the “We’ll Build Everything Ourselves” Wave

When building becomes cheap enough that everyone can do it, everyone starts building – and the bill arrives later. We increasingly see four forms of debt emerging, all of which are easy to overlook during the initial enthusiasm around low build costs.

They all share one characteristic: they do not appear in the project budget. They appear in operations.

1. Maintenance Debt

What is built quickly today must be maintained tomorrow. Every self-built application is a long-term maintenance promise – to yourself. Interfaces change. Libraries become insecure. Requirements evolve. Ten AI-built applications are still ten maintenance obligations, even if each one was created in a single afternoon. Fast development is not a promise of cheap operations – if anything, often the opposite.

2. Knowledge Debt

Who maintains the application in five years? With self-built software, the critical knowledge often lives inside one person’s head – usually the motivated business user who built the tool over a productive weekend. When that person leaves the company, what remains is a black box nobody dares touch. AI-generated code can even worsen the problem: it is produced quickly, but often not deeply understood by anyone.

3. Compliance Debt

AI-generated code pushed into production without expert review creates risk – the kind that only becomes visible once it is too late. Privacy, security, traceability: standard vendors carry responsibility here within a defined framework. With custom development, that responsibility sits entirely inside the company – even when the code itself originated from an AI system nobody fully reviewed. There is a reason why security frameworks such as the OWASP risk list for LLM applications and the NIST Secure Software Development Framework identify unchecked outputs, supply-chain risks, and blind trust in AI as central threats.

4. Process Debt

This may be the most underestimated debt of all. Self-built applications often cement exactly the processes that should actually be questioned. Instead of asking “Do we even need this step?”, organizations quickly turn it into software – and thereby make the inefficiency permanent. Standard software at least occasionally forces confrontation with established best-practice processes. Tailored custom solutions spare companies from that uncomfortable discussion – and that is not necessarily an advantage.

→ Without architectural discipline, AI-driven development simply creates the next zoo – only faster.

Two Practical Examples

To keep this from remaining abstract, here are two anonymized examples from our work – deliberately one in each direction.

The positive example: a mid-sized company used AI-assisted development to create a specialized configurator representing a genuine differentiating capability in its business – something no standard system could have delivered. Thanks to AI support, the development effort remained manageable. The solution fit cleanly into the extension layer of the architecture, and after roughly eighteen months, the investment had paid for itself through won deals and reduced proposal effort.

Here, custom development was the right answer – because it addressed a differentiating capability and was architecturally intentional from day one.

The cautionary example: another company built its own reporting application quickly and cheaply inside the business department. After roughly eighteen months, nobody maintained it anymore because the original developer constellation had changed. Reporting quality deteriorated, trust eroded, and eventually the realization emerged: a standard BI solution would have covered roughly 80% of the requirements from day one with an upgrade path and without knowledge debt. The savings happened upfront. The payment came later – with interest.

“But Soon AI Will Maintain Itself” – the Strongest Counterargument

The strongest counterargument against everything above deserves to be acknowledged openly: if AI can handle development today, will it not eventually handle maintenance, review, and further evolution tomorrow? Would that not eliminate three of the four debts almost automatically? The objection is legitimate – and the direction is probably correct. Tools that understand existing code, document it, and evolve it safely are improving rapidly.

But two things should not be confused: what becomes technically possible, and what remains organizationally accountable. Even if an AI system can technically maintain an application five years from now, someone still has to decide whether a change is business-correct, who carries liability when something fails, and who even remembers the application exists. That is not solved by tools. It is solved by governance. Our recommendation is therefore not a bet against technical progress. It is a bet that accountability will still belong to humans five years from now. Anyone building today should plan under the assumption that AI may not remove the maintenance burden – and simply be happy if it eventually does.

Our Honest Recommendation

Custom development: yes. But with architectural discipline, not as Wild Growth 2.0.

The good news is that Greenfield architecture, discussed in Part 2, already provides the right place for it: the extension layer. The deliberate, controlled space for low-code solutions and targeted custom development. That is where custom development belongs, not inside an expanding shadow IT landscape nobody can fully understand five years later.

Which means the real question is no longer simply “make or buy.” It is: “Make or buy – and who will operate, maintain, and own it five years from now?” Anyone who answers the second half of that question as well will continue making good decisions in the AI era. Anyone who skips it because building currently feels so temptingly cheap will simply build the next zoo – only faster than the first time.

What Comes Next

One final question remains – and it is the most practical one of all: How do you actually combine these approaches in practice? Standard software for the core, low-code for the gaps, AI-assisted custom development for differentiation – it sounds like a neat principle, but what does it look like in euros and in day-to-day governance? That is what Part 4 of this series will cover: the cost-optimized symbiosis. We will examine where typical licensing cost traps lie, what an honest multi-year TCO perspective looks like, and who inside the organization should actually decide what becomes standard software, low-code, or custom development.

Until then, here is one question to take into your next “we’ll just build it ourselves” conversation: Do you already know who will still be maintaining what you want to build today five years from now? If the answer is clear, custom development may indeed be exactly right. If not, it may be worth pausing before laying the first brick.