Build vs. Buy: How Finance Teams Make the Decision in Practice

The Promise of Building In-House

We all know the scenario: an internal tool is not working well, IT proposes to “build something custom,” and management agrees – because it sounds like control, flexibility, and independence.

The arguments are always the same: “We know best what we need.” “No software is a 100% fit.” “Long-term, we save on license fees.” So how does that play out in practice?

What the Numbers Show

According to the Standish Group, only 31% of custom IT projects succeed – measured by time, budget, and scope. Gartner puts a number on total cost: for every dollar spent on development, another 4–5 dollars go into maintenance and evolution.

Even large enterprises with substantial budgets are not immune: Lidl spent over seven years and more than €500 million on a custom SAP adaptation – only to replace it with an off-the-shelf solution in the end. Nike lost over $100 million on planning software that had been customized so heavily it effectively failed like an in-house build.

Werner Vogels, CTO of Amazon Web Services

“Stop spending money on undifferentiated heavy lifting.” – If it is not a competitive differentiator, it can be bought.

The Hidden Costs of Building

Development costs are just the tip of the iceberg:

Maintenance costs

15–20% of development costs – every year. A system built for €500,000 then costs €75,000–100,000 per year to keep running.

Key-person risk

The developers who built the system leave the company. Their knowledge walks out the door – and the system becomes a black box.

Opportunity costs

Every developer working on an internal finance tool is not working on the actual product.

Regulatory risk

E-invoicing mandates, compliance updates, GDPR changes – every regulatory shift has to be implemented in-house.

Build vs. Buy: A Side-by-Side Comparison

Criterion	In-House Build	Specialized Solution
Time to Value	12–24 months	Weeks to a few months
Success rate	31% (Standish Group)	Proven product on the market
Maintenance	15–20% p.a. + dedicated team	Included in the price
Regulatory compliance	Every change implemented yourself	Proactive updates from the vendor
Total cost (5 years)	4–5x the development cost	Predictable license fees

The Local Maximum Trap

Behind many build decisions lies a pattern known in optimization as the “local maximum”: an existing system is incrementally improved over years – new scripts, more workarounds, additional integrations. Each individual improvement makes sense. But taken together, they create an increasingly complex structure that becomes harder and harder to change.

The problem: incremental improvements cannot take you past a certain point. If you keep automating an Excel-based reconciliation system, you will eventually hit a ceiling – no matter how much development time you invest. The leap to a fundamentally different architecture (say, a system that natively understands documents instead of parsing cells) requires leaving the local maximum behind.

That is exactly what feels hard. The existing system works – sort of. It has years of customization behind it. Everyone knows it. Switching feels risky, even though the real risk lies in staying on a plateau while the market moves on.

Common warning sign

“We are too complex for an off-the-shelf solution.” – In many cases, that is not genuine complexity but process debt: historically grown workarounds that were never cleaned up. The truly unique parts of a finance department (strategic FP&A work, valuation decisions) are typically the ones that require human judgment – not automation.

When Building In-House Makes Sense

Gartner offers a simple rule for this: only build in-house when two conditions are met simultaneously:

It is core to your competitive advantage

Customers choose your product because of this exact capability.

No suitable solution exists on the market

For finance processes, this is extremely rare – it would take a truly niche requirement that no specialized vendor covers.

Fair Arguments for Building

Two objections to buying that are legitimate:

Data sovereignty

Financial data is among the most sensitive data categories. But consider this: anyone automating internally still needs LLMs – and sends the same data to OpenAI, Anthropic, or Google. Specialized vendors often offer dedicated instances, EU hosting, and data processing agreements as a core part of their product.

Vendor lock-in

A vendor can be acquired, raise prices, or discontinue its product. Open data formats and export capabilities significantly reduce this risk.

Three Questions That Help You Decide

Is this process a genuine competitive advantage – or necessary work that does not differentiate us from competitors?

Do we have the capacity to maintain this system for years and keep it up to date with regulatory changes?

What could our developers build instead that actually generates revenue or retains customers?

Conclusion

For standardized finance processes like invoice processing, reconciliation, and reporting, the data paints a clear picture: the effort involved in building in-house often exceeds expectations significantly. At the same time, there is a risk of optimizing a local maximum instead of making the leap to a fundamentally better solution.

That does not mean building in-house never works – it means those resources may have a greater impact elsewhere.