Bespoke software vs off-the-shelf: how to choose
Decide whether to buy, configure, connect or build business software. Compare workflow fit, ongoing costs, ownership and support using a practical example.

A software demo can look convincing. The screens are tidy, the feature list sounds right, and then someone asks how it handles the awkward approval process your office deals with every Thursday.
That's the part worth exploring before you buy anything.
Off-the-shelf software is a good fit when an existing product handles your important tasks well. Bespoke software, built around your business, becomes worth considering when suitable products can't meet a requirement that matters enough to justify the work and ongoing support.
There are options between the two, too. A better setup or a connection between tools might solve the problem without replacing everything. To work out which route suits you, start with an ordinary working day.
Follow one job through the business
Imagine a maintenance company using a CRM for enquiries, a calendar for visits and an accounting package for invoices. Follow a job through its office and we'll have something more useful to compare than feature lists.
The office team keeps typing the same customer addresses into different systems. It's frustrating, and mistakes creep in. Their first thought is to find one application that does the lot.
Perhaps they don't need to. If the CRM can send an accepted job to the calendar through a supported connection, that could remove the repeated typing. The accounting package can carry on doing its job.
Now add another detail. Every visit needs two suitably qualified staff, a particular vehicle and approval of customer photographs before the booking is confirmed. The problem has changed. Moving an address between systems won't help the office check all those conditions.
A scheduling product might already handle them. If it doesn't, a small planning application could deal with assignment and approval while the business keeps its existing CRM and accounts software. That's the sort of boundary we explore when planning bespoke business software or systems integrations.
Buying and building aren't the only two choices
“Off the shelf” means a product designed for a wider group of users. You work with its existing features and the settings, extensions and connections it supports. A hosted subscription service is one familiar example.
Bespoke software is developed for a particular business, process or product. It might be a whole ordering system, or just the planning tool our maintenance company needs. It can still use standard software components; every part doesn't have to be written from scratch.
In practice, there are four routes to consider:
| Route | Where it could fit | The thing to establish |
|---|---|---|
| Use an existing product | Its normal way of working suits your main tasks | Can your team finish a real job without extra spreadsheets? |
| Configure a product | Settings or supported extensions cover the gaps | Who will maintain the setup when the product changes? |
| Connect existing tools | Each works well, but staff copy information between them | Do the supported connections handle the actions you need? |
| Build a bespoke system | Important rules or customer tasks don't fit suitable products | Can you define a useful first version and support it afterwards? |
There's a trap at either end. You can assume your process is so unusual that nothing existing will do, or bend a standard product so far that looking after it becomes a project of its own. The GDS discussion of building and buying technology explores both problems.
It's also worth questioning an old step before paying to reproduce it. A workaround that made sense years ago doesn't automatically belong in the next system.
Give the awkward bits a proper trial
Back at the maintenance company, a useful trial would follow a job from enquiry to confirmation. The office needs to choose qualified staff, reserve the vehicle, review the photographs and tell the customer what's agreed.
Then the plan changes: one member of staff becomes unavailable. Can the team reassign the visit? Does the system spot a missing qualification? Is it clear whether the customer needs a new confirmation?
That's much more revealing than watching someone click through a prepared demonstration. GOV.UK's purchasing guidance recommends testing a small, difficult problem in a product trial, alongside integration and user experience.
Include the people who'll actually use the software. The manager may want a weekly overview, while the administrator needs to spot the one request nobody has answered. Both needs are reasonable. Seeing them together helps you decide what's essential for the first version and what can wait.
For a custom build, the same examples give the developer a clear scope and give you a way to check the result. Our maintenance company's first release might cover accepted jobs, resource checks and a visible status for the office. Payroll and a mobile app can stay outside that boundary until there's a reason to add them.
Look past the price on the proposal
A monthly subscription and a development quote rarely cover the same responsibilities. Compare what it will cost to make each option work over the same period, including the work your own team will do.
With a purchased product, that means checking setup, data migration, staff accounts, training and any extensions or integration work. The attractive starting price is less useful if the feature you need sits on another plan. Find out how the bill changes as you add people or capabilities.
A bespoke quote needs to make clear what's included at launch, with discovery, design, development and testing accounted for. There'll also be hosting, backups, monitoring, updates and support to arrange. GOV.UK's dependency guidance explains why the software components used in a build need maintaining over time.
Neither option imports and checks your records by magic. Someone still has to prepare the data, resolve duplicates and help colleagues get used to the system. Allow for that effort, and keep estimated savings labelled as estimates. There's no useful universal price for bespoke software without knowing the work it needs to do.
Make sure there's a plan for life after launch
Before committing, find out who will keep things working and what happens if you want to move on.
For a purchased product, check data exports, account administration and the limits of its support. With bespoke work, agree the rights to custom code, third-party licences, access to hosting accounts and the documentation another developer would need. Ownership and continuity deserve a conversation while everyone's available to answer it.
Your business also needs someone who can make decisions about the process. A developer can add an approval step, but they can't decide who in your organisation has authority to approve the work. Agree how urgent faults and requests for new features will be assessed, too; they call for different responses.
The best choice is the one you can explain using a real task, a workable budget and clear responsibilities. Our TailTrack case study shows how booking requests, scheduling and customer access can sit within a connected product.
For our maintenance company, the answer could be a supported calendar connection or a planning tool built around staff and vehicles. Either way, there's now a real job to test it against. If your own choice still feels unclear, we can work through the difficult part with you.


