Deciding What Software to Build, Buy or Integrate

A request for “a new customer platform” can hide several different needs: recording enquiries, calculating prices, checking stock, assigning work and giving customers progress updates. Treating these as one purchase forces an unnecessarily blunt decision. A standard CRM might handle enquiries well while a specialist pricing process needs a separate calculation service.

Start by naming the work, without using product names. Describe what each capability must accomplish, who uses it and which other capabilities it depends on. Then mark the parts that genuinely distinguish the business. A familiar screen layout is seldom a competitive advantage. An unusual allocation method that lets the business fulfil difficult orders reliably may be.

The distinction between standard capabilities and differentiating ones is central to Thoughtworks’ build-versus-buy framework. For an SME, its practical value is focus: custom development should have a clear reason beyond a preference for owning the software.

This exercise often reveals a fourth option: leave a working capability alone. Replacing a dependable accounting tool merely to make the technology estate look uniform can consume money and attention without improving the customer’s experience.

Feature lists are a poor substitute for a working demonstration. “Supports approvals” says little about an approval that changes when the order crosses a value threshold, the manager is absent or the customer revises the request halfway through.

Give shortlisted suppliers a small set of representative tasks. Include a normal case, a common exception and a correction after completion. Ask them to demonstrate those tasks with realistic sample data. Record which steps work as supplied, which require configuration and which depend on an extension or a manual workaround.

For a hypothetical equipment service business, the decisive scenario might be rescheduling a visit after parts fail to arrive. Can the system preserve the customer’s original commitment, notify the right team and distinguish a supplier delay from a technician delay? A polished appointment calendar does not answer those questions.

Be equally demanding of a proposed custom build. A diagram and a promise of flexibility are insufficient. Ask how the design will handle the same cases, what remains uncertain and which assumption needs a prototype.

Classify each gap by consequence. A minor inconvenience used once a month should not outweigh a broken step in every order. Conversely, a rare event can matter greatly when it changes a payment, exposes information or prevents the business from operating.

A credible comparison includes the work around the product. Buying software still requires configuration, migration, training and someone to administer it. Building software still depends on external components, hosting and maintenance. Integration creates its own responsibilities for access, data definitions and failures.

Use a comparison sheet that keeps those obligations visible:

The strongest option may combine all three approaches. Buy customer and finance systems, build a narrow scheduling capability and integrate the relevant records. The benefit comes from assigning each job appropriately, rather than forcing every job into a single delivery model.

A connection deserves particular scrutiny when nobody wants to own it. If a supplier says an integration is available, establish whether that means a supported product feature, a third-party service or custom work that your business must maintain.

Compare costs over a period that matches the expected business decision, using the same assumptions for every option. Include implementation, internal staff time, subscriptions, infrastructure, support, training, migration and foreseeable changes. Document what is excluded.

Separate committed cost from uncertain cost. A supplier’s quoted subscription is different from an estimate of future development. A conservative estimate should allow for the work required to keep the system useful, not assume that launch is the final expense.

Benefits need the same discipline. Reduced data entry may release capacity, but it becomes a cash saving only if expenditure actually changes. Faster quoting may help sales, but the value depends on demand, the quality of the offer and the team’s ability to respond. GOV.UK’s service-benefits guidance provides a useful basis for comparing measured starting conditions with expected improvements.

Test the decision against uncomfortable cases. What if implementation takes longer? What if usage grows more slowly? What if the person maintaining the system leaves? A choice that makes sense only under the most optimistic assumptions deserves more investigation.

The best option is the one the business can use, support and change with confidence.

For businesses operating across countries, check currency, tax handling, local payment methods, language and support hours during the comparison. A product that fits headquarters may create manual work for another location. Ask where data is hosted and which contractual or regulatory requirements apply to the actual information involved. Resolve these questions with the relevant local advisers before treating regional expansion as a simple licence upgrade.

A contract can describe service availability while leaving the practical exit unclear. Request a sample export of the records the business will need. Check whether it includes relationships, attachments, history and identifiers, and whether another system can interpret it.

For custom software, establish access to source code, deployment instructions, account ownership, documentation and the rights needed to continue development. Do not rely on the original developer’s memory as the operating manual. For integration, record the credentials, transfer rules and recovery procedure so that a failed connection can be repaired without guesswork.

Retention and retirement should also be explicit choices. AWS’s migration-strategy guidance includes retaining and retiring workloads alongside replacement and rebuilding. That is a useful reminder when a software review begins to turn into a wholesale replacement programme.

Before making the final commitment, write a short decision record: the capabilities in scope, the selected approach, the strongest alternative, the assumptions that matter and the event that would cause a review. Keep it understandable to someone joining the business later.

Where uncertainty is concentrated in one workflow, commission a bounded discovery or prototype before the full build. A small investment in resolving that uncertainty can make the larger choice easier to defend. Custom software development becomes a sensible next step when the business can explain both what it needs to own and why.