Make-or-Buy in the Age of AI

Why Enterprise Architects Must Rethink the Make vs Buy Decision

The world is changing, but are you, as an Enterprise Architect, changing with the times? The cost of building software has dropped dramatically, and is still falling.

The traditional “buy before build” principle deserves to be reconsidered.

For decades, standard thinking has been to buy software whenever possible and only to build when necessary (when your requirements are highly specific, or when the software provided a core business function giving you competitive advantage).

In many cases it has been the recommendation to accept generic SaaS software, which perhaps doesn’t perfectly match your requirements, but which spares this risk and cost associated with self-building, and hosting.

What if I told you, you could have the best of both worlds? Software perfectly fitting your requirements, without the high cost and risk. Sounds too good to be true? Well, perhaps, but perhaps it’s also not as crazy as it sounds.

How AI is Changing the Cost of Building Software

More and more companies (and individuals) are turning to LLMs to generate code. While this “vibe coding” may still have some stigma associated with it, many companies are proving that AI-assisted development can yield high quality for a fraction of the price.

Instead of entire teams building a software service over multiple months, individual engineers have been able to spin up complex services in a matter of days or weeks, including a full suite of tests and a great user interface and oftentimes documentation.

We are discovering that, as we previously found with higher level programming languages, AI generated code isn’t just a fad, it’s here to stay and likely will become the dominant form of software development in the future. This shift, however, introduces new challenges.

As the cost of building software decreases, the boundary between buying and building is shifting.

The AI Build-Buy Threshold Model

This model shows how AI is lowering the threshold at which building software becomes viable. The key shift is not in differentiating capabilities, which were always built, but in supporting capabilities, which are now increasingly viable to build.

Legend

The colours represent the following:

• Blue (Buy) – Vendor provided solutions are generally preferable.
• Green (Build) – Internal building is viable. In some cases this may justify a strategic build where significant investment is made to create high-quality, long-lived solutions.
• Yellow (Evaluate) – Decision is less clear and depends on context. Further evaluation is required.

Interpretation

This is not a binary change, but a transition.

Where an organisation sits between these two states depends on:

• Its maturity in AI-assisted development.
• The capabilities of available AI tools.
• Its ability to govern and operate internally built systems.

When Building Software Now Makes Sense

Here are some situations where building can be a strong option:

1. Internal Tools with Unique Requirements

Internal tooling is one of the clearest opportunities.

Off-the-shelf SaaS often forces organisations to adapt their processes rather than the other way around.

We have become used to paying this price because:

• We often assume that internal tooling isn’t providing a competitive advantage (even though it often can).
• Because customers don’t see it, it isn’t considered as important and hence doesn’t get the investment it would need to be built.

In fact, internal tools are ideally suited for an AI-assisted build because:

• Customers don’t see it. The risk of brand damage is lower if it looks bad. We can be much more relaxed about releasing something functional, but ugly.
• We can be more relaxed about release cycles. We probably don’t need to ensure 100% uptime.
• We have easy access to stakeholders to test and validate the product hypotheses, so there isn’t a “market fit” problem as there is for customer facing software.

For highly domain specific internal tools, the case becomes even clearer as the available vendor pool becomes very small and your organisation is already expert in that domain!

2. Avoiding Vendor Lock-in

SaaS vendors frequently actively try to lock-in their customers. Don’t blame the vendor, for them it’s just business, but some vendors are more problematic than others.

EAs might not explicitly consider the cost of managing aggressive price increases, complicated contract negotiations or managing the risk of a forced migration, but these costs (and risks) are real.

The exact numerical cost, and risk, of being in a vendor lock-in may also change in unknown ways over time. We can make an assessment for today that does not hold 2 years from now. This is compounded as vendors are scooped up by larger players and the buyer decides to monetize more aggressively.

If we were honest (and had better alternatives), perhaps we would be less inclined to pay this ransom?

Vendor lock-in can appear in several forms:

• Data Lock-in – When proprietary data is stored, in vendor-specific formats, migration becomes expensive.
• Process Lock-in – When processes have been adapted to match the vendor’s workflow, migration requires process re-design and can involve retraining.
• Integration Lock-in – Technical integrations with other systems can grow to be complex creating a high cost to migrate.
• Platform Lock-in – By providing a wide suite of tools, the above lock-ins are further compounded.

Evaluate those SaaS components which would cause a high level of pain to your company if the vendor were to become an unreliable partner. With a clear-eyed view of the risk, perhaps you could build some of these components yourself?

Historically, even if vendor lock-in was undesirable, the cost of building alternatives was often too high. AI-assisted development changes this calculation, making it more feasible to build internal alternatives for certain components.

3. Best-of-Breed Architectures

Many companies have moved away from heavy platform suites and unified solutions in favour of a best-of-breed architecture. This means using distinct specialised components (better fitting the company needs) and integrating them together.

Best-of-breed architectures already require integration, so extending this to additionally building some of those specialised components internally may now be viable.

Specialist vendors who focus on a small part of the problem space can, and often do, provide a first class set of features, indeed, they focus their entire businesses around solving a small set of problems well. Competing with such highly specialised vendors is probably foolish given their laser focus.

However, there are probably also components which do not need to be state-of-the-art or perhaps which aren’t that important to your business. In such cases, finding a specialist vendor is not an interesting endeavour, but an obligation to complete the set of features which a general platform suite would have otherwise provided.

Such cases are ideal candidates for AI-developed components.

Some examples could be:

• The customer address management service for managing historical addresses.
• A knowledge base for internal employees, or for customers.
• Dashboards and cockpit views for specific stakeholders.

In addition, the actual integrations between components using APIs, events or middleware can be implemented using AI-assisted development. The requirements are usually easy to describe given that the input and output contracts are already well defined.

4. Non-Core but Non-Commodity Capabilities

Some capabilities are:

• Not strategic enough to justify a large software procurement.
• Too specialised for generic SaaS tools.
• Not considered important enough to justify the cost of building.
• Too simple and specialised that nobody even considered that software could be used.

Such cases are good candidates for AI-assisted development.

Examples might include:

• Niche reporting or dashboards.
• Specialised non-core operational workflows (including replacing currently manual processes).
• Internal data processing pipelines (such as extracting data from emails or Excel tables and converting this into another format, or connecting to an API)

When You Should Still Buy Software

AI changes the economics of building software, but it does not eliminate the need for mature platforms.

Commodity Business Systems

Some systems operate in a similar way no matter your business. These are often complex, have developed slowly over decades, and mostly have a very well understood problem domain.

It is usually not worthwhile to build such systems:

• ERP
• HR Systems
• Payroll
• CRM
• Finance Systems

These systems often fall into the Complex / Commodity corner of the model and are clear buy decisions.

Infrastructure Platforms

Building foundational platforms (upon which other software is built) is still extremely risky.

Examples include:

• Technical infrastructure components (storage and databases, communication infrastructure)
• Identity platforms

These are better sourced from mature vendors or open-source ecosystems.

Engineers require very deep technical expertise to even validate code and small errors can have catastrophic and cascading consequences.

Platforms with Network Effects

Sometimes it makes sense to buy something simply because many other people or organisations already use it. This can mean we need to interact directly with other people outside the organisation and using standard software enables this. Alternatively it can mean we rely upon software from which we benefit from a broad industry usage and we can hire users for this software and benefit from community discussions and knowledge sharing.

Examples:

• Productivity tools such as ticket management and project management.
• Communication tools
• Identity platforms (especially enabling federated identity).

These systems don’t falls neatly into the model, but remain clear “Buy” decisions. While they may be technically feasible to build, their value lies not in their implementation, but in their network, scale and ecosystem – all of which are difficult to replicate.

Is Your Organisation Ready for AI-Assisted Development?

AI-generated software is also not a “free lunch” and still requires important considerations:

Security and Compliance

Customer data and other sensitive systems require oversight. An AI code generator cannot (yet) take responsibility for data leaks or data loss. There still needs to be a review process in place.

Governance and Maintainability

Somebody still needs to understand and maintain generated code. Code needs to be able to evolve over time, so it is important that someone is responsible that architectural standards and guardrails are respected.

Hosting and Infrastructure

Building the thing isn’t enough. You also need to run it somewhere, which means hosting and infrastructure. We also need to keep track of IT costs relating to hosting to ensure they do not spiral out of control.

AI-Enabled Workforce

Your engineers, architects and other team members need to know how to leverage AI tools effectively and to be enabled with access to appropriate AI tooling.

Building and anchoring AI-Assisted software into your organisation requires that you have considered and addressed these (and probably more) topics. Also consider that:

AI accelerates development, but it can also amplify your organisational problems.

Final Thoughts

Traditional assumptions around buying or building are being challenged with new trends.

AI isn’t just making developers faster, it is changing the economics of software sourcing.

Things are moving very fast, so don’t plan just for today, think what might be possible in 6 months to a year.

The challenge for Enterprise Architects is no longer simply choosing between buying or building, but understanding how the economics of creating software are changing.

EAs which can adapt to these trends can make smarter, and more cost-effective, decisions for their businesses.

Those who ignore these shifts risk locking their organisations into expensive software contracts while competitors seek newly emerging alternatives.