Is it time to build?

“We’re a retailer, not a software company.”

Anyone who has made the case for custom software inside a retail or hospitality business will have heard some version of this objection. It is often read as cultural resistance or a lack of ambition. It may be better understood as a rational response to the economics of these industries.

Build versus buy is primarily a question of risk and reward. Building proprietary software has usually meant a large upfront investment, with little certainty about when it will be delivered or whether it will work. If it creates a lasting competitive advantage, the returns can be substantial. Integrating a SaaS product costs less up front, pays back sooner and produces far more predictable outcomes. However, competitors can buy the same product on the same terms, which limits the upside.

For a business that earns a few cents on every dollar of sales, the choice has usually been clear.

In retail and hospitality, the reluctance to build software has less to do with culture than with margins.

AI-assisted development is beginning to change some of the inputs to that calculation. It lowers the cost of building software and shortens the time it takes to learn whether a product works. At the same time, the major enterprise platforms are opening up through APIs and agent interfaces, making it possible to build on top of trusted systems rather than replace them.

Two questions follow:

• Has AI changed the cost and risk of software development enough to make proprietary builds a sensible investment for a thin-margin retailer or hospitality operator?
• Will software shaped by a company’s own employees and customers prove more effective than products designed to serve many businesses at once?

Most of the examples in this note are drawn from retail. Hospitality shares the same thin margins and operational focus, and the argument applies to both.

For much of the last fifty years, retailers and hospitality operators have improved their economics primarily through operations: greater scale, lower costs, faster inventory turns, better labor scheduling, stronger purchasing terms and more productive stores, restaurants and hotels.

These improvements carry risk, but it is risk that can be measured. A retailer opening its fiftieth store, or a restaurant group opening its fiftieth site, can estimate sales from comparable locations, forecast staffing, negotiate a lease and model the downside. If the location underperforms, stock and equipment can be moved or sold. Rent, labor, fit-out and working capital are known exposures with a long history behind them. Expansion is not risk-free, but its risk is quantifiable.

R&D has the opposite profile. It requires cash to be committed now in exchange for the possibility of better cash flows later, and both sides of that equation are uncertain. Development may overrun. The product may not work. Customers may not adopt it. Even if they do, the value it creates is difficult to predict.

Known expenditure against an unknown probability of an unknown payoff.

It is therefore far easier to approve $10 million for an expansion program backed by dozens of comparable stores or restaurants than the same amount for a software product with no comparable history.

Thin margins reinforce this. Among US-listed companies, grocery retailers earn a net margin of around 1.3% and general retailers around 5.6%, compared with roughly 25% for software companies.¹ Hospitality is in a similar position. The National Restaurant Association puts a typical restaurant’s pre-tax margin at around 5% prior to the pandemic, and 42% of operators reported being unprofitable in 2025.²

When margins are this thin, protecting existing cash flow becomes the priority, and any investment with an immediate downside and an uncertain upside faces close scrutiny. The low level of R&D spending in both sectors reflects this.³

That caution is well founded. A study of more than 5,400 IT projects by McKinsey and the University of Oxford found that large projects ran 45% over budget and 7% over time on average, while delivering 56% less value than expected. Some 17% of IT projects went badly enough to threaten the company’s survival.⁴

Flyvbjerg and Budzier found that one in six IT projects became a “black swan”, with an average cost overrun of 200%. Retail has its own example. An IT overhaul at Levi Strauss, budgeted at under $5 million, led to the closure of three US distribution centers for a week and a $192.5 million charge against earnings.⁵

For a finance director, the spread of possible outcomes is often a greater concern than the average. A proprietary build has a deep trough. Capital and delivery risk accumulate for several quarters before any value is returned, and the final result may land well above or well below the plan.

A SaaS integration pays back sooner, within a much narrower range. It then levels off. Because every competitor can buy the same capability on the same terms, it rarely becomes a lasting advantage.

In a thin-margin business, the depth and width of that trough matter more than how high the curve might eventually climb.

Taken together, these factors create a loop. Retailers and hospitality operators with little differentiation earn low margins. Low margins reduce the appetite for uncertain investment. They therefore continue to choose the lower-risk option, which brings lower returns and the same tools their competitors use. When the next opportunity arises, they are no more differentiated than before and have no more capital available to invest.

Each individual decision to buy is sensible. Together, however, these decisions cause competitors’ technology to converge, and differentiation has to come from elsewhere. Often that means price, which puts further pressure on margins.

Buying also carries less visible costs. The average organization now runs 305 SaaS applications.⁶ Products sold to thousands of customers are designed around the typical one. A widely cited vendor study found that around 80% of their features are rarely or never used.⁷

Employees on the shop floor and in the dining room see problems that will never appear on a vendor’s roadmap.

Store and restaurant teams see the friction that no vendor is likely to prioritize: the replenishment exception that takes twenty minutes every morning, the click-and-collect handover that frustrates customers, or the delivery order that reaches the kitchen in the middle of the dinner rush. Some retailers and restaurant brands already treat proprietary software as a source of advantage. Domino’s developed its own point-of-sale and ordering platforms, which it describes as a competitive advantage, and now takes more than 85% of its US retail sales through digital channels.^8,9 Walmart builds tools for store employees on its own machine learning platform. Early estimates suggest one shift-planning tool has cut planning time from 90 minutes to 30.¹⁰

The most common claim for AI-assisted development is speed. The evidence supports it, but it is more mixed than the headlines suggest. Field experiments at Microsoft, Accenture and a Fortune 100 company found that developers using AI completed 26% more tasks.¹¹ A trial at Google found that tasks took around 21% less time.¹²

However, a 2025 trial by METR found that experienced developers working in large codebases they knew well were 19% slower with AI, despite believing it had made them faster.¹³ METR’s 2026 follow-up points to speed gains, though METR itself describes the result as unreliable.¹⁴ Google’s DORA research links AI to higher throughput but also to less stable delivery, concluding that “AI doesn’t fix a team; it amplifies what’s already there.”¹⁵

The case for building should not, therefore, rest on AI making developers dramatically faster. The more important change is to the shape of the investment.

AI makes small bets affordable. A small team can put a working prototype in front of frontline employees or customers within days, learn whether it helps and then decide whether to continue. Small projects have always succeeded more often than large ones. The Standish Group found that 61% of small projects succeeded, compared with 6% of the largest.¹⁶ By lowering the cost of each step, AI allows more of a program to be structured as a series of small, reversible steps rather than a single large commitment.

Building also no longer means replacing core systems, which are becoming platforms to build on. In April 2026 Salesforce launched Headless 360, stating that “everything on Salesforce is now an API, MCP tool, or CLI command.”¹⁷ A retailer or hospitality operator can therefore keep the systems of record it trusts and build a thin layer on top that is specific to its own operation, shaped by its employees and customers.