Build vs buy in retail: 5 factors, and what AI changes

Build or buy. Every retailer faces this decision when choosing a platform for their store teams. The answer has changed since most people last looked at it.

The question used to be mainly about cost and control. Now it also involves AI, which has made building look easier than it is. So here are five factors worth weighing before committing either way, and a straight answer on what AI actually replaces.

Start by reframing the question

At enterprise scale, though, the binary is misleading.

Buying is rarely plug and play, because you are not switching something on. You are licensing a configurable platform and shaping it around your processes, hierarchy and ways of working. Building is rarely from scratch either. It usually means assembling parts that were never designed as one system, then maintaining the connections between them.

Therefore the real choice is narrower. Either you buy something already built to work as one system and configure it. Or you assemble the parts yourself, then write the connecting code indefinitely.

Factor 1: What you would actually be building

Most build conversations picture the interface, so start there. The interface is the small part.

In practice a working store operations platform needs six things. Data ingestion across POS, workforce management, inventory, product master and traffic, each with its own schema. Agreed KPI definitions and ownership across functions that currently disagree. Prioritization logic that ranks competing signals against available labor hours. Execution rails, meaning store hierarchy, roles, permissions, assignment logic, offline capability, photo capture and notification routing. Frontline adoption. And attribution robust enough to show whether an action moved the number.

Integration alone is therefore a multi-quarter program. Research into retail IT estates puts POS integration at six to twelve months. ERP and warehouse management integration runs nine to eighteen. Data extraction and pipeline work consumes 60% to 70% of project budgets. RAND Corporation research found something similar. Data engineering and cleaning account for roughly 80% of the effort in delivering production machine learning systems. Buying does not remove this work, but it does mean connecting to systems through existing integrations rather than building each connection from nothing.

Factor 2: Where building genuinely wins

Building is the right answer for some things. Pretending otherwise only makes the rest of the argument weaker.

Gartner’s pace-layered application strategy separates enterprise software into three tiers. Systems of record, such as ledgers and core POS engines, change slowly and should be bought. Systems of differentiation, such as markdown optimization or proprietary fulfillment logic, evolve faster and suit a hybrid approach. Systems of innovation move in months and are best assembled from modular components.

Meanwhile Geoffrey Moore made the same distinction more simply in Dealing with Darwin. Core activities differentiate you in the mind of the customer. Context activities are everything else you need to stay in business.

So build your pricing logic. Build your category strategy. Build anything that genuinely separates you from the retailer across the street. The question is whether a task list, a store visit form and a photo upload belong in that category. For most retailers they do not, because no shopper has ever chosen a store because of its internal audit tool.

Factor 3: The build is the smaller number

This is where internal business cases usually go wrong, because they price the wrong thing.

Lientz and Swanson established the proportion in 1980, and Boehm confirmed it a year later. Maintenance accounts for 70% to 80% of a system’s lifetime cost. Development velocity has changed enormously since then. That proportion has not.

Retail feels this more acutely than most sectors, because the budget is moving the wrong way. McKinsey found US enterprise technology spending grew roughly 8% a year between 2022 and 2024. Retail IT spending contracted by more than 1% a year. Over the same period retail labor productivity rose nearly 4%. Retail technology teams are being asked to deliver more from a shrinking budget.

Maintenance also compounds over time. McKinsey puts technical debt at 20% to 40% of the value of an enterprise’s technology estate. Organizations then pay a 10% to 20% penalty on every new project budget, purely to work around what already exists. Thirty percent of CIOs surveyed said more than a fifth of their new product budget goes on debt-related defects.

The structural reason is simple arithmetic. Point-to-point connections between systems scale quadratically. Ten systems can require up to forty-five interfaces, while twenty-five systems can require three hundred. Every schema change upstream breaks several of them.

Factor 4: Adoption decides whether any of it matters

Adoption is the factor nobody scopes, and it is usually what kills internally built frontline tools.

Corporate engineers build for the environment they work in, since that is what they know. Dedicated logins, reliable connectivity, desktop navigation, time to learn an interface. Store floors, however, work differently. Devices get shared between shifts. Backrooms swallow signal, hands are full, and turnover means the interface has to be obvious rather than learnable.

Consequently internally built store tools tend to fail in predictable ways. Corporate email logins that hourly staff do not have. No offline caching, so a stocktake in a concrete backroom loses its data. Double entry, where an associate logs something in the new tool and again in the system that actually matters. When that happens, teams revert to paper, whiteboards and WhatsApp, and the task list stops reflecting what is really happening in the store.

David Jones therefore tested this deliberately. They ran a four-month pilot with 400 to 500 store managers first. Only then did it go out to 6,000 frontline employees.

Factor 5: What AI changes, and what it does not

AI has made building feel more achievable. A model can now read a legacy codebase in hours and explain what it does. That is real, and it changes part of the picture.

McKinsey QuantumBlack studied this directly. Using AI to inspect, document and refactor legacy code can accelerate modernization by 40% to 50%, while cutting debt-related costs by around 40%. The same research is clear about the condition attached. Those gains come from using AI to extract business logic and build modular interfaces. They do not come from translating old code into a new language. Straight translation moves the existing problems into a newer framework, which McKinsey calls the code-and-load anti-pattern.

AI also does not remove any of the six components in factor one, though. A model still needs clean ingestion, agreed KPI definitions, execution rails and an adopted mobile experience. If anything it adds cost, because inference, monitoring and evaluation are running expenses that conventional software never carried. That is the case for consuming AI through a platform where those foundations already exist, which is how AI-powered performance is built.

So can AI replace legacy or in-house retail operations tools?

Partly, although the distinction matters more than the headline.

AI does not replace a running system of record in one step, and no serious architect recommends trying. The established approach is to encapsulate core systems behind interfaces, then retire the layer above them piece by piece. What gets replaced is the compensating layer. That means the spreadsheets, the internal dashboards, the paper packs and the homemade tools. All of it was built because the real systems were never designed for the shop floor.

In practice, that pattern shows up consistently. Morrisons retired paper communication packs and a document holding hundreds of links to Google Sheets and PDFs. They kept their existing store hardware, tablets and back-office systems. They also integrated Bluetooth temperature probes and in-store shelf cameras. Pilot Company kept SharePoint and connected it, then added a ServiceNow integration for maintenance tickets.

By contrast, the homemade tools are the ones that go. Lagardère Travel Retail replaced an obsolete in-house duty-free execution tool across more than 20 countries. DFS Group reviewed over 200 pieces of overlapping content and homemade tools during consolidation. PureGym consolidated seven separate operational tools into one platform and cut regional manager email traffic by 58%.

Systems of record stay. The layer built to compensate for them is what AI and modern platforms actually replace.

How to decide

Work through it in order, because sequence matters here. Establish whether the capability differentiates you commercially or simply keeps the business running. Ask what share of your requirements a commercial platform already meets. Widely used procurement guidance suggests buying above roughly 80%. Below 60%, building makes sense where the gap is genuine advantage.

Then price the full decade rather than the first year, remembering that maintenance is the larger share. Ask who maintains it when the engineer who built it leaves. Finally, ask how the tool will be adopted by someone on a shared device with their hands full. Other retailers have already worked through this, and their customer stories show what they kept and what they retired.

Start retailing smarter

Book a DemoSee how other retailers decided