The Build vs. Buy Decision Has Changed Because of AI

A manager describes an internal workflow on Tuesday. By Friday, a developer has a convincing prototype. It accepts a request, checks a record, drafts a response, and updates the dashboard. The room sees three screens working and asks the obvious question: why would we buy another platform when we can build this ourselves?

That prototype may be the start of a good decision. It may also be the cheapest five percent of a system whose ownership lasts for years.

I like building software. I also know how easy it is to fall in love with the first visible result. AI shortened the distance from an idea to a demo. It did far less to shorten the distance from a demo to a dependable business system.

The ownership math in this decision is old. In my book it shows up as a friend's ice-cold patio in July and a two-line exchange about his new air conditioner:

"'What'd that set you back?' 'Like 10 or 12 grand. But our power bill dropped $80 a month too.'"

I had spent more than that keeping a 1988 unit alive, one heroic repair at a time. AI has cut the price of the repair visit, which is exactly why the patio math matters more now, not less. Creating software got cheap. Owning it, securing it, and operating it did not. Run the five-year number before you fall in love with the demo.

From The 3AM Test by Steve Copeland.

A prototype is not a system

AI is exceptionally good at compressing the distance between an idea and something visible. Leadership sees a working screen and assumes most of the cost disappeared.

The screen is rarely the expensive part.

The durable work is deciding which data is authoritative, how identity and permissions function, what happens when an integration fails, how changes are tested, who reviews generated code, how the system is monitored, and who answers when the person who prompted the first version leaves.

AI reduced creation cost. It did not remove lifecycle responsibility.

Buying changed too

The buy side is not standing still. Software vendors are adding AI features to products companies already own. Sometimes that removes the need for a custom tool. Sometimes it adds a premium license for a feature that does not understand the company’s process or data.

The relevant comparison is no longer simply custom development versus a SaaS subscription. The real options are:

• use an existing feature,
• configure an existing platform,
• integrate systems,
• automate a narrow step,
• buy a specialized product,
• build a focused application,
• or fix the process and do none of the above.

Any decision method that starts with only two boxes is already too small.

Where building makes more sense now

Building has become more attractive when the workflow creates real differentiation, the required scope is narrow, the company already owns clean data, and commercial products force people into a process that does not fit.

Internal applications are especially interesting. They do not need to win a public software market. They need to make a known group of employees faster, reduce an expensive error, connect systems, or create visibility that leadership lacks.

A focused internal tool can be valuable without becoming a software company.

Where buying still wins

Buy when the process is standard, the market is mature, regulatory updates are frequent, specialized vendors spread development cost across many customers, or the capability is not a source of differentiation.

Payroll is a good example. The fact that AI can generate payroll code does not make owning tax calculations, filing changes, payment movement, security, and support a good business decision.

The same logic applies to commodity security controls, accounting platforms, and many core systems of record.

The ownership test

Before approving a build, ask one question that AI enthusiasm tends to skip: who owns this in year three?

Name the person or role responsible for the product backlog, access model, data quality, testing, vendor dependencies, support, documentation, and retirement decision. Estimate that operating cost. If nobody wants the ownership, the company does not want the software. It wants the demo.

Use economics, not excitement

Compare three-year lifecycle cost, not first-version cost. Include licenses, implementation, integration, internal time, support, security review, training, change requests, downtime exposure, and exit cost.

Then value the upside: labor removed, errors prevented, revenue accelerated, risk reduced, and capability created.

AI belongs in the calculation because it changes speed and cost. It should not be allowed to erase the rest of the calculation.

The build-versus-buy decision did change. More options now require better discipline.

Put the options back on the table

Build versus buy sounds like a two-column exercise. Most real decisions have at least six paths: simplify the process, configure a current platform, integrate systems, automate one step, buy a specialist product, or build a focused application.

Start there. The broader list prevents a prototype and a vendor demo from becoming the only visible choices.

Suppose a 140-person company wants to reduce the time required to prepare customer implementation plans. Today, two coordinators gather data from the CRM, a survey, shared files, and a scheduling system. Each plan takes four hours and the company creates 40 plans a month.

The current labor load is 160 hours monthly. Rework adds about 20 hours. At a loaded rate of $48, the visible annual effort is roughly $103,680.

The first option is process repair: remove duplicate questions and standardize the source records. That cuts 35 hours a month for about $12,000 of internal and advisory work.

The second is configuration and integration inside products already licensed. Estimated implementation is $38,000, with $9,000 annual support. It should remove another 70 hours monthly.

A specialist SaaS product costs $54,000 a year plus $25,000 to implement. It covers most of the workflow but requires users to maintain another customer record.

A focused internal application costs an estimated $95,000 to build, then $24,000 a year to host, secure, support, and improve. It fits the workflow and can produce a customer-facing plan that becomes part of the service experience.

The answer depends on differentiation and ownership. If the plan is routine administration, configuration may win. If the plan embodies a method customers buy and the company will keep improving, the build carries more strategic value.

AI lowers parts of the build estimate. It does not decide which value story is true.

Use a three-year ownership sheet

For every path, calculate initial work, subscription or hosting, integrations, internal owner time, security review, testing, training, support, change requests, downtime exposure, and exit.

Then write assumptions beside the numbers. How many users? How many transactions? Which integrations? What service level? Which data class? How much annual change? A cost without assumptions becomes an argument later.

For the internal application above, the three-year cash cost might be $167,000: $95,000 build plus three years of $24,000 operating cost. Add 0.15 of a product owner's time, perhaps $54,000 across three years. The working total becomes $221,000 before major scope changes.

The SaaS path might total $187,000: $25,000 implementation plus three years of $54,000 subscription. Add integration maintenance and the cost of duplicate data. The gap narrows.

Now compare outcomes. If the custom application removes 110 hours monthly and the SaaS option removes 80, the difference is 1,080 hours over three years. At $48 an hour, that is $51,840 of additional capacity. If the custom plan also improves close rate or customer experience, quantify the evidence and uncertainty.

This is a decision model. It is not a promise that every saved hour turns into cash.

The first visible screen is a trap

A prototype proves that the team can produce a workflow. It does not prove identity, permissions, error handling, data quality, observability, accessibility, browser support, recovery, documentation, or support.

I have watched a five-day prototype become the production system because people began using it before those questions were settled. Temporary credentials became permanent. A spreadsheet became the database. The only developer became the help desk. Every later improvement had to work around choices made for a demo.

Set the boundary before the pilot. Use sample or approved data. Name the system owner. Record what the prototype is allowed to prove. Put a decision gate between demonstration and production.

A good prototype reduces uncertainty. It should answer questions such as whether the source data is sufficient, whether users follow the workflow, whether the integration can support the volume, and whether the expected time reduction appears. It should not smuggle an ownership commitment through excitement.

When a build earns its place

Building becomes attractive when the workflow carries real differentiation, the scope can remain focused, data is accessible and owned, and the company has someone who will direct the product after launch.

Look for repeated work where commercial products force a harmful compromise. Look for a customer experience that competitors cannot buy from the same catalog. Look for a decision method the company understands closely. Look for integration gaps whose value rises with every transaction.

Internal tools can clear this bar. They do not need a public market. They need a known user group, a measurable problem, and an ownership model that fits the value.

Build the smallest coherent product. A narrow application that solves one expensive handoff is easier to secure, support, and retire than an attempted replacement for the entire operating stack.

When buying remains the adult decision

Buy mature, regulated, commodity capabilities where a specialist vendor can spread responsibility across many customers. Payroll, tax filing, payment processing, mainstream accounting, identity platforms, and established security controls usually fit this category.

Also buy when speed matters more than differentiation, the internal owner is absent, requirements are standard, and an acceptable exit path exists.

The due-diligence work still matters. Check data rights, integrations, identity, logs, support, change terms, model training terms where AI is involved, export, deletion, resilience, and contract renewal. Buying transfers some work to a vendor. It does not transfer accountability for choosing and operating the product.

Treat AI-generated code like code

AI can help draft tests, explain unfamiliar code, generate routine components, and shorten integration work. The output still enters the same engineering system as human-written code.

Require review, dependency scanning, secret handling, test coverage, version control, deployment controls, logs, and a rollback path. Record licenses and third-party components. Keep production access away from casual prompting.

The faster code arrives, the more important the intake becomes. Speed without review increases the volume of decisions hidden inside the system.

The decision meeting I want

Bring one page with the current process, baseline numbers, six options, three-year cost, value range, material risks, owner, and next experiment. Spend the meeting challenging assumptions.

If the group cannot name a year-three owner, remove build from the active choices. If the vendor cannot export the data, price the exit risk. If configuration can capture most of the value in six weeks, prove it before funding a larger program.

End with a reversible next move. Clean the data, run a two-week prototype, request a contract term, or test the existing platform. A good decision process creates evidence before it creates commitment.

AI changed what can be built and how quickly you can learn. That is a genuine advantage. Use the advantage to compare more paths and test assumptions sooner. Keep ownership in the room.

Add an exit test before approval

For a purchased product, ask how data leaves, how integrations are removed, how long the vendor retains records, and what happens to custom configuration. Price the move. Contract language matters because the cheapest subscription can become expensive at exit.

For a build, ask whether another capable team can run it from the repository, documentation, tests, deployment process, and architecture record. Confirm that the company owns the code and needed accounts. Name the retirement path even when the product is new.

The exit test improves the current design. Systems that can be understood, exported, and retired are usually easier to operate.

Decide what the company is willing to own

Ownership has layers. A business owner prioritizes changes and measures value. A technical owner governs architecture, security, releases, and support. An operator handles incidents and routine administration. Finance owns the budget. Leadership decides when the capability no longer deserves investment.

One person may cover several layers in a small business. Write the names anyway. Hidden ownership becomes apparent when that person takes vacation or leaves.

I ask for a realistic monthly allowance after launch. If nobody can reserve time for user feedback, dependency updates, tests, access reviews, and small changes, the three-year cost sheet is missing its most important line.

Use staged commitment

Approve discovery first when requirements or data are unclear. Approve a prototype when the key uncertainty is usability or technical feasibility. Approve a pilot when you need evidence from real work. Approve production only when identity, data, support, security, recovery, ownership, and measurement are ready.

Each stage should have a question and a spending limit. "Can the data support this decision?" is better than "Build phase one." The company can stop when evidence weakens the case.

Staged commitment is especially useful now because AI makes early work inexpensive. Use that speed to learn, not to skip gates.

A final comparison page

Before signing, put the leading options side by side. Show three-year cash cost, internal time, time to first value, fit, differentiation, data position, integration, security, vendor dependency, owner, exit cost, and confidence.

Write the recommendation in plain language. "Configure the existing platform now, because it captures 75 percent of the value in eight weeks. Revisit a focused build after the data cleanup and six months of usage evidence." That is a decision people can remember.

The best answer may change as the evidence changes. A disciplined method makes that a strength.