Custom Software, Reconsidered: A Smarter Framework for the Build-or-Buy Decision

A Question Worth Asking Twice

Every enterprise eventually faces it. A core system has aged past its useful life, a business unit needs capabilities the current software cannot deliver, or the backlog of workarounds has simply become too costly to maintain. Someone in the room suggests looking at products on the market. Someone else argues for building something tailored. The debate that follows is almost always framed the same way: Make or Buy?

It is a familiar question – and a useful one, up to a point. The trouble is that it bundles two distinct decisions into one, and that bundling is where expensive mistakes begin.

The make-or-buy framing implies a binary: either an organization’s own developers build it, or it acquires a product from a vendor. But the real decision space has two independent dimensions. The first is about fit: does a product exist that genuinely matches what the business needs, or does the process at stake require a solution designed specifically for that organization? The second is about capability: if custom is the right answer, who actually builds it?

Separating these two questions – and answering them in the right order – leads to materially better outcomes. And with Agentic AI now reshaping the economics of custom software development, the case for the custom path has never been stronger.

Where Products Fall Short

The appeal of buying a product is real – a market-proven platform promises faster time to value, a known cost structure, and someone else’s responsibility for infrastructure and maintenance. For many processes, that logic holds. Payroll, basic HR administration, travel expense management – these are commodities. Any large enterprise runs them the same way as any other. A well-chosen product handles them well.

The problem surfaces when the same logic is applied to processes that actually differentiate the business. The way an insurer prices and underwrites risk. The logic by which a bank segments clients and determines credit. The workflow through which a manufacturer coordinates custom production. These are not standard processes. They encode years of refinement, regulatory adaptation, and competitive learning. No product was designed to match them precisely – because no product can be designed for one company’s specific situation.

The implementation record is consistent:

• 55–75% of enterprise software implementations fail to meet their stated objectives (Gartner, Panorama Consulting Group)
• Among overrunning projects: average cost overrun 178%, average schedule overrun 230%
• Delivered functionality in overrunning projects: just 41% of what was planned
• Typical final cost: 3–4× the original budget

The root cause is almost never the product itself – it is the customization required to make the product fit a business it was not designed for. Customizing off-the-shelf software is expensive, and each new vendor release demands rework on that custom code; heavily customized systems often cannot be upgraded at all. The deeper the customization, the greater the long-term dependency on consultants and specialized support. The vendor’s product roadmap becomes the enterprise’s constraint. Competitive differentiation is gradually flattened toward the vendor’s lowest common denominator.

Products are not the problem. Applying them to the wrong class of problem is.

A Smarter Framework

The starting point is straightforward: ask two questions instead of one.

For commodity processes – payroll, HR administration, standard workflows – a well-chosen product is almost always the best answer. The goal is reliability and cost efficiency, not competitive distinctiveness. Products excel here. But for differentiating processes – the way an organization prices risk, segments customers, or coordinates production – custom software is the only path that makes sense. These processes encode competitive logic specific to that business. No product was built for such a specific situation. Attempting to force one to fit produces the failure patterns described above.

Once custom is clearly the right answer, the second question follows: who builds it? Here is where the traditional “make or buy” framing leaves a critical option off the table. “Custom” does not mean “an organization’s own IT department builds it.” It means software designed and built to specific requirements – and that work can be done by a specialist partner just as well as by internal engineers, often better. Internal teams are rarely set up to absorb a large custom build cleanly – capacity is finite, engineers carry responsibilities across multiple initiatives, turnover is a real risk, and the cost structure does not flex with project demand. A specialist partner, by contrast, brings focused expertise, accountability, and the ability to mobilize the right resources precisely when needed.

The third path – commissioning a partner to design, build, and maintain custom software – is the one that the “Make or Buy” framing omits entirely. The organization retains ownership. Business logic stays within the organization’s control. Delivery expertise is gained without carrying the fixed cost of building and sustaining that capability in-house. This option has existed for decades. Agentic AI has made its economics so compelling that it merits serious consideration before defaulting to internal development.

How Agentic AI Changes the Cost Equation

The traditional objection to custom software is cost and time. A product, however imperfect, can be deployed faster and – on paper – for less than a bespoke system built from scratch. That gap has narrowed significantly. In some scenarios, it has closed entirely.

Agentic AI – tools that plan, execute, test, and document across entire codebases with meaningful autonomy – is delivering 3–10× productivity gains on production projects, not in vendor benchmarks. From itestra’s own production projects in early 2026:

• ERP system, >1M lines of code: New feature developed autonomously including end-to-end tests – in under 2 hours
• Mainframe system, >1M lines of code: Complete architecture documentation generated – in 1 hour
• Across project types: 3–10× efficiency gains observed, with analysis and documentation tasks toward the higher end, complex feature development toward the lower

What previously required weeks of senior engineering time now takes hours. What required months can take weeks.

The consequence for the product-vs-custom decision is direct. When expert-built custom software can be delivered faster and cheaper than the effort of forcing a product to fit, the trade-off that once favored products largely dissolves.

That said, Agentic AI does not reduce the need for expert judgment. Code generated without deep understanding of business requirements, regulatory constraints, and architectural consequences is technically functional but strategically wrong – and it produces those wrong results quickly, which amplifies the damage. Productivity gains materialize reliably only where experienced engineers with genuine domain knowledge guide the AI at every critical decision point. That combination – Agentic AI in the hands of expert engineers – is what makes the new economics translate into reliable delivery.

Ownership as a Strategic Asset

Pure cost comparisons miss a critical dimension: ownership.

A custom system owned by the enterprise appreciates in value over time. Each feature added and each adaptation made brings the system closer to the organization’s actual competitive needs – the opposite of the vendor product path. Unlike a heavily customized product that grows more complex and fragile with each layer, a purpose-built system compounds in strategic value.

Consider what that means across the lifetime of the investment:

• Future development becomes faster and cheaper. The foundation is purpose-built for the organization’s context, not a market average. Changes align with business needs, not the vendor’s release cycle.
• Vendor lock-in is eliminated. The enterprise owns the code and the business logic. Strategic options remain in the organization’s hands.
• Upgrades stay under organizational control. No dependency on the vendor’s upgrade path. No worrying about compatibility breaking changes.
• Ongoing costs are predictable. The same partner who built the system maintains it under SLA – defined response times, deep knowledge of the internals, no handoff penalty.

The common objection – that custom software creates operational burden without a vendor to fall back on – misunderstands how modern expert partnerships work. A custom system maintained by the partner who built it delivers the flexibility of custom software combined with the reliability of managed support. It is neither a liability nor an ongoing project – it is infrastructure that compounds in value as the business evolves.

Across 20+ years and 90+ enterprise clients, itestra has built and maintained core custom systems on this basis – lean, precisely tailored to the business, free of unused product functionality, and straightforward to evolve as requirements change.

Where to Start

For enterprises currently navigating a core software investment decision, the right starting point is to be explicit about which question is actually being answered.

Is this a commodity process, where standard behavior is good enough and a product offers genuine value? Or is it a differentiating process, where the business logic at stake is specific to how the organization competes, serves clients, or manages risk? That answer should come before any vendor evaluation or internal capacity discussion.

If the answer is custom, the follow-on question – build internally or commission from experts – should be assessed honestly against current capacity, realistic timelines, and the full cost of each path including the cost of delay.

itestra’s Enterprise Business Solutions Health Check is designed for exactly this starting point. In one to two weeks, it maps the specific process landscape, identifies where custom software delivers the most value, assesses the realistic options for delivery, and frames the build-vs-commission decision with concrete cost and timeline estimates. Fixed-price, clearly scoped – analysis, not commitment.

What presents as a single decision almost always contains two. Getting the order right is what separates software that fits from software that merely functions.