Build, Buy, or Neither? The Enterprise Decision Guide

One question shapes almost every enterprise technology decision: do we build this ourselves, or do we buy it from a vendor? Historically, the answer was shaped mostly by budget and timeline. However, the advent of AI has made that decision more nuanced. Instead of deciding simply between custom development and off-the-shelf solutions, enterprises now have to consider whether to build, buy, or add an AI capability. But there is a fourth possibility that is often overlooked: neither. Sometimes the right technology decision is not to build, buy, or add anything at all – because the problem does not justify a new system or capability.

Ashish Mantri, Vice President – Strategic Operations at Dotsquares, has spent much of his career on both sides of this decision – as someone delivering technology and as a strategist advising businesses on what to build in the first place. Dotsquares has been executing web, mobile, and enterprise projects globally for more than 24 years. Over that time, Ashish Mantri has watched multiple technology trends play out, including the current one in which every other proposal seems to arrive with an AI feature attached, irrespective of whether the problem actually needs one. His view on why technology decisions succeed or fail is refreshingly unglamorous. More importantly, it has little to do with the technology itself and more to do with how clearly the business problem was defined at the outset.

The Question That Matters More Than “Can You Build This?”

Ask Ashish Mantri about the biggest mistake businesses make when choosing a technology partner, and his answer doesn’t reach for vendor selection criteria or technical due diligence. It’s about the question companies ask in the first place.

“One mistake I see quite often is that companies select a partner based on ‘Can you build this?'” he says. “For me, that is no longer enough.” The better question, in his view, is whether the thing should be built at all – and that’s a question most vendors are structurally uninterested in asking because their business model depends on saying yes.

A technology partner that behaves like an order-taking development team will build almost anything a client asks for. A partner worth working with, Ashish Mantri argues, pushes back first: What result is actually expected? What could go wrong? And does a simpler path exist? He is direct about what that sometimes means in practice. 

“Sometimes the best advice we can give a client is actually: don’t build it.” That advice costs the vendor short-term revenue. It is also, he believes, what builds trust over time – a trade-off that fewer companies are willing to make than those that claim to.

Ashish Mantri weighs a short list of questions when evaluating technology decisions: Does it solve a real problem? Does it create value? Will people actually adopt it? And does the return justify the investment? Adoption, the last filter, is where he sees technically sound projects quietly fail. Software can be built exactly to specification and still be a failure if the people it was built for never use it.

“Buy the Standard. Build the Advantage.”

When it comes to the actual build-versus-buy decision, Ashish Mantri doesn’t overcomplicate it. He follows a principle simple enough to fit on a whiteboard: buy the standard, build the advantage. In his view, there’s little value in spending time and budget rebuilding something that hundreds of companies have already solved well – accounting systems, standard CRM tools, HR platforms, ticketing systems. These are commodity problems with commodity solutions, and treating them as anything else is usually just an expensive way to reinvent a wheel that already rolls fine.

In his framework, custom development belongs somewhere else entirely: in the small set of processes that actually differentiate a company from its competitors. That’s a narrower category than most businesses assume, and Ashish Mantri thinks the framing of “custom versus off-the-shelf” as opposing choices misses the point. “I don’t believe the future is simply Custom vs Off-the-Shelf,” he says. “I believe it is Core Platform plus Custom Advantage.” He proposes a simple rule of thumb: run the common 70 to 80 percent of the business on proven products, and put the custom development budget only into the smaller slice that can genuinely move customer experience, efficiency, revenue, or competitive position. Done well, that split lets a business move quickly in areas that do not provide competitive differentiation, without diluting investment in the areas that do.

It’s a useful discipline precisely because it can easily be ignored under pressure. 

Deadlines and internal politics push teams toward building everything in-house, or toward buying platforms that promise to do everything at once. Ashish Mantri’s framework forces a harder, more specific question for every system a business is considering: Is this one of the few things that actually sets us apart, or is it just infrastructure everyone else already has?

From “Where Can We Use AI?” to “What Will AI Actually Improve?”

Nowhere has that discipline mattered more in recent years than in AI adoption, and Ashish Mantri has watched the client conversation shift in real time. He says many conversations once started with a version of “Where can we use AI?” Increasingly, the opening question is different: “What will AI actually improve?” That’s a small change in wording with a large change in intent – one starts from the technology and looks for a use case, while the other starts from a business outcome and asks whether AI is the right tool for it.

Ashish Mantri describes AI maturity in three stages. The first is AI as a feature – chatbots, content generation, search, recommendations – the stage most companies have already adopted in some form.

The second, which he sees businesses moving into now, is AI as a digital worker: systems that read information, complete repetitive tasks, update records, prepare reports, and support teams directly rather than just answering questions. In short, this phase executes entire workflows. The stage he considers most valuable has not fully arrived yet: AI as a decision partner, capable of understanding a business’s own data well enough to flag what actually needs a person’s attention – and explain why.

According to Ashish Mantri, the third stage is where he expects much of the real business value to eventually emerge. But he’s equally clear that arriving there prematurely, or forcing AI into a proposal because it’s the expected feature to include, produces the opposite of value. His test for separating a genuine AI use case from a trend-driven one is blunt: “If I remove the word AI from this proposal, is the business case still strong? If the answer is yes, we probably have something worth building. If the answer is no, we may just be buying excitement.”

The Common Thread

Strip away the AI-specific framing, and Ashish Mantri’s build-versus-buy philosophy and his AI-adoption filter are really the same idea applied twice. Both start by refusing to take the stated request at face value – whether that request is “build us a custom platform” or “add AI to this.” Both insist on tracing the request back to an actual business outcome before committing resources to it. And both accept that the more disciplined answer is often the less exciting one: buy the standard system, skip the AI feature, or say no to the build.

After 24 years of delivering technology across markets and industries, that discipline is arguably the most durable insight Ashish Mantri offers – not a prediction about where AI or software architecture is headed, but a reminder that most expensive technology mistakes trace back to a question that was never clearly defined at the outset.

Sometimes the smartest technology decision is to build. Sometimes it is to buy. And sometimes, the most valuable decision is neither.

Article Contributed by Ashish Mantri, Vice President – Strategic Operations at Dotsquares