AI Solutions: Build, Buy, or Configure?
The Technology Decision That's Flipping Convention On It's Head
Where your competitive advantage sits determines everything else.
The conversation usually starts in the wrong place. A board member asks about AI strategy, someone mentions a vendor demo they saw, and within minutes the discussion has become about features, pricing, and implementation timelines, while the fundamental question gets skipped entirely: should we be building this, buying it, or configuring something that already exists?
I’ve watched this happen across multiple businesses, and the pattern is consistent. The decision gets framed as a technology choice when it should be a strategic one. Get it wrong and you either waste money building something you could have bought, or you hand competitive advantage to a vendor who will sell the same capability to your competitors.
Systems of record versus systems of differentiation
The distinction that matters is whether the system creates competitive advantage or simply keeps the lights on.
Systems of record, things like HR platforms, finance systems, and core ERP, are largely the same across organisations, with processes standardised by regulation or professional practice, which means building these from scratch makes no sense. You buy them, configure them to your needs, and move on, because the value comes from what you do with the data they produce rather than from the system itself.
Systems of differentiation are different, encompassing the operational systems where your specific way of doing things creates advantage: how you forecast demand, how you allocate inventory, how you price, how you plan ranges. Here the integration between your data, your processes, and your decision-making is the product, and buying a generic solution means accepting generic outcomes.
At Travis Perkins, we built WholeHouse from scratch because nothing on the market did what we needed.[1] The platform allows small housebuilders to configure houses from pre-designed components, generating BIM data that flows directly into materials scheduling, costing, and delivery timing. The competitive advantage came from the integration: Travis Perkins’ unique position as both the design platform provider and the materials supplier. No vendor was selling that because no vendor could.
The new inversion
Conventional wisdom says small businesses buy off-the-shelf because they lack development capability, while large enterprises build custom because they have resources. The emergence of AI tools has inverted this.
Small businesses now have the ability to build lightweight AI workflows quickly and cheaply using tools like Claude Code for development and N8N for workflow automation, and a motivated founder with a clear problem could have something working in days rather than months, which has collapsed the barrier to experimentation entirely.
Large enterprises face the opposite pressure. Integration complexity across multiple systems, data governance requirements, and the need for enterprise-grade security and compliance make buying platforms more attractive, not less. Recent research suggests 76% of enterprises have stopped building AI in-house, with most custom-built solutions never making it past the pilot stage.[2] Internal builds that promised six-month delivery timelines stretched into multi-year projects, while off-the-shelf solutions delivered value in weeks.
The retailers making the most progress are doing something more nuanced: Walmart built its demand forecasting neural network entirely in-house because that’s where competitive advantage sits,[3] but they bought Cropin’s agricultural AI platform for produce sourcing because that’s specialised capability they didn’t need to own.[4] Nike acquired Celect for demand sensing rather than building from scratch, then integrated it deeply into their operations,[5] and the pattern across both is consistent: buy or acquire where capability exists, build where integration creates unique value.
The trap nobody warns you about
Here’s where growing businesses get caught: you start with a low-cost experiment using accessible tools, it works well enough that people start depending on it, you layer on more functionality, and before you know it you’ve got a business-critical system that was never designed to be one.
The organisational memory problem is real. If you’ve built workflows, prompts, and tacit knowledge around how a tool works, migrating becomes a change management problem as much as a technical one. One retailer wanted to switch AI platforms after year one but discovered it would take eighteen months to extract and retrain their data. A financial services firm found their vendor’s price increased 300% in year three, but switching would cost more than paying.
This is the spreadsheet problem all over again. Someone builds an Excel model to solve an immediate need, it becomes the source of truth, and five years later the business is running on a workbook nobody fully understands and everyone is terrified to touch.
The step change in cost from a home-brew solution to an enterprise-grade system is often prohibitive, which means growing businesses need to make a conscious decision early about whether this is an experiment or infrastructure. If it’s infrastructure, design it properly from the start, and if it’s an experiment, put boundaries around it so it doesn’t accidentally become something it was never meant to be.
The integration problem nobody talks about
There’s another trap waiting for businesses that buy multiple AI-enabled tools without thinking about how they fit together.
If you’ve got an AI-powered demand planning tool from one vendor and an AI-powered allocation tool from another, and they’re both generating forecasts based on different models and assumptions, you end up with systems arguing with each other, a conflict nobody designed that emerged from buying best-of-breed without considering how the pieces connect.
I’ve seen this pattern in manual forecasting processes where different functions create their own forecasts in silos, with sales holding one view, supply chain another, and finance a third, leading to predictable and unproductive arguments. AI automates this problem rather than solving it, giving you the same circular disagreements but faster and with more confident-sounding numbers.
The end-to-end platforms from vendors like Blue Yonder, o9, and RELEX exist partly to solve this problem, and while they’re not always the best at any single function, they avoid the integration nightmare of bolting together multiple point solutions. Whether that trade-off makes sense depends on how much of your competitive advantage comes from the planning process itself.
A design principle worth following
Before committing to any AI platform or building anything yourself, ask whether your data architecture will survive a change of tool.
The principle is straightforward: keep your data layer separate from your application layer. If your data is clean, well-governed, and stored independently, switching the AI tool on top becomes a software decision rather than a data migration nightmare. If you’ve let the tool become the de facto data store, or if the tool has created its own derived data and logic that doesn’t exist anywhere else, you’re locked in.
This isn’t always possible and it adds complexity to implementation, but it’s worth asking the question before you commit.
Questions to ask before deciding
Before your next AI investment decision, work through these:
Where does competitive advantage actually sit in our business? If the answer is operational execution, think carefully before handing that to a vendor who will sell the same capability to your competitors.
Is this an experiment or infrastructure? If it’s an experiment, put boundaries around it, and if it’s infrastructure, design it properly from the start.
What happens to our data if we change tools in three years? If the answer is “we lose it” or “it would take eighteen months to migrate,” you’re making a long-term commitment, whether you intended to or not.
Do we have multiple AI tools that will be generating forecasts or recommendations? If so, how will we resolve conflicts between them?
What’s the total cost of integration, not just the platform? Connecting AI tools to legacy systems, workflows, and reporting often costs more than the AI itself.
The boards that get this right don’t start with vendor demos or feature comparisons, they start with a clear view of where competitive advantage sits and work backwards from there.
This is the seventh article in my series on practical AI for operators. Previous articles covered where AI adds value, when not to use it, accountability in algorithmic decision-making, experimentation and scaling, why pilots succeed and rollouts fail, and the data quality constraint. Subscribe for the rest of the series.
References
[1]: Travis Perkins WholeHouse platform:
https://wholehouse.uk
[2]: Beam.ai Agentic Insights: “76% of enterprises have stopped building AI in-house” https://www.beam.ai/agentic-insights/ai-build-vs-buy
[3]: Supply Chain Dive: “Walmart uses a multi-horizon recurrent neural network, built entirely within Walmart, to predict demand” https://www.supplychaindive.com/news/4-walmart-supply-chain-ai-uses/760891/
[4]: Cropin press release: “Walmart partners with Cropin for AI-powered produce sourcing” https://www.cropin.com/press_release/walmart/
[5]: Business Wire: “NIKE, Inc. Acquires Data Science and Demand Sensing Expert Celect” (August 2019) https://www.businesswire.com/news/home/20190806005928/en/NIKE-Inc.-Acquires-Data-Science-and-Demand-Sensing-Expert-Celect