Build or buy software: when does each make sense?

Start with the work you need to support

A build-or-buy decision needs a clear account of the job. Who is trying to do what? Which requirements are essential? What goes wrong today, and what is the consequence?

Separate a necessary business rule from a habit. An approval may protect a genuine risk. It may also survive because someone added it years ago. Automating both without asking the question preserves the confusion.

Write down the difficult cases as well as the ordinary journey. They will make a supplier demonstration or prototype much more useful.

When SaaS is a sensible choice

Software as a service is an existing product provided as an ongoing service, usually through a subscription. It deserves serious consideration where the need is common and a suitable product already supports it well.

Look for a good fit with the tasks people perform, the access they need and the systems that must exchange information. A long feature list is less useful than seeing your team complete a realistic task.

The supplier operates defined parts of the service. Your organisation still needs to manage its data, permissions, configuration and adoption. Check what support includes, how changes are introduced and whether important functions require a different subscription tier.

Be willing to adopt a sound standard process when your current variation adds little value.

When configuration or integration is enough

Before replacing a tool, establish whether it is being used well. The problem may be inconsistent records, an unconfigured workflow or information trapped between two otherwise useful systems.

Configuration changes how an existing product works within its supported options. Integration lets systems exchange information. Either may address the gap without a new core platform.

Test the connection against real conditions. Which system is authoritative? How are duplicates handled? Who notices a failed update? Can the connection cope with changed data or permissions?

Avoid accumulating so many extensions that a standard product becomes difficult to understand or upgrade. Those additions need an owner too.

When a tailored system is justified

Building becomes a stronger option when the unmet requirement is important and persistent. Perhaps the service depends on a particular sequence of decisions, or available products cannot support the necessary experience without substantial manual work.

Be precise about the gap. “Our business is different” is too broad to guide a build.

A tailored layer around established services may be enough. You can retain suitable products for common functions and build the part that connects the journey or supports the distinctive work.

The case needs someone who can make product decisions, access to the people who will use it and an achievable plan for running it. Access to developers solves only part of that problem.

Compare the whole commitment

Compare options over the same period and against the same expected use. Include implementation, data preparation, migration, integration, training, internal decision time and the period when old and new arrangements run together.

For SaaS, examine subscription tiers, usage limits, necessary add-ons, renewal terms and export options. For a build, include hosting, monitoring, security work, maintenance, support and future changes. Check which responsibilities sit with each party.

Ownership deserves a practical test. Who controls the accounts and data? What can you export? What rights do you have to code, configuration and documentation? Could another supplier take over? Answers depend on the actual agreements and dependencies, whether you buy or build.

A lower starting price does not settle the total effort.

When to wait

Waiting is reasonable when teams disagree about the process, no one owns the decision or the organisation cannot make time for implementation. A new system can make those gaps more expensive to resolve.

Use the pause deliberately. Name an owner, map one workflow, check the quality of the relevant data and test a simpler way of working. Set a review point and decide what evidence would justify moving ahead.

Waiting without that work is simply postponement.

Test the choice before committing

Take one representative workflow, including a difficult exception, through the strongest options. Involve the people who will use and support the result. Record what fits, what needs work and what remains uncertain.

Choose the smallest commitment that meets the need and leaves room to learn. That may be a subscription, an integration or a carefully bounded build.

The decision should be explainable in terms of the work, the trade-offs and the organisation's capacity to carry it through.