Cutting through the noise on enterprise technology decisions
Technology questions executives ask in 2026 sound the same as they did five years ago — should we build or buy, cloud or self-host, what should we do about AI — but the right answers have moved. The pace of platform change has accelerated, AI has reshaped the cost side of nearly every “buy” calculation, and the early enthusiasm of 2023–2024 has hardened into more honest numbers. According to recent industry analysis, roughly 42% of companies scrapped AI initiatives in 2024 — up from 17% the prior year — most often because timelines slipped and stakeholder patience ran out before the project delivered measurable value.
The questions below are the ones we hear most often from operators trying to make actual decisions, not the abstract ones that fill conference panels. Each gets a direct answer, the trade-offs that matter, and a practical framework for thinking it through yourself.
Should we build it or buy it?
This is the most asked and most consistently mishandled question in enterprise technology. The mistake is treating it as a cost calculation rather than a strategy question. The right framing is simpler than most build-vs-buy matrices suggest: is this capability part of how we compete, or part of how we operate?
Capabilities that sit on your critical user journey, that compound proprietary data over time, or that directly shape your differentiation deserve internal investment. Everything else — email infrastructure, expense reporting, HR onboarding, document signing, payroll — should be rented from a vendor whose entire business is that one problem. The pattern most companies fall into is the inverse: building bespoke internal tools for commodity functions, then outsourcing the work that should be a competitive moat.
For AI specifically, the same logic applies, but the numbers are sharper. Building your own AI capability brings heavy fixed costs — specialized engineers, data pipelines, evaluation tooling, infrastructure — that typically only pay off if the capability is core to your competitive position. A useful rule of thumb circulating in 2026: buy unless you have at least six dedicated engineers and twelve months to reach feature parity with what’s already on the market.
How do we actually evaluate a new tool without getting burned?
Most tool evaluations fail in predictable ways. The team relies on vendor demos that use cleaner data than yours, skips reference calls, underestimates integration work, and ignores switching costs. A disciplined evaluation looks different. Five steps reliably separate the tools that earn their seat from the ones that quietly become shelfware.
First, define the specific business metric this should move, and by how much. Not “improve productivity” but “reduce ticket resolution time from 18 hours to 8” or “cut close cycle from 12 days to 5.” Without a target, you’ll never know if it worked.
Second, capture the current-state baseline in measurable terms before any pilot starts. Most teams discover, six months in, that they can’t prove improvement because they never measured the starting point.
Third, run a time-boxed pilot with real data and a real team — never the vendor’s demo environment. Edge cases that don’t appear in canned demos are precisely where most tools break down. Test with your hardest scenarios, not the easy ones.
Fourth, calculate total cost of ownership over a three-year window. Include integration cost, training time, ongoing maintenance, security review overhead, and an estimate of switching cost when you eventually want to leave. Vendor list price is rarely the meaningful number.
Fifth, ask for two reference customers with use cases similar to yours, and actually call them. Ask specifically about the support experience after the sale, the renewal process, and what they wish they’d known before signing. Most vendors will provide friendly references; the useful information is in the texture, not the headlines.
Cloud, on-prem, or hybrid?
The cloud-versus-on-prem question used to be ideological. It isn’t anymore. Each has clear use cases, and the right answer is usually a hybrid that reflects the actual workload profile.
Cloud wins when workloads are bursty, when your team lacks deep infrastructure expertise, when you need compute faster than a multi-week procurement cycle, or when utilization is below roughly 60% — at which point on-prem break-even extends well past eighteen months and the math stops working. Cloud also wins for genuinely experimental workloads where you don’t yet know what hardware profile you’ll need at scale.
On-prem or dedicated infrastructure wins when workloads are sustained at high utilization, when data residency or regulatory constraints force it, when latency requirements are extreme, or when GPU spend has grown large enough that capital purchase economics dominate. For most enterprises in 2026, the practical answer is: start in cloud, establish a utilization baseline over 90 days, then evaluate selectively bringing high-utilization workloads on-prem once you have real data.
How should we approach AI right now?
Three things to know. First, the companies extracting real value from AI in 2026 are not the ones with the most sophisticated models. They’re the ones who have done the unglamorous work of cleaning their data, mapping their workflows, and rewriting specific processes to take advantage of what current models can do. The technology is largely commoditized; the operational discipline isn’t.
Second, the failure rate of enterprise AI projects has gone up sharply, not down, even as the underlying models have improved. The reason is consistent: teams launch broad transformation initiatives without a clear baseline metric, without an owner of the redesigned workflow, and without an honest 90-day checkpoint. The companies winning pilot narrowly, measure ruthlessly, and only scale what beats baseline.
Third, the build-versus-buy question is more nuanced for AI than for traditional software. Most enterprises should not be training their own foundation models. Many should be fine-tuning or building retrieval layers on top of vendor models. Almost all should be building application logic, prompt engineering, and evaluation infrastructure in-house — that’s where the proprietary value accrues. The architecture pattern that’s worked best in 2026 is a thin proprietary application layer on top of vendor model APIs, with disciplined evaluation tooling and clear ownership.
What about cybersecurity — are we doing enough?
Cybersecurity spend continues to rise at most enterprises, but the question isn’t whether to spend more — it’s whether you’re spending on the right things. The vast majority of breaches still come from a small number of root causes: stolen or weak credentials, unpatched known vulnerabilities, social engineering, and misconfigured cloud resources. Sophisticated zero-day attacks make headlines but represent a tiny fraction of actual incidents.
If you’re trying to allocate a security budget for maximum risk reduction, the unglamorous fundamentals dominate: enforce multi-factor authentication everywhere, maintain a current asset inventory, patch on a defined cadence, run continuous configuration scanning on cloud resources, and rehearse incident response. These are not where most of the conference attention goes, but they’re where most of the actual risk lives.
How do we manage technology vendor sprawl?
The typical mid-market enterprise now manages 100+ SaaS subscriptions, often with significant overlap, unclear ownership, and 20–40% of seats inactive. This isn’t a budget problem — it’s a security, compliance, and complexity problem. Each tool is a potential breach surface, a vendor risk review, and a piece of the integration map your team has to maintain.
Two practices that work. First, instrument actual usage — most SaaS tools either support this directly or can be measured via SSO logs. Cancel anything below a defined activity threshold. Second, run an annual portfolio review where every renewal of more than a modest amount is justified on its current value, not its historical purchase rationale. Companies that do this consistently typically reclaim 15–25% of SaaS spend in the first year and meaningfully reduce their vendor risk surface.
The thread running through all of these
Every one of these questions has the same underlying answer: technology decisions should follow strategy, not lead it. Start with what the business is trying to accomplish over the next two to three years. Identify which capabilities you need to own and which you can rent. Decide what success looks like in measurable terms before any tool purchase. Measure ruthlessly against that baseline. Be willing to kill projects that aren’t working, and willing to scale aggressively the ones that are.
The companies pulling ahead in 2026 are not the ones with the most ambitious technology strategies. They’re the ones with the clearest connection between specific business outcomes and specific technology investments — and the operational discipline to walk away from anything that doesn’t deliver.
