Deciding Whether to Buy or Build Your Company Brain

‘I’m not saying we couldn’t build this,’ I heard one CIO tell his team in a recent meeting. ‘But I’d probably be retired or dead before it was actually working.’

He wasn’t being dramatic. This CIO runs technology for a very tech-forward $30 billion retailer. His team wasn’t debating whether they needed to build an intelligent management layer to close the gap between data and actions. That need was already settled, urgent enough that they’d stood up a dedicated initiative to solve it. What remained unresolved was how. Either spend years trying to build what Quorso does themselves, or buy it.

That’s the same choice retail leaders keep bringing to me when discussing the intelligent management layer (or ‘company brain’) I described in my last piece. Intelligent management uses data and AI to autonomously orchestrate work across a business: focusing humans on what matters, automating the low-value work, and joining up functions that today only connect when someone remembers that something needs to be done.

Why ‘build vs. buy’ is the wrong first question

It’s usually framed as binary. It rarely is.

Large organisations are complicated, which means the choice to ‘buy’ is rarely a plug and play SaaS product (which often stalls out inside big enterprises). It’s really ‘buy a highly configurable platform’—more like ordering a car from an OEM, choosing trim, colour, extras than picking one off the lot—that can be shaped to a company’s specific processes, culture, and ways of working, but stood up in days rather than years (e.g., Alteryx, Power BI, ServiceNow, UKG).

And ‘build’ rarely means starting from scratch either. It means stitching together a handful of tools that were never designed to work as one system (a bit like building a car from spare parts), then patching the seams as they show.

So the real ‘choice’ isn’t ‘build vs. buy’ in the abstract, it’s more specific: (1) buy a solution that’s already built to work well, or (2) buy something that’s frankensteined together and write code to fill the gaps yourself. It’s that more precise tension that actually stalls decisions, so it’s worth unpacking.

The four real reasons companies want to build their own

When I probe what’s really behind the instinct to build, I typically hear one of four things.

‘We don’t want to expose our IP’

In grocery especially, there’s a sense that certain ‘secret sauce’ algorithms (e.g., replenishment) or specific SOPs are the source of competitive advantage, and that working with a third party risks that knowledge leaking to a competitor.

I understand the instinct. But I think it’s overstated.

One top-5 global retailer we work with had a long-standing on-shelf-availability algorithm, built with a data science consultancy. Within the first three months on the job, a new graduate built an enhanced version with a 6% higher accuracy rate.

That’s not a fluke. ML and data science have advanced to the point where the algorithm itself usually isn’t the differentiator anymore. Most retailers feed similar data into similar models, and the machine converges on a similar answer regardless of who built it.

The real differentiator is harnessing the benefits of continuous execution: getting thousands of colleagues to actually act on what the algorithm recommends, and capturing the metadata from what happens next to keep improving it in a constant learning loop.

And if IP exposure is still a concern, there’s a simple fix. Deploy the third-party intelligent management layer inside your own infrastructure, with all its attendant security and permissions.

‘We can’t have data leave our environment/cloud’

Understandable. Leaked sales data could hand a competitor real intelligence. Or, for a public retailer, hand investors a trading edge ahead of results.

The concern is legitimate and deserves to be taken seriously rather than waved off. However, this is really a discussion about security controls. Any serious technology vendor should be able to satisfy an enterprise company on this front, rather than require that company to build a new solution from scratch.

In more detail, there are three main risks to address: data transport, data hosting, and infrastructure access. The first two can be addressed by encrypting data and applying stringent cloud provider security controls. The third is about controlling who at the third party can access the data and from where—managed through a combination of tenant and user provisioning, plus network-level controls like IP ‘allow-listing’ or private connectivity.

As with IP, deploying within your own infrastructure removes the concern entirely.

‘We want to own the end-user experience’

Fair enough, if you’ve already invested in a front end (e.g., your own task solution, wrapper app, or design library), it’s clear that you’re highly attuned to the importance of user experience, which drives user engagement.

However, the honest question is whether that front end is flexible enough to support everything an intelligent management layer actually needs to do. Not just tasks, but also alerts, events and opportunities with contextual data, different logic states, automation, and ongoing coaching workflows. Most aren’t there yet.

That’s why we built Quorso so it can sit inside a company’s existing app, rather than compete with it. It’s hugely configurable to match existing design libraries and themes, and integrated with applications like Teams and Outlook and external systems such as ServiceNow or UKG. It’s designed intentionally to optimise and complement the user experience so people actually want to use it.

‘We just want to build it ourselves’

This is the one most tech teams don’t say out loud. In my experience, it’s also the most common.

Top-tier enterprise retailers often have thousands of engineers, data scientists, and product managers at their disposal, and the engineers actually doing the work are rarely naive about how hard it is to build an intelligent management platform. They know better than anyone what it takes to ship something that holds up at scale.

The underestimation tends to happen among the business and technology leaders who scope the initiative, set the timeline, and approve the budget. Modern AI coding tools have revealed quite how simple a lot of well-known SaaS tools are, and how quickly ‘mainly front-end’ applications can be built. But AI has generally struggled to build complex back-end systems—heavy state, tight coupling, hard-to-verify ‘correctness’ requirements—of the kind intelligent management requires. This leads too many business and technology leaders to assume the next 95 percent of the build will be as easy and fast as the first 5 percent. Organisations thus underestimate the distance between a front-end MVP that supports one or two use cases, and an enterprise system that has to orchestrate hundreds of use cases across tens of thousands of people, every day, without breaking.

That distance is real.

It means solving prioritisation logic that can weigh dozens of competing signals. It means data integration across dozens of source systems (POS, workforce management, inventory, etc.) each with its own schema, and building the plumbing that keeps it all in sync without breaking. It means supporting several genuinely different kinds of triggers (deterministic, hybrid, probabilistic, and event-based). It means assignment logic that accounts for both role and user. It means a workflow builder flexible enough to route a customer complaint and a performance coaching conversation through entirely different approval chains. It means the ability to run compute-intensive analytics in parallel, at real scale, without slowing down the store floor operations the system is meant to serve. It means intelligent prioritisation that weighs company priorities against labour availability. It means robust statistical measurement and attribution, so a leader can tell whether an intervention moved the number, or the number moved on its own. And it means digital twins of core SOPs, so the system understands what should happen across each individual store.

None of this is impossible in isolation (though each includes considerable engineering and problem-solving effort). What’s hard is making all of it work together without falling over.

Quest—Quorso’s knowledge graph—puts a number on what it would take to build all that, and it’s sobering. Eighteen months of dedicated effort gets you a newborn brain: a blank canvas with no accumulated knowledge or judgement. Three years in, maybe a 3rd or 4th grader: capable of basic, supervised tasks, but not something you’d hand the keys to. A brain you’d genuinely trust to run a business: five years, minimum, and $50 million+. That’s before you’ve even added the domain expertise that makes it useful in the real world.

That’s exactly the gap the CIO I quoted at the top was staring down. His team could probably build something like this from scratch. But it would consume nearly all his resources, which is how you end up retired before it’s actually working.

And even if he got there, the spending wouldn’t stop on delivery. Keeping something like this running, patching it, extending it, and keeping it ahead of (or avoid falling behind) market innovation tends to cost tens of millions more, indefinitely. Build is the down payment. Maintenance is the mortgage.

He’s not an outlier. We track at least 18 top-tier retailers who have set off down the build path in recent years. By our count, only one has anything live in production. Even the ones that got furthest, including several of largest retailers in the world, have only solved for dynamic task reassignment instead of the full, multi-layer intelligent management platform they dreamed of. Twelve of those 18 are Quorso customers: retailers who built, spent, and ultimately chose to partner with us instead.

Is a company brain too strategic to outsource?

Underneath all four objections sits a fifth idea, usually unstated: that this is simply too strategic to hand to anyone else.

I’d push back.

What do you actually mean? Are you willing to invest in a solution as if you were a tech company? What exactly makes it too strategic?

Frontier models are strategic. Computers are strategic. ERP systems are strategic. They’re all essential to everyday enterprise operations. It’s many times easier to build a BI tool than an intelligent management platform. But almost nobody builds their own Tableau. They build on Tableau.

What you should actually be asking is whether you’re getting the best possible solution for your organisation’s needs. Whether you’re partnering with people who make you successful. Whether you’re moving at speed. And whether you’re staying ahead of competitors who partner rather than build.

Two questions to ask instead of ‘build or buy’

First: what’s the true time and cost to value? Not just the cost to build, but also the cost to maintain that I mentioned earlier: it’s the mortgage that keeps coming due long after the down payment clears.

Second: are you aiming at a fixed point, or committing to a multi-year journey that keeps moving? Intelligent management layers aren’t static products. They get smarter and more capable every year you’re on them. In the last year alone, Quorso has added voice UI, predictive use case set up, autonomous prioritisation, and agentic workflows (just to name a few new features) to constantly stay ahead of the market. The real risk is spending a ton of money, yet falling behind even more.

Which brings me to the point that matters most.

The bottom line: buy a brain that’s already trained

Build internally, and in the best case, say after five years of dedicated effort, you might reach something like two-thirds of where a mature platform already stands today. Meanwhile, the market keeps changing, and climbing.

Buying an intelligent management platform is less like buying an IT system and more like hiring a brilliant graduate: someone already trained, who gets sharper and more capable the longer they work with you, rather than starting from zero, and spending years just trying to catch up to where the rest of the industry already is.

One caveat: no vendor can sell you a brain that already knows your company inside out. The graduate still needs onboarding with your SOPs, your guardrails, and your data. But that’s true whichever path you take. The only real question is whether you’re also building the rest of the brain from scratch, or educating a brain that already knows how to think.