Custom software or off-the-shelf: buy, build or integrate?

Compare buying, integrating and building

Buy an existing tool when it handles your essential workflow well. Integrate the tools you already use when the problem is the handoff between them. Build custom software when a material requirement remains unmet and you can fund its ongoing care. Start with those three options, not a forced choice between a subscription and a bespoke system.

The useful question is not whether custom software is more powerful. It is whether the extra control justifies responsibility for design, testing, security, support and future changes. A familiar product with a workable process can be a better decision than a new system nobody has time to maintain.

Run these decision gates first

Describe one workflow from beginning to end, including its exceptions. Use sanitised examples of real work to test the options. A demo with perfect sample data tells you little about duplicate records, corrections or failed handoffs.

1. Can you configure an existing product? Test the essential task, user permissions, reporting and exceptions. Check whether a needed feature is included in the plan you would actually buy.
2. Can you connect current tools? If each system does its own job well, examine native connectors, APIs or controlled imports before replacing it. Name the source of truth and the person who handles failed transfers.
3. Does a hard gap remain? Record the unmet requirement and its consequence. A preference for different button colours is not the same as an inability to enforce required access controls.
4. Can you own the outcome? Before a build, identify a product owner, support arrangement and budget for maintenance. If those are missing, reduce the scope or defer the decision.

An option that fails a genuine non-negotiable requirement should not win because it scores well on convenience. Separate those gates from preferences before looking at a total score.

Use a weighted fit worksheet

Copy the following headings into a spreadsheet, with a column each for buy, integrate and build. Choose weights together before suppliers present proposals. Use 1 for low importance and 5 for high importance. Score fit from 0 for no fit to 3 for demonstrated fit, then multiply weight by fit for each row.

• Essential workflow, including the awkward exceptions.
• Access controls, privacy and audit requirements.
• Data quality, reporting and compatibility with current systems.
• Adoption, accessibility and training effort.
• Delivery risk and time until a usable first slice.
• Full lifecycle cost and availability of support.
• Export, ownership and the practical exit route.

Write the evidence beside each score: tested, documented, promised or unknown. Do not award an unbuilt feature a demonstrated-fit score. A custom proposal needs a credible design and a trial of its riskiest part. If the result changes when one weight moves slightly, investigate that uncertainty rather than treating the spreadsheet as an objective verdict.

Compare the full lifecycle cost

Use the same planning period and expected usage for every option. Include setup, migration, configuration, integrations, licences, hosting, training and internal staff time. Ask how charges change with users, storage, transactions or API use. Use actual quotes and contract terms, not supposed industry price averages.

For custom software, include security patches, dependency updates, backups, restore tests, monitoring and bug fixes. For bought software, include vendor price changes, plan restrictions and process changes. Integrations have their own maintenance cost when either connected tool changes. All three options need someone to investigate problems and make decisions.

Price the exit as well as the launch: exporting records and attachments, mapping them to a replacement, checking completeness and running both systems during a transition. Compare a manageable ongoing commitment, not just the first invoice.

Agree ownership and an exit test

Ask who controls the accounts, domain, hosting and administrative access. Check what the contract says about data ownership, source code, licences and handover. Custom software does not automatically give you every right to its code, and owning code does not make it maintainable without documentation and access.

Request a sample export with relationships and attachments intact. Check the format, any fees, retention rules and what happens after cancellation. For a build, include deployment instructions, backup restoration and a handover that another competent maintainer can use. For an integration, document field mapping, credentials ownership and the safe way to pause or retry a transfer.

Make the first commitment reversible

Trial the essential workflow with a small, representative dataset and clear acceptance criteria. Measure whether the job works, not how many features the supplier can demonstrate. Agree what happens if the trial fails before signing up for the larger scope.

If the gap is between existing systems, review our tool and API integration service. If a distinct operational interface is justified, see our bespoke web apps and dashboards service. A sound decision can be to buy, connect, build a narrow piece, or leave the current setup alone.

Related capability

Integrations

System connections that keep data moving cleanly between websites, tools, agents, and teams.