Build vs Buy in 2026 and What We Are Actually Buying

Back in December 2024, I wrote about whether to buy an ISV solution or build your own functionality in Dynamics 365. We walked through cost, implementation time, technical resources, support, and ownership.

I still care about all of those things. Particularly support. An impressive demo has never answered its phone during month-end.

But the conversation deserves another look. AI coding tools are changing what teams can reasonably attempt to build, and tools that help them investigate existing software are making the question more uncomfortable for vendors.

My view is that SaaS companies need to make their business expertise and reliable execution valuable independently of their screens. For buyers, that creates an opportunity to build more of the experience they want without assuming responsibility for every capability underneath it.

Which brings me to the question I would put in front of any software leadership team right now:

If your customers stopped using your screens tomorrow, what would they still pay you for?

Reverse Engineer Anything, usually shortened to REA, has attracted considerable attention this October. It connects AI coding agents to tools that inspect software, including established reverse-engineering tools such as Ghidra, Hopper, and IDA. An agent can investigate an application, trace relevant behavior, and use that evidence to help reconstruct a feature.

That is a meaningful capability. It also needs a little separation from the excitement surrounding it.

Inspecting an application does not automatically reveal a SaaS provider’s private backend. Recreating the behavior you can observe does not give you its operational data, every business rule, or the history of exceptions its team has spent years handling.

The project’s demonstrations include investigating individual calculations and software features. There is a substantial distance between understanding a calculation and operating a dependable enterprise product.

Still, dismissing this because reverse engineering already existed would miss the point. Specialist tools become more consequential when more people can use them effectively. The potential shift is in the effort required to investigate functionality and turn that understanding into another implementation.

For a vendor whose advantage depends heavily on customers finding its features difficult to reproduce, that deserves attention.

For a buyer, it deserves better judgment than “the subscription is expensive and the demo worked.”

The presentation layer has to earn its place

A good interface has real value. It helps people understand a problem, catch mistakes, and make decisions. Anyone who has watched a warehouse employee fight through five screens to complete one task should appreciate that.

But vendors should be nervous if the interface accounts for most of their differentiation.

Consider a manufacturing scheduling application. A polished board with draggable production orders is useful. The harder questions arrive when you move one.

Is the material actually available? Does the sequence introduce an allergen changeover? Is the required resource qualified and available? What happens to the schedule when a supplier misses a delivery, or actual production runs behind?

A convincing scheduling screen and a feasible production schedule are different deliverables. The customer is ultimately paying for the latter, even if the former sells the demo.

The same applies to a premium homebuilder’s selections portal. Beautiful images and an easy approval process help. The deeper value may be knowing whether a selection is valid for that floor plan, community, supplier, and construction stage, then carrying an approved change into purchasing with the correct cost and authorization history.

If the cabinetry is already ordered, a green checkmark does not make the change free. It just makes the argument more colorful.

Those rules and consequences are where a software product can accumulate expertise worth paying for. The interface gives people access to that expertise. Increasingly, customers will want other ways to reach it.

What I mean by a headless intelligence layer

Headless software separates the underlying capabilities from a particular user interface. Customers can reach those capabilities through APIs, agents, or an experience built for their own work.

I think that direction makes sense for SaaS. I would be careful, though, about what we call the intelligence.

Putting a general-purpose model behind an API does not create much protection from competition. Neither does exposing a collection of database operations and calling the product agent-ready.

The valuable layer needs to understand the domain and execute its operations dependably. It needs to enforce permissions, apply business rules, preserve transaction integrity, and leave enough evidence to explain what happened.

For Dynamics 365, think about an agent handling an invoice exception. Explaining a discrepancy is useful. Resolving it requires knowing what can change, whose approval is required, and how to perform the transaction through the appropriate application logic.

A natural-language answer cannot substitute for an authorized posting.

I also do not want critical business rules scattered across prompts maintained by whoever last edited the agent. If a rule must hold regardless of how someone reaches the system, it belongs in a place that enforces it consistently.

The agent can help interpret intent and coordinate the work. The underlying application still needs to protect the transaction.

Vendors are already moving in this direction

This shift was underway before REA attracted its recent attention.

On April 15, 2026, Salesforce announced Headless 360, describing access to platform capabilities through APIs, Model Context Protocol tools, and CLI commands. Its proposition puts data, workflows, and controls underneath experiences delivered on different surfaces.

Microsoft’s Dynamics 365 ERP MCP documentation describes tools for working with F&O data, forms, and application actions. MCP provides a standard way for compatible agents to reach those capabilities.

That creates an important possibility for our ecosystem: the user’s interaction can happen somewhere else while Dynamics remains responsible for the underlying business operation.

It does not mean every process is ready for autonomous execution. It does mean an ISV should have a thoughtful answer when a customer asks how its capabilities participate in that model.

If the answer is “open our portal and click these twelve buttons,” that may become a harder conversation at renewal.

Headless access brings a commercial tradeoff

There is a catch for vendors. Making your capabilities easier to consume can also make them easier to replace.

When the customer owns the interface and the orchestration, changing an underlying service may require less user retraining. You gain access to more workflows, but you may lose some of the protection that comes from being where people spend their day.

An API alone is therefore a weak answer to the competitive problem. The service behind it still needs to earn its place through results, useful data, domain expertise, reliability, or support.

Pricing also needs attention. If an agent performs work that previously required people to navigate an application, the relationship between named users and delivered value deserves another look. Charging for transactions, capacity, or outcomes may fit some products better, although each introduces its own problems. Customers need predictable costs, and a billable “outcome” needs a definition both sides can defend.

None of this means a different interface automatically changes an existing license obligation. Commercial terms remain part of the buying decision.

It does mean vendors should work out how to get paid for the capability customers value, even when customers prefer somebody else’s front door.

Build versus buy becomes a decision about layers

The most useful change to my original article is to stop treating an application as one indivisible purchasing decision.

A business could build a tailored experience, buy specialized domain functionality, and retain Dynamics as its system of record. Another could use an existing interface and build a narrow piece of orchestration that its industry requires.

For example, a homebuilder might own the selections experience because that experience differentiates its customer service. It could still buy maintained product content or specialist configuration logic and use its ERP for purchasing and financial transactions.

The evaluation becomes more specific:

• Which part of the experience actually differentiates our business?

• Which capabilities require expertise we want someone else to maintain?

• Where must business rules be enforced, regardless of the interface?

• Who owns failures between the components?

• What would replacing each component really require?

That fourth question deserves more attention than it usually receives. A process assembled from five excellent products can still fail between them. Someone has to own diagnosis, recovery, and the customer conversation.

I would also tighten a couple of assumptions from the 2024 article. ISV solutions are not automatically plug-and-play, and custom development does not come with unlimited scalability. Both depend on design, implementation, and ongoing investment. A subscription does not remove integration work, and owning the code does not make a support team materialize.

AI changes the effort involved in parts of that work. It does not remove the ownership decision.

The cost of building includes the years after the demo

A cheaper initial build can make a custom solution worthwhile. That is a real opportunity, especially for a narrow workflow with clear boundaries and a team capable of supporting it.

The calculation still needs to include validation, security, monitoring, upgrades, recovery, and the business changes that arrive after everyone has celebrated go-live.

When comparing a subscription with an internal build, compare the responsibilities on both sides. A vendor may be maintaining integrations, interpreting domain changes, handling exceptions, and answering support calls. Or it may be charging a premium for a thin feature that your team can now own economically. Those deserve different answers.

The same scrutiny belongs on the internal estimate. “We built it over the weekend” establishes that something was built over the weekend. It tells me very little about whether it handles duplicate requests, partial failures, incorrect permissions, or next year’s requirements.

Before calling the savings real, assign a named owner, fund the ongoing work, and test the failures that matter to the business.

The next build-versus-buy meeting should spend less time admiring how quickly the prototype appeared and more time deciding which responsibilities the organization is prepared to carry.

The demo is cheaper now. Somebody still gets the call when month-end doesn’t balance.

Until next time,

DynamicsDad