Why Companies Now Build Software They Once Bought

In McKinsey’s August 2026 survey, 32% reported their organizations had declined at least one software product or feature purchase in favor of an internal build using agentic coding. Software purchasing now has another contender at the approval meeting: a small application the company can commission itself through development accelerated by coding agents.

Between May 4 and June 8, McKinsey surveyed 1,719 participants in 97 nations, so the finding concerns reported decisions across a varied corporate sample. Since the question combines products with features, its result supports a narrower conclusion than wholesale subscription replacement. Procurement teams now have evidence for putting an internal build on the shortlist; the survey leaves each project’s financial outcome for a separate assessment.

The Purchase Boundary Moves to the Feature

In an illustrative equipment-supplier case, warranty staff use a purchased application to decide which repairs qualify for reimbursement according to individual customer contracts. The supplier wants an approval rule based on an installed component’s age and the customer’s contract tier. If the application’s next pricing tier carries several unrelated capabilities, the company faces a question smaller than replacing its entire software estate.

Instead of rebuilding the purchased application, an engineering team could create a narrow approval component connected to the supplier’s existing customer records. Contract administration would remain in the purchased product. For employees, the custom component would calculate the proposed reimbursement and route exceptions to a named approver. Since the company’s warranty policy determines eligibility, someone accountable for reimbursement decisions must interpret the policy for the engineers.

Developers can delegate implementation work to coding agents while retaining responsibility for reviewing the resulting changes and approving their release to the live application. For agent-generated pull requests, GitHub’s review guidance calls for human scrutiny. Once code production becomes easier to commission, management’s judgment shifts toward the software’s required behavior and the people available to maintain it.

Price the Same Business Requirement

The build vs buy software comparison becomes useful when both proposals cover the same operating requirement over a period long enough to include maintenance. For the equipment supplier, a fair comparison would ask both options to process the same contract rules. If a proposed custom component handles only the common cases, its estimate needs an allowance for the remaining exceptions.

A Three Year Illustration

For an illustrative cost comparison, the supplier’s purchased option costs $36,000 annually; a custom component requires $48,000 to develop and $18,000 annually to operate. Provided both options cover equivalent scope, the three-year totals reach $108,000 for the purchase and $102,000 for the build, with equal migration costs excluded. The apparent $6,000 saving leaves a thin financial margin for extra work.

Within these assumed annual budgets, licenses and vendor support are included in the purchase; the custom component’s allowance pays for hosting and engineering maintenance. Both estimates allow for routine security updates. For urgent repairs, the annual total needs an extra allowance whenever either proposal lists a separate charge. Until repairs finish, employees need an agreed fallback process for claims awaiting a reimbursement decision. The company can then compare proposed repair times with the longest interruption its reimbursement team can tolerate.

If annual operating expenditure for the custom component reaches $26,000, its three-year total rises to $126,000 while the purchased option remains at $108,000. The $8,000 annual difference reverses the initial ranking. To assess the estimate, finance needs evidence supporting the engineering time allocated to repairs. If a repair estimate omits expected staff hours, finance needs another calculation.

Subscription savings enter the business case when the supplier can actually reduce its contractual payments, which may occur at a renewal date several months after launch. Until renewal, the company may pay for both applications. If the custom component replaces only a proposed upgrade, the financial benefit is the avoided upgrade price; the existing subscription remains an operating expense.

Put Revision Timing in the Estimate

Custom development can still be economically attractive when the purchase carries a lower quoted price, particularly where frequent policy revisions affect customer promises or margins. If a revised warranty agreement takes effect next month, its reimbursement ceiling needs to enter the application on schedule. Late implementation would create incorrect approvals for repairs processed after the revised agreement takes effect. To price a delayed change, management can multiply the affected repair volume by the average reimbursement difference.

For a purchased product, the relevant evidence includes its configuration options and the supplier’s contractual route for requesting changes to business rules. Procurement can test the proposed configuration against the company’s actual exception cases. Where a modest configuration change satisfies the approval requirement, the custom component’s revision advantage shrinks.

Integration Decides Where the Work Lands

The equipment supplier’s custom component needs access to current contract terms, so its development budget must pay for a tested connection to the existing customer database. Prior to implementation, the team needs to assign ownership for the approved contract record. When a customer renews an agreement, the approval component needs the revised terms prior to processing the next claim; a delayed update could authorize a reimbursement using obsolete information.

Permissions introduce another design decision when the custom component reads contract details used by employees whose authority differs between the supplier’s regional offices. Prior to release, engineers need to test an ordinary employee’s access alongside an administrator’s access. If a reimbursement decision is disputed, the company needs a record linking the approval to the applicable contract version. Procurement can ask a software vendor to demonstrate equivalent evidence.

When a purchased product already exchanges the required data through a supported connection, its vendor’s maintenance arrangements may make the integration expense easier to estimate. For a custom component, the connection’s upkeep belongs in an assigned engineering workload. To test the estimate, finance can request the engineering hours required to accommodate a customer database’s revised authentication method.

The Repository Needs a Business Owner

Once a custom component can approve reimbursements, the company is relying on software to apply its customer agreements to decisions authorizing real expenditure. GitHub’s guidance on reviewing AI-generated code recommends automated checks alongside human review. For new software packages, reviewers are asked to examine maintenance and license compatibility. The business owner still has to judge the reimbursement rule’s correctness.

If engineers are to test the supplier’s warranty policy prior to a production release, they need cases with approved expected results. For a component replaced during an earlier repair, the policy owner must specify which date governs eligibility. The engineer then has an approved calculation to test. If the policy’s language permits competing interpretations, management needs to resolve the commercial question prior to approving the code.

Maintenance authority deserves an explicit agreement when an internal team or an external development partner is expected to support the application after its launch. Who can approve a policy revision, and who can release the corresponding code? To repair the live application, an available engineer needs permission to edit its code and release the correction.

Approve the Ownership Arrangement Alongside the Build

The proposal for this supplier would connect a specific commercial requirement to a funded maintenance arrangement, with an accountable owner for the warranty policy. For the procurement demonstration, the company could supply two difficult repair cases. Commercial reviewers would check the decisions against the contracts. Alongside this business review, engineers would examine the data connection and the procedure for releasing a correction.

OPERENDIA’s digital engineering work includes custom business applications and ongoing maintenance, which places this procurement question within the relationship between a company’s promise and its operating behavior. For the equipment supplier, a useful project brief would state the reimbursement rule and the desired change schedule. The next conversation can then assess who will own the application when the customer’s agreement changes.