The most revealing technology decision is sometimes the one that never becomes a launch announcement.
Arjun Wadwalkar, Director of Product Management at Global Payments, once faced a version of it on a compressed timeline. A distributed fleet of point-of-sale devices needed a reliable way to install applications, manage updates and support different operating systems remotely, and the business needed an answer quickly.
Building a proprietary device-management platform was possible. It would also have required considerable engineering time, specialist expertise and long-term maintenance. Buying an existing product looked faster, but only if a vendor could satisfy the company’s requirements for security, compliance, architecture and cost.
Wadwalkar led the evaluation. His team tested competing products through end-to-end workflows, examined their ability to support Android, Windows and iOS devices, and involved security, compliance and architecture teams before making a selection. The evaluation was completed in a matter of weeks, and negotiations substantially reduced projected costs.
“The question is not whether a vendor can produce an impressive demonstration,” Wadwalkar says. “It is whether the capability can survive security review, integrate with existing systems and remain economical at production scale.”
It was not an artificial-intelligence project. But the decision behind it, whether to build a capability internally or rely on a specialist provider, is becoming one of the most important questions in enterprise AI.
Wadwalkar has spent much of his career working across software, payment systems, connected devices and product strategy. In 2026, he was named an Electronic Transactions Association Forty Under 40 honoree for his work in payments and connected-commerce technology.
His experience suggests that the familiar “build versus buy” debate is now incomplete. With AI, companies also need to recognize when an initiative should not move forward.
An impressive demonstration is not necessarily a useful product. A prototype may generate fluent answers, identify patterns or automate part of a workflow, yet still fail when it encounters incomplete data, security restrictions, unpredictable usage or the economics of operating at scale. The difficult question is not whether the technology works under ideal conditions. It is whether the organization should own it, purchase it or stop investing before a promising experiment becomes an expensive obligation.
Build where the advantage lives
There are circumstances in which building is the rational choice.
Earlier in his career at Global Payments, Wadwalkar led an internal research-and-development program focused on automating voice ordering for restaurant drive-throughs and phone orders. The work required more than connecting a speech model to a microphone. He developed the business case, defined the scope and milestones, secured stakeholder support and directed a cross-functional team. The program also involved examining existing drive-through hardware, designing conversational flows and building an analytics portal that could monitor successful orders, service availability and failures.
Even this build decision was not entirely internal. The team evaluated outside natural-language technologies, including Amazon Lex, Google Dialogflow and Microsoft speech-recognition capabilities. The goal was not to recreate every technical component. It was to retain control over the parts of the product that were distinctive: its interaction with restaurant hardware, the structure of the ordering conversation and its connection to an existing commerce platform.
Building an AI product does not necessarily mean training a proprietary model. It may mean owning the workflow, customer experience, integrations, operating data and business rules while using third-party models underneath. The decision depends on where the company believes its advantage resides.
When a capability is closely tied to a proprietary process, specialized data or customer experience, internal ownership can make sense. When the underlying technology is widely available and does not differentiate the business, building it may amount to repeatedly paying for a problem that another company has already solved.
Buying does not remove responsibility
Purchasing an AI product can appear simpler. It rarely is. A polished demonstration shows what a vendor wants a prospective buyer to see. An enterprise deployment reveals everything around that demonstration: data access, identity management, error handling, monitoring, integration, pricing and accountability when the system behaves unexpectedly.
The device-management selection led by Wadwalkar illustrates why buying technology is itself a product-management exercise. The work did not end with comparing feature lists. It required defining technical criteria, testing real workflows, reviewing vendor controls and understanding how the product would operate across a diverse hardware fleet.
The same scrutiny is necessary when purchasing AI. A vendor may demonstrate high accuracy, but that figure means little without understanding what data was used, which failures were excluded and how performance changes in the buyer’s environment. A low introductory price may become uneconomical as usage grows. A system that works with a small pilot group may create an unmanageable review burden when deployed across an enterprise.
The buyer also inherits dependencies that are easy to ignore during procurement. Model behavior may change after an update. A provider may discontinue a feature, alter its pricing or restrict how customer data can be used. Integration decisions made during a hurried pilot can become expensive architectural commitments. Buying transfers part of the engineering burden. It does not transfer accountability for the outcome.
Knowing when not to continue
The least celebrated product decision is putting an initiative on hold. Companies often continue AI projects because executives have already discussed them publicly, teams have invested months of work or a competitor appears to be moving faster. None of those reasons proves that the product should exist.
A credible evaluation should define its failure conditions before the pilot begins. What level of accuracy is required? How much human review can the business support? What will the product cost at full usage? Which errors are tolerable, and which create financial, legal or reputational risk? Who will own the system after the innovation team moves on?
“A pilot should have failure conditions before it begins,” Wadwalkar says. “If the economics, accuracy or operating model do not hold, continuing the project is not innovation. It is avoiding a decision.”
When those questions remain unanswered, a pilot can survive indefinitely by producing promising demonstrations without becoming a dependable product. Pausing or ending the initiative may be the most disciplined decision available.
This is especially true when an AI system does not address a sufficiently valuable problem. Some tasks can be automated but should not be. The efficiency gained may be smaller than the cost of integration, monitoring and exception handling. In other cases, a conventional rules-based system may be cheaper, clearer and easier to audit. The presence of AI does not automatically improve the business case.
A product decision, not a model contest
The build-or-buy conversation is often framed as a comparison of technical capability. Which model performs better? Which vendor has the longest context window? Which product scored highest on a benchmark? Those questions matter, but they come later.
Enterprise leaders first need to determine what they are prepared to own. Building creates responsibility for development and maintenance. Buying creates responsibility for vendor dependence and integration. Continuing a weak initiative creates responsibility for the money and attention it consumes.
There is no universally superior choice. A company may build the part of an AI product that differentiates its customer experience, buy infrastructure that has become a commodity and pause features that fail to produce measurable value. The strongest product strategy may involve all three decisions within the same initiative.
That is the less exciting truth behind enterprise AI. The defining capability is not launching the greatest number of pilots. It is recognizing which ideas deserve to become products, which capabilities are better entrusted to specialists and which projects should be reconsidered before enthusiasm turns into sunk cost. The demo shows what the technology can do. The product decision determines whether it belongs in the business.
