Build, Buy, or Orchestrate? The Changing Economics of Business Software

For much of the past two decades, the default answer to a business software problem has been to buy another product.

Need better customer management? Buy a CRM. Need visibility into projects? Buy a project management platform. Need more consistent reporting, approvals, or customer onboarding? There is probably a SaaS product designed for it.

This model has worked remarkably well. Businesses gained access to sophisticated capabilities without needing engineering teams to build and maintain them.

But it also created a familiar operating environment: companies accumulate software, teams adapt their processes to the products they purchase, and information becomes distributed across an expanding collection of systems.

Each application might perform its intended function well. The difficulty often emerges in the work between them.

Now, AI-assisted software development is changing the calculation.

Capabilities that previously required substantial development resources can increasingly be prototyped by small teams. Internal applications, interfaces, integrations, and tailored tools are becoming more accessible.

The change is already influencing purchasing behavior.

In McKinsey's August 2026 State of AI survey, 32% of respondents reported that their organizations had decided against purchasing at least one software product or feature because they could build the functionality internally using agentic coding tools.

That is a meaningful signal. Software purchasing is no longer the automatic starting point it once was.

But a lower cost of building software does not necessarily mean a lower cost of operating it.

And that distinction should be central to how businesses make their next technology investment.

The cost of creating software is falling. The responsibility for it isn't.

A working prototype and a dependable business system are very different things.

It may now be possible to develop an internal application in days rather than months. That application can provide a tailored interface, connect to company data, and automate a previously manual task.

But what happens six months later?

A third-party integration changes. A pricing rule is updated. An employee discovers an exception the original design never considered. Someone needs access to information they were previously restricted from seeing.

The application still needs to work.

Someone must maintain its dependencies, protect its data, manage permissions, test changes, investigate failures, and decide which new requirements are worth implementing.

AI can assist with much of this work. It does not eliminate the organization's responsibility for the outcome.

This is where the economics become more interesting.

Historically, businesses paid software vendors to absorb much of that responsibility. The subscription purchased not just functionality, but continuing development, maintenance, security work, and operational support.

When a company builds its own solution, some of those responsibilities move back inside the organization.

That may be entirely justified. It may also be considerably more expensive than the initial development estimate suggests.

The question is no longer simply whether a business can build the software.

It is whether owning that particular capability is worth the continuing responsibility.

Three ways to solve the same operating problem

Consider a hypothetical B2B services company that regularly produces customized commercial proposals.

Its sales team manages opportunities in a CRM. Pricing is maintained in spreadsheets. Contract terms sit in shared documents. Finance approves certain exceptions through email.

Producing a straightforward proposal requires someone to assemble information from several places, verify the commercial terms, and obtain the necessary approvals.

Leadership wants to shorten the process and make it more consistent.

There are three plausible approaches.

1. Buy: Let a specialist provide the capability

The company could purchase a dedicated quoting or proposal-management platform.

A mature product may provide pricing configuration, approval workflows, document generation, CRM integration, reporting, and ongoing vendor support.

If the company's requirements broadly resemble those of other businesses, purchasing may be the most sensible choice.

The vendor has already invested in solving a common problem. Its product benefits from experience across multiple customers, a development roadmap, and an established support model.

But the company is also accepting the vendor's assumptions about how the process should operate.

Configuration may be more complicated than expected. Unusual commercial requirements may be difficult to accommodate. Additional integrations may be needed, and employees must learn another system.

The subscription fee is only one part of the cost.

Buying is attractive when the capability is relatively standardized and a vendor can operate it more effectively than the business could itself.

2. Build: Own the capability and its evolution

The company could instead develop a tailored internal quoting application.

It might draw directly from its CRM, apply company-specific commercial rules, generate the appropriate documents, and present exceptions for approval.

The application could reflect how the business actually sells, rather than requiring the business to adapt to a predefined product.

If its pricing logic is unusually complex, changes frequently, or contributes materially to how the company wins business, that control may be valuable.

AI-assisted development makes this option more accessible.

But the company would also need to own the software's continuing operation. Someone must understand its logic, maintain integrations, test changes, and respond when it fails.

That obligation becomes particularly important when a tool moves from being a convenience to something employees depend on every day.

A custom system that only one person understands is not necessarily a stronger operating asset than a vendor-managed product.

Building becomes attractive when the underlying capability is distinctive enough to justify ownership, and the organization can support it over time.

3. Orchestrate: Make existing systems work together

There is a third possibility that deserves more consideration.

What if the company already owns most of the functionality it needs?

Its CRM can manage opportunities. Its spreadsheet or finance system contains pricing information. Its document tools can generate proposals. Its existing communication platform can handle approvals.

The missing capability may not be another application.

It may be the ability to coordinate the ones already in place.

An orchestration layer could retrieve relevant information, apply defined rules, prepare the proposal, send exceptions to the appropriate approver, and update the underlying systems when the process is complete.

AI might help interpret unstructured customer requirements or prepare supporting information. Deterministic logic could enforce pricing boundaries and approval thresholds.

The company retains its existing systems of record while creating a more coherent process between them.

This can offer a lower-disruption route to improvement, particularly when the underlying applications already work well.

It is not free of operational responsibility. Integrations can fail, API limits can change, data can become inconsistent, and workflows still require monitoring and maintenance.

But it may avoid the larger commitment of adopting another platform or developing an entire application.

Orchestration is attractive when the necessary capabilities already exist, but coordination between them is the principal problem.

The economic mistake: comparing a subscription with a development estimate

Businesses evaluating these options can easily compare the wrong numbers.

A vendor presents an annual subscription price. A developer estimates the initial cost of building an alternative. An automation provider quotes the cost of connecting existing applications.

Those figures are useful, but they do not represent equivalent commitments.

A more meaningful comparison looks at what it costs to operate each option over time.

All three options also carry the potential cost of unreliable results, employee workarounds, or interrupted operations.

Consider an illustrative example.

A business produces 120 proposals each month. Each requires approximately 15 minutes of avoidable information gathering and manual entry.

That represents 30 hours of administrative effort every month.

At an illustrative fully loaded labor cost of $60 per hour, the activity consumes approximately $21,600 in annual labor capacity.

That figure establishes the scale of the problem. It does not mean the business would automatically save $21,600 by eliminating the work. Released capacity only becomes an economic benefit when it is put to productive use, avoids future hiring, or reduces actual expenditure.

It also does not justify purchasing a $50,000-per-year platform purely to address that administrative effort.

But suppose slow proposals are also causing missed customer deadlines, inconsistent margins, or delayed revenue. The case may look very different.

The same applies to a custom application or an orchestration project. The cheapest implementation may have high ongoing costs, while an expensive solution may prove worthwhile if it reliably improves a consequential business outcome.

The comparison needs to consider the complete operating cost and the value of the improvement, not simply which technology is cheapest to acquire.

The overlooked variable: how much change can the business absorb?

There is another factor that rarely receives enough attention in software investment decisions.

Reversibility.

A company implementing a new enterprise platform may commit to lengthy contracts, data migration, process changes, and extensive employee training.

A custom application can create its own dependencies, particularly when important business logic becomes embedded in code that only a small number of people understand.

An orchestration layer may offer a more incremental route, but it can also become difficult to replace if dozens of workflows depend on undocumented integrations.

Each approach changes how easily the organization can adapt in the future.

That flexibility has economic value.

When requirements are uncertain, an incremental solution may allow the business to learn what is genuinely needed before making a larger commitment.

When requirements are stable, well understood, and common across an industry, purchasing a mature product may avoid years of unnecessary development.

And when a capability is strategically distinctive, accepting the initial expense of owning it may provide long-term flexibility that a standardized product cannot.

The objective is not to avoid commitment altogether.

It is to make commitments that match the organization's actual needs, resources, and confidence in the problem it is solving.

Where should a company own its intelligence?

AI adds another dimension to this decision.

Historically, much of a company's operating logic has been distributed between software configuration, employee knowledge, documents, and established routines.

As AI becomes more capable of interpreting information and coordinating actions, businesses have more opportunities to make that logic explicit and reusable.

For example, an organization may have developed a distinctive way of qualifying opportunities, assessing commercial risk, allocating resources, or handling complex customer requirements.

Should that logic live inside a vendor's application? Should it be maintained in an internal system? Or should it operate across existing tools through a controlled orchestration layer?

There is no universal answer.

Vendor software can provide valuable capabilities without preventing a company from retaining ownership of its underlying data and decision rules. A custom-built application, meanwhile, does not guarantee independence if it relies heavily on external providers, proprietary services, or people the business cannot easily replace.

Ownership must be understood practically.

Who controls the underlying data? Who can change the business rules? Can the organization inspect how an outcome was produced? Can it migrate its information and operating logic to another system? Who is responsible when the process fails?

These questions may become more consequential as organizations accumulate experience with AI-enabled workflows.

The potential long-term asset is not simply an internal application or an AI model.

It is the company's ability to retain, improve, and apply the knowledge that makes its operations distinctive.

That is worth protecting where it creates a genuine advantage.

It is not a reason to rebuild every ordinary business function.

A practical way to make the decision

Before committing to a new product, custom application, or automation project, leadership should be able to answer five questions.

1. Is the capability standard or distinctive?

If hundreds of businesses need essentially the same functionality, a mature vendor may offer better economics. If the capability reflects an important competitive advantage, greater ownership deserves consideration.

2. What do we already have?

Identify which required functions are available in existing systems. The answer may reveal unnecessary duplication or an opportunity to connect capabilities already being paid for.

3. Where does the value actually come from?

Separate the benefit of the software itself from the benefit of improved coordination, faster decisions, fewer errors, or better customer outcomes. A new application is not valuable merely because it reduces the number of clicks.

4. Who will operate it after launch?

Every option requires ownership. Understand who will manage exceptions, maintain integrations, review performance, authorize changes, and respond to failures.

5. What is the least burdensome way to test the hypothesis?

A narrowly scoped integration, limited pilot, or targeted configuration change may provide enough evidence to justify a larger decision. Equally, when the need is well established and the capability is standardized, buying a proven product may be more sensible than conducting another experiment.

These questions make the build-versus-buy decision less ideological and more operational.

The likely answer is a combination

The growing accessibility of software development does not mean the end of SaaS.

Businesses will continue to benefit from purchasing reliable, specialized products. Few organizations should spend their resources rebuilding mature accounting, payroll, identity-management, or other standardized capabilities without a compelling reason.

At the same time, the ability to develop targeted applications creates opportunities to own capabilities that were previously uneconomical to build.

Between those options sits orchestration: using existing systems more effectively, introducing tailored logic where necessary, and avoiding unnecessary replacement of functionality that already works.

For many growing businesses, the strongest architecture will combine all three.

Buy the capabilities that are mature and standardized.

Build the elements that are genuinely distinctive and worth maintaining.

Orchestrate the work that needs to move across them.

The boundaries will change as technology improves, vendors evolve, and organizations learn more about their own requirements.

That is why the strategic decision is not simply which software product offers the most functionality today.

It is deciding where the business should depend on the market, where it should invest in its own capabilities, and how those choices should work together.

The falling cost of building software gives companies more options. The advantage will belong to those that become more selective about which options they exercise.

How Rivington approaches this

Rivington helps growing businesses evaluate these decisions at the workflow level.

Rather than beginning with a preferred product or technical architecture, we examine the operating requirements, existing systems, decision rules, ownership, and measurable business consequences.

From there, we help determine whether improvement calls for better use of existing software, targeted orchestration, new capabilities, or a broader system change.

The objective is a practical implementation decision grounded in how the business operates—not a technology investment justified by what has recently become possible.

Explore Rivington's AI Workflow Diagnostic.