AI Is Changing Build vs. Buy, But Ownership Still Matters

The First Build Is Only the First Bill

A technology leader can now reasonably revisit work that once looked too expensive to build. An internal service tool, supplier portal, planning assistant or commerce integration may be within reach of a smaller team using AI development tools. The opportunity deserves serious attention. A previous estimate is not a permanent argument for buying software, especially when the purchased product forces expensive compromises in how the business operates.

The mistake is to compare the price of a subscription with the effort required to produce the first version. Those are different units. The subscription usually includes some continuing product development and service operation. The custom estimate may include neither. A working screen can conceal unfinished work around access, reconciliation, support, recoverability, reporting and the next platform release. The economic comparison becomes credible when both options cover the same business obligation.

There is an equally weak argument on the other side: a retailer should buy because it is not a software company. A business that makes distinctive promises about availability, service, membership or fulfillment may need to control how those promises are implemented. Calling every custom capability a distraction can surrender useful differentiation to a vendor roadmap. Leadership needs to identify which responsibilities are worth retaining and which a supplier can perform more effectively.

That is the useful starting point for build versus buy in the AI era. Ask what has become cheaper to produce, what remains expensive to operate, and which decisions the company needs the freedom to change. The answer can differ across the same customer journey.

Separate Two Different AI Decisions

The first decision concerns AI-assisted software development. A team may use AI to inspect code, implement an integration, draft tests or explain a failure. The delivered system can still follow ordinary deterministic rules. A custom order-status service does not need to use a language model when customers call it simply because an AI tool helped engineers write it. Its production economics should reflect the software that actually runs.

The second decision concerns software that uses AI during the business process. A service assistant might interpret a customer request, retrieve order information and propose a resolution. That introduces continuing questions about model behavior, context quality, evaluation, usage cost and the authority to act. A vendor can package those capabilities, or a retailer can assemble them. Either way, their suitability must be demonstrated within the retailer's workflow.

This distinction prevents two distorted business cases. One assumes every custom application needs a continuing AI operating budget. The other assumes cheaper code generation proves that an autonomous workflow will be cheaper and better to run. Neither follows automatically. Development productivity and business performance should be measured separately before combining them into an investment recommendation.

DORA's 2025 State of AI-assisted Software Development research describes AI as magnifying existing organizational strengths and weaknesses. The implication for this decision is to examine the delivery environment alongside the tool: clear requirements, understandable systems, review capacity and reliable release practices influence whether faster implementation becomes useful business change.

Draw the Boundary Across the Commerce Ecosystem

Consider an exchange journey. The customer sees a simple request, but the business may need commerce order history, point-of-sale receipts, order-management status, warehouse availability, payment eligibility, tax treatment, loyalty balances and service records. Enterprise resource planning must receive the financial consequences. Analytics must distinguish an exchange from an incremental sale. Each connection brings business rules and recovery obligations into the apparent scope of a small feature.

Other journeys draw on different systems. A wholesale ordering portal may depend on account hierarchies, contract pricing, credit limits and allocation. A campaign assistant may need content approval, customer consent, segmentation and suppression rules across CRM, customer data and marketing platforms. A store associate tool may depend on identity, inventory, appointment scheduling and customer service. Product information and digital assets matter, but they are part of this wider system.

Map these dependencies before choosing a delivery model. For every important fact, name the authoritative source. For every business action, identify the service permitted to commit it. For every customer promise, identify who handles a disagreement between systems. This prevents a custom application from quietly becoming a second order ledger, a second promotion engine or an unofficial record of consent.

The boundary should also show where a delay is acceptable. A management report might tolerate yesterday's figures, while a stock reservation cannot simply borrow that assumption. If the proposed design depends on freshness or availability that the source system cannot provide, changing the interface supplier will not solve the underlying problem.

When Buying Earns Its Place

Buying is attractive when the capability is broadly standard, the product fits the operating requirements, and the supplier can sustain it more effectively than an internal team. A mature service may bring tested transaction handling, administrative tools, deployment processes and specialist support. Those benefits have value even when an AI tool could reproduce part of the visible experience quickly.

Evaluate the responsibilities that actually transfer. Does the supplier maintain the connector or only provide a starting template? Does support investigate a failed order through completion or stop at its own API response? Are release compatibility, monitoring and recovery included in the proposed scope? A feature checklist will not answer these questions. Contract commitments, implementation responsibilities and a practical incident walkthrough are more useful evidence.

Cloud infrastructure offers a clear illustration. AWS's shared responsibility model explains that customer responsibilities vary with the services selected, while data and permissions still require customer management. The broader procurement lesson is to make the division explicit. A managed service can reduce operating work without taking ownership of the retailer's business decisions.

Buying can also create expensive constraints. A product that fits the current market may require awkward workarounds for another country, channel or acquisition. Assess the probable next set of requirements before treating configuration as effortless. A low implementation quote is less persuasive if essential business changes require custom work inside a vendor-controlled extension model.

When Building Is Worth Owning

Building deserves consideration when the business needs a capability that standard products handle poorly, and the difference has a credible effect on customer value or operating economics. Examples could include a specialized service decision, a distinctive fulfillment allocation method or a wholesale approval flow shaped by the company's commercial model. These are candidates to investigate, not automatic reasons to create another application.

Test the supposed differentiation with business owners. Does the unique workflow protect margin, improve a valued customer promise or remove a material constraint? Would customers or operators notice if the organization adopted a standard process instead? A legacy exception supported by a vocal department is not necessarily an advantage. Sometimes process simplification is the better investment, even when custom implementation has become easier.

Then assess ownership capacity. The company needs people who can explain the design, review changes, manage dependencies and recover the service when the original author is unavailable. Source code in a company repository is helpful, but it does not prove the organization can operate that code. Documentation, access, operational knowledge and continuing engineering capacity are part of what the build decision purchases.

AI can help a capable team handle more implementation work. It can also create more software than that team can responsibly maintain. Set an explicit budget for the number and criticality of custom services the organization will own. Otherwise, many locally sensible projects can accumulate into a portfolio that exceeds support capacity.

The Build, Buy and Ownership Map

Hybrid is often a sensible answer, but it needs more definition than buying the core and building around it. Specify which system records the transaction, where the retailer's distinctive decision lives, which services can be replaced, and who owns the complete workflow. The architecture should make these boundaries understandable to operations as well as engineering.

For example, the retailer might own how a service recovery offer is selected while relying on established order and payment services to execute permitted actions. The custom component should receive the facts it needs, return a bounded decision and leave transaction authority where it belongs. If it fails, the team should know whether work can continue manually and how to reconcile anything already committed.

A hybrid design can become the most complicated option if the business owns extensive customization while still accepting the supplier's constraints. Require a clear reason for each custom boundary. If the split does not improve control, economics or customer outcomes, it may simply distribute complexity across more teams.

Compare Equivalent Economic Obligations

Build the comparison over a horizon that fits the decision, with the same scope, service expectations and expected volumes for every option. Include discovery, implementation, migration, integration, platform fees, infrastructure, model usage where applicable, support, security, evaluation, training and retirement. Show when the cash is required as well as the total. A lower long-term estimate may still be impractical if it consumes scarce capacity during a critical trading period.

Make business change visible. Promotions, country expansion, warehouse changes, acquisitions and service-policy revisions can all require software work. Buying may package some changes into product releases and charge separately for others. Building gives the team discretion but requires the capacity to exercise it. Ask each option to handle the same two or three plausible changes rather than assigning a vague contingency percentage with no explanation.

Keep exception economics explicit. Imagine, as a hypothetical planning example, 20,000 eligible service cases a month. If five percent require eight minutes of additional handling, that creates about 133 hours of work. Those are illustrative assumptions, not a benchmark. The calculation shows why a small exception rate can materially affect a business case. Test the rate and the handling effort with representative work before using either in a budget.

Use low, expected and stressed scenarios. Vary demand, supplier usage charges, integration effort, review needs and time to release. Distinguish cash savings from time that becomes available for other work; both can matter, but they are not interchangeable. The preferred option should remain explainable when assumptions move. If a small change reverses the result, leadership is making a contingent choice and should document the condition that would trigger reconsideration.

The Unpopular Opinion: More Build Capacity Can Justify Buying

Cheaper implementation does not make every software category strategically worth owning. In fact, it can strengthen the argument for buying well-supported common capabilities: a capable internal team now has more valuable custom opportunities competing for its attention. The relevant comparison is what the team could accomplish elsewhere, including the continuing obligations each project creates.

This position has limits. A supplier that blocks necessary change, prices an essential capability poorly or prevents the business from inspecting critical behavior can make ownership worth the effort. Buying is not a permanent default, and building is not a badge of maturity. Revisit both when the facts change. The discipline is to protect scarce expertise for responsibilities the company has a reason to retain.

Leadership should therefore review the portfolio as well as individual projects. Ten small custom tools may each pass a project-level return calculation while collectively leaving no capacity for peak trading, platform changes or incidents. An ownership budget exposes that constraint before it becomes an operational surprise.

Unpopular AI opinion: a better ability to build can be a stronger reason to buy. When your team can create more valuable differences, spending its ownership capacity recreating standard capabilities becomes harder to justify.

JM Digital Corp

Maintenance Starts With the Next Change

Maintenance is broader than fixing defects. It includes dependency updates, access reviews, platform compatibility, data-contract changes and adjustments to business policy. A supplier may perform some of this work for a packaged capability. A custom component still needs a person or team to detect change, assess its impact, validate behavior and coordinate release. Include that responsibility in the design and operating agreement.

For a concrete example, Shopify documents a quarterly release schedule for its versioned APIs and a minimum twelve-month support period for stable versions. A retailer that builds an integration must plan for compatibility work; a retailer that buys one should confirm who performs and verifies it. The precise policy varies by platform, so inventory the dependencies actually used instead of applying one provider's schedule to the whole estate.

AI-dependent behavior adds another change surface. A revised model, retrieval configuration, prompt or tool definition can affect accepted outcomes even when the surrounding screen is unchanged. Maintain versioned evidence for the workflow and rerun relevant evaluations before expanding exposure. Buying an AI feature should include a discussion of notice, testing access and response options when the supplier changes underlying behavior.

Also plan for people leaving. A service that only its original author can release is operationally fragile regardless of code quality. A useful handover exercise asks another qualified person to explain the dependencies, investigate a seeded failure and recover the workflow using the available documentation.

Controls and Evaluations Belong in the Price

Give a purchased feature and a custom feature the same acceptance cases. Include incomplete inputs, stale information, duplicate requests, denied permissions, supplier outages and requests outside policy. Evaluate the resulting business state as well as the response shown to the user. A reassuring confirmation message is not evidence that the order, payment and customer record agree.

Transaction handling illustrates the distinction. Stripe documents idempotency keys for safely retrying supported requests without repeating an operation. A workflow still has to manage its own intent and resulting state across other systems. In a refund journey, establish which request is the same attempted refund, when to retry, and how to discover a committed result after a timeout. Do not let an uncertain response become an invitation to start again blindly.

For AI that can call tools, authority needs particular scrutiny. OWASP identifies excessive functionality, permissions and autonomy as causes of excessive agency. Apply this to procurement and implementation: a service that only needs to explain eligibility should not receive unrestricted transaction access. Approval and authorization rules should be enforced by the application and underlying services, rather than relying solely on instructions to the model.

The NIST Generative AI Profile provides voluntary guidance for considering trustworthiness across design, development, use and evaluation. For this investment decision, the practical requirement is a named owner, relevant evaluation evidence and a response when observed behavior falls outside accepted limits. These costs belong in both the purchased and custom options.

Three Scenarios, Three Different Boundaries

Consider three hypothetical retail situations. First, a growing retailer needs a conventional returns portal, has limited engineering capacity and can use standard eligibility rules. Buying could be the strongest starting hypothesis if the product supports its order, warehouse and financial flows. The proof should focus on reconciliation, exception handling, support coverage and usable data exports. Rebuilding familiar screens offers little advantage if the team then inherits a critical service it cannot comfortably support.

Second, a specialist distributor sells against customer contracts with unusual allocation and approval needs. Standard portals could distort a commercially important workflow. Building the account-specific decision layer may be justified while retaining established ERP, identity and payment services. The critical evidence is that the unusual behavior creates value and can be maintained as contracts change. Every exception should not become permanent custom logic without an accountable business owner.

Third, an omnichannel retailer wants AI assistance for service recovery. A hybrid approach could buy the service workspace and underlying model capability while owning policy evaluation and bounded actions against order systems. Begin with recommendations that trained employees review, then assess whether specific actions warrant more automation. The retailer must determine how consent, customer history, store activity, delivery events and financial adjustments remain consistent.

None of these examples establishes a universal winning architecture. A stronger internal team, a better-fitting supplier or a different commercial strategy could change the recommendation. Their value is in showing how the decision boundary moves with differentiation, operational consequence and ownership capacity. Record those reasons so the business can recognize when the original choice has stopped fitting.

Exit Options Need Operating Evidence

Ask what leaving would actually involve. For a purchased service, examine available exports, identifiers, configuration, workflow history, relevant logs, retention arrangements and transition support. Commercial and legal teams should establish appropriate contract terms, but engineering and operations must test whether the resulting material can support a transition. A file download alone may omit relationships or history essential to the next system.

Custom software also has dependencies. Owning the repository does not eliminate reliance on a cloud service, model provider, specialized library, proprietary data store or the people who understand it. Identify which dependencies are reasonable to accept and which deserve a replacement path. Avoid building abstractions for every hypothetical supplier change; target the dependencies whose failure or commercial movement would materially constrain the business.

Run a small exit exercise before the commitment becomes difficult to reverse. Export a representative record set, reconstruct a workflow elsewhere or substitute a service behind a controlled interface. Document gaps and estimate the remaining work. This will not guarantee a frictionless migration, but it turns portability from a sales statement into something the team has inspected.

Ownership is the practical ability to explain a decision, change its implementation and recover its consequences when something goes wrong.

JM Digital Corp

Measure the Outcome and the Ownership Burden

Define the accepted outcome before testing an option. For exchanges, that might mean a policy-compliant replacement with consistent inventory and financial records. For a wholesale portal, it might mean an approved order with the correct terms and allocation. The denominator should include eligible work, rejected attempts and exceptions so the solution cannot appear successful merely by completing the easiest cases.

Track cost per accepted outcome alongside completion time, rework, service contacts and business-quality measures such as avoidable concessions or fulfillment errors. Compare similar work over a useful period, accounting for channel mix and seasonality. Do not attribute every improvement during the rollout to the software; changed staffing, policy or demand can also affect results.

Add ownership measures: support effort, time to diagnose failures, change lead time, compatibility work and the number of critical components understood by more than one person. These reveal whether the solution becomes easier or harder to sustain. A custom capability may deserve a higher operating cost because it produces distinctive value. A purchased capability may deserve its fee because it reliably removes work. Both conclusions require evidence beyond adoption or release counts.

A Practical 30, 60 and 90-Day Decision Path

AI gives retail leaders a reason to reconsider assumptions about what their teams can create. The useful response is a better decision process: identify the business difference, price the complete obligation and assign the capacity to own it. Bring that evidence into the platform discussion before the first delivery estimate becomes the investment case. The right choice should remain defensible when the system is changing, trading is busy and the original project team has moved on.