When is bespoke software
worth building?

Your team copies the same details between three systems. A spreadsheet fills the gaps. Another licence renewal lands, and you wonder whether building your own software would finally make things simpler.

Perhaps. But an awkward process isn’t automatically a reason to commission an application.

Bespoke software development means creating software around your particular requirements, rather than adapting your work to an existing product. It’s worth considering when the value of that fit outweighs the cost and responsibility of building and maintaining it.

Here’s how to make that decision without starting with a shopping list of features.

1. Put a number on the recurring admin

Start with one workflow that regularly slows people down: preparing quotes, allocating jobs, processing orders or assembling reports.

Follow it from beginning to end with the people doing the work. Record:

• How often it happens and how long it takes.
• Where people re-enter information or wait for approval.
• Which mistakes require work to be repeated.
• What happens when the person who knows the spreadsheet is away.

Then estimate the effort involved:

Monthly task volume × average minutes per task ÷ 60 = monthly hours spent.

For illustration, 300 tasks taking 12 minutes each represent 60 hours a month. That’s the current workload, not a promise that software will recover all 60 hours. Exceptions, checks and customer conversations may still need people.

Ask what recovered time would actually enable. Would it reduce overtime, delay a recruitment need or give your team more capacity? Time saved isn’t automatically cash saved.

Before automating anything, check whether a simpler process would remove the work altogether.

2. Give existing products a fair trial

Buying is usually the better starting point when your needs are common, a suitable product already exists and you need to get moving quickly.

Accounting, appointment booking and straightforward customer records are sensible places to investigate established products before considering a build. Your business can be distinctive without needing distinctive software for every task.

Test shortlisted products against real scenarios, including awkward exceptions. A polished demonstration won’t tell you whether your team can correct an order or export usable records.

Buying is a strong choice when:

• The product handles essential tasks without significant workarounds.
• You can reasonably adapt your process to it.
• Its permissions, reporting and export options meet your needs.
• The subscription remains affordable as usage grows.
• You prefer a supplier to manage the product’s core development.

Check whether better configuration or an unused feature in your current software would solve the problem first.

3. Compare whole-life costs, not just licences

A large subscription bill can make bespoke software look attractive. It doesn’t, on its own, make a build cheaper.

Compare options over the same period, such as three years, with consistent assumptions about users, transactions and support.

Keep VAT treatment consistent across quotes and check the assumptions with your finance team.

Model expected usage and a higher-growth scenario. Include uncertainty rather than treating an early estimate as a fixed commitment. Bespoke software can still depend on paid platforms, so building doesn’t necessarily remove subscriptions.

4. Check whether you need a connection, not a replacement

Sometimes the products are doing their jobs. The gap between them is the problem.

If staff copy approved orders into a finance system, a focused integration may be enough. You might keep both products and build only the connection or small internal application that’s missing.

Before choosing this route, investigate whether each supplier provides an API: a supported way for software systems to exchange information. Confirm access costs, usage limits, available data and whether the required updates are supported.

Also decide what happens when a transfer fails. Someone needs to spot the failure, correct it and avoid creating duplicate records.

The same principle applies to app development. Establish whether people need offline working, device features or simply a clearer interface before committing to a mobile app. A browser-based application may be sufficient.

5. Decide what ownership needs to mean

Control can be a good reason to build, particularly when a workflow is central to how you serve customers. But commissioning software doesn’t automatically give you unrestricted ownership of everything it uses.

Agree in writing:

• Who owns the custom code and what rights you receive.
• Which components carry third-party licence conditions.
• Who controls hosting accounts, code repositories and credentials.
• How you can export your data and restore backups.
• What documentation and handover another developer would receive.
• Who handles security updates, support and future changes.

For personal data, include UK data protection requirements in the brief and seek appropriate advice where needed.

Ownership is useful only if you can exercise it. Having source code without access, documentation or a maintenance plan leaves you with a different dependency, not independence.

6. Keep AI tied to a specific job

AI integration might help with variable inputs, such as extracting information from incoming documents. Fixed rules may be more appropriate for predictable tasks such as sending an approval notification.

Don’t commission an AI workflow simply because it sounds like an upgrade. Test it on representative examples, define acceptable errors and decide where human review is necessary.

Include usage charges, review time, data handling and a fallback process in the comparison. If an existing product performs the task reliably enough, that may be the better purchase.

7. Use this build-or-buy checklist

Copy this into your planning document. Mark each item yes, no or needs investigation, and assign an owner to unanswered questions.

• We can describe the problem without naming a proposed solution.
• We have measured the recurring workload and its consequences.
• We have checked whether simplifying the process would help.
• We have tested suitable existing products against real tasks.
• We have considered configuration or integration before replacement.
• We have compared whole-life costs using consistent assumptions.
• We understand essential third-party constraints.
• We have agreed data access, code rights and exit arrangements.
• We have someone responsible for decisions, adoption and ongoing care.
• We can define a small first release and measure whether it works.

This isn’t a points contest. A critical unanswered question about data access or affordability can outweigh several positive answers.

Buy when an existing product meets essential needs at an acceptable ongoing cost. Connect when the main friction sits between otherwise useful systems. Build when important requirements remain unmet and the expected benefit supports the investment. Pause when the process or evidence is still unclear.

If building looks promising, start with the smallest useful workflow and agree what improvement you’ll measure before expanding.

Want a second pair of eyes on the decision? Talk to Atlas-James about what’s getting in your way and what you’ve already tried.

• Bespoke software
• Software development
• Business planning
• Systems integration
• Workflow automation