Build or buy: a decision guide for business software

Custom software is right when your process is a source of advantage or packaged products force costly compromises. In almost every other case, buying a proven product is cheaper, faster and less risky. The difficulty is that the decision rarely arrives so neatly. A sales team wants a tool that fits how it really works. Finance points out that a subscription is cheaper. IT worries about yet another system to support.

This guide gives leaders a structured way to make the call. It covers three questions: how well available products fit, what each option will really cost over its life, and how much control you need over the roadmap and the data. It ends with a simple process you can run in a few weeks.

Start with the job, not the solution

Build-or-buy debates often start with a solution already in mind. Someone has seen a product demonstration, or a developer has sketched an application. Step back and describe the job the software must do in plain terms: who uses it, what they need to achieve, which other systems it must work with and what good looks like.

Then ask a harder question: is the way you do this job genuinely different from your competitors, in a way customers notice and value? Payroll, expenses and email are not sources of advantage for most firms, however important they are. A distinctive pricing engine, a scheduling method that lets you promise faster delivery, or a customer portal that makes you easier to deal with might be.

Compare fit honestly

Check how much of your need a product meets out of the box. List your requirements and mark each as essential, important or nice to have. Then test two or three leading products against the list, using your own data and real scenarios rather than the vendor’s prepared demonstration.

Be honest about which requirements are essential. Many “essential” requirements turn out to be habits that the organisation could change at little cost. Adopting a product’s standard way of working is often cheaper than paying to configure it around a process nobody would design that way today.

• If a product meets most essential needs out of the box, buying is usually right.
• If it meets them only with heavy customisation, the cost and upgrade risk rise sharply.
• If no product meets a requirement that genuinely sets you apart, that is a case for building.
• If the gaps are small and specific, consider buying and building only the missing piece.

Watch for heavy customisation of packaged software. It combines the downsides of both options: you pay for licences and for development, and each vendor upgrade risks breaking your changes. A product that needs extensive bespoke code to fit may be a sign that either the product or the process is wrong.

Count the lifetime cost

Include maintenance, hosting and change. The first release of custom software is often the smallest part of its total cost. Software needs fixing, securing, updating and adapting as the business changes. A reasonable planning assumption is that a custom application will need ongoing investment every year for as long as it is in use.

Packaged products have hidden costs too. Subscription prices tend to rise, user numbers grow, and premium features you need may sit in a higher tier. Implementation, data migration, integration and training can cost as much as several years of licences.

What to include in a five-year comparison

1. Initial cost: licences or development, configuration, data migration and integration.
2. Running cost: subscriptions or hosting, support, monitoring and security.
3. Change cost: new features, updates to keep pace with other systems, regulatory changes.
4. People cost: internal staff time to own, administer and support the system.
5. Exit cost: what it would take to move away, including data extraction.

Compare the options over the same five-year period and include a range rather than a single figure. Custom builds carry more uncertainty, so the range will be wider. If the custom option only wins in the best case, buy.

Do not forget the cost of time. A packaged product can often be live in weeks, while a custom application may take months to reach the same point. If the software supports a new service or a market opportunity, those extra months carry a real cost in revenue not earned. Equally, a rushed purchase of an ill-fitting product can cost more in workarounds and staff frustration than a slower, better-fitted build.

Consider control

Think about who owns the roadmap and the data. When you buy, the vendor decides which features are built, when prices change and when old versions are retired. For most back-office functions that is fine, and even an advantage: the vendor spreads the cost of improvements across thousands of customers.

For capabilities at the heart of your offer, dependence on a vendor’s roadmap can be a real constraint. If a competitor uses the same product, you cannot easily differentiate. If the vendor is acquired or changes direction, you may be forced into an expensive migration.

Data deserves its own question. Check where the data is stored, whether you can export all of it in a usable format, and what happens to it if you leave. Custom software gives you full control of the data, but also full responsibility for protecting it.

Capability matters as well. Building software well needs product ownership, design, engineering, testing and operations, either in-house or through a long-term partner. If your organisation has never run a software product, the first custom build carries extra risk. Be realistic about whether you can own it for years, not just commission it once.

The hybrid option

Many of the best answers combine both. A firm might buy a standard platform for customer records, finance or inventory, then build a custom portal, pricing tool or mobile app on top of it, connected through the platform’s interfaces. The commodity work runs on a supported product, and development money goes only into the parts that make the business different.

The trade-off is integration. Every connection between systems needs designing, testing and maintaining. Choose platforms with well-documented interfaces and keep custom logic outside the packaged product wherever possible, so upgrades do not break it.

A four-week decision process

1. Week one: describe the job, list requirements and mark which genuinely set you apart.
2. Week two: shortlist two or three products and test them with real scenarios and data.
3. Week three: estimate five-year costs for buying, building and a hybrid, with ranges.
4. Week four: assess control and data risks, then recommend an option with clear reasons.

We were sure we needed a custom build. Testing three products against our real scenarios showed that only one requirement was truly unique, so we bought the platform and built that one piece.

Operations director, distribution client

Before your next build-or-buy decision, ask the sponsoring team to write one page answering a single question: what would we do differently from competitors with this software, and why would customers care? If the answer is thin, buy. If it is compelling, build, but cost it over five years first.

Source: Intelliversal analysis.

Frequently asked questions

Is custom software always more expensive than buying?

Not always, but usually over its lifetime once maintenance, hosting and change are included. It can be cheaper when packaged products would need heavy customisation or when licence costs grow with large user numbers.

How much customisation of a packaged product is too much?

When customisation starts to affect upgrades, or when the bespoke code becomes a significant share of the total cost, step back. Either adopt the product's standard process or consider building that piece separately.

What is the biggest risk of building?

Underestimating the ongoing cost and ownership. Custom software needs a team, a budget and a roadmap for as long as it is in use, not just a project to deliver the first version.

Explore Custom Application Development