How to customise off-the-shelf software to get the perfect fit (2026 guide)

You customise off-the-shelf software by extending it from the outside rather than altering its core: use the vendor’s API, webhooks, scripting layer or plugin framework to add the missing behaviour in a separate service you control. That approach keeps you on the vendor’s upgrade path, keeps your team on the system they already know, and costs a fraction of replacing the package outright. Directly editing vendor source code is the one route we would almost always advise against, because your changes are lost or conflict at the next update.

Most businesses arrive at this question the same way. You have a package that covers 80 or 90 per cent of what you need. The remaining slice is small, but it is the part that costs you hours every week, and the vendor’s roadmap shows no sign of covering it.

The three options, and why the middle one usually wins

When a package is nearly right, there are only three honest responses.

Option	What it costs	What you give up
Live with the gap	Nothing up front, but ongoing manual effort	Time, accuracy, and the ability to act on data quickly
Customise around the edges	Typically a small project measured in days or weeks	Some ongoing maintenance, plus a dependency on the vendor’s API
Replace with bespoke software	£10,000 to £50,000 for a simple system, considerably more for a complex one	Months of build time, retraining, migration risk

The first option is quietly expensive. Manual data entry and manual checking are not free; they are just paid for in salary rather than invoices, and they generate mistakes that cost more to unpick later.

The third option is right when the package is genuinely wrong for you, not merely incomplete. If you are fighting the software’s basic model of the world, no amount of customisation will fix that, and a bespoke build is the sensible answer. We have written separately about choosing between custom and packaged software if that is the decision you are actually facing.

For everything in between, extending the package is the better trade.

Five ways to customise off-the-shelf software

These are listed roughly from safest to riskiest.

1. Configuration and built-in settings

Start here, always. Custom fields, workflow rules, permission groups, report builders, notification templates. It is unglamorous, but a surprising number of “we need development” requests turn out to be a setting nobody had found. Configuration survives upgrades because the vendor designed it to.

2. Webhooks and outbound events

Most modern packages will notify an external endpoint when something happens: an invoice is raised, a record changes, hours are logged. You receive that event in a small service of your own and do whatever the package will not do, such as sending a threshold alert, writing to a second system, or building a report the vendor never offered.

Time tracking is a good example of where this applies. A commercial tool will record hours and estimates perfectly well, but comparing effort against estimate often still means someone checking each task by hand. A small service that listens for logged hours and sends daily summaries and threshold warnings solves that without touching the package itself. Nobody has to learn a new system, and the manual checking stops.

3. API integration

Where webhooks push, APIs let you pull and write. An integration layer sitting between two packages can remove an entire category of rekeying: orders into accounts, applicants into payroll, enquiries into the CRM. Our guide to API integration covers the mechanics in more detail.

The practical limits to check before you commit: rate limits, whether the API exposes every field you need (it often does not), authentication method, and whether the vendor versions its API properly.

4. Plugins, apps and scripting layers

Salesforce, Bullhorn, Xero, Shopify, Dynamics and most enterprise packages have a documented extension framework. Building within it is more work than a webhook, but you get to place your functionality inside the product’s own interface, which matters enormously for adoption. Users will use what is in front of them and ignore what sits in a separate tab.

5. A companion application

Sometimes the cleanest answer is a small web application of your own that reads from the package and adds the layer it lacks: a proper dashboard, a customer-facing portal, an approvals workflow. The package remains the system of record. Your application is the interface people actually enjoy using.

What to establish before you write any code

We ask clients the same set of questions at the start of this kind of work, because the answers determine whether the project is a week or a quarter.

• Does the vendor’s licence permit it? Some agreements restrict integration or reselling of data. Read it rather than assume.
• What does the API actually expose? Read the documentation and test the specific endpoints you need. “It has an API” and “it has the API you need” are different statements.
• Where does the data live and who is responsible for it? If your service stores personal data, it is in scope of UK GDPR, and you need to be clear whether you are acting as controller or processor, because that determines your obligations.
• What happens when the vendor upgrades? Anything built against a documented, versioned API is reasonably safe. Anything built against scraped screens or an undocumented endpoint is not.
• Who maintains it in two years? A small extension is still software. It needs hosting, monitoring and someone who understands it.
• Is the gap worth closing? Quantify the hours currently lost. If it is twenty minutes a month, live with it.

What it costs and how long it takes

An honest answer depends on the depth of the change. A single webhook listener that sends alerts is a small piece of work, often a few days. A two-way integration between two systems, with error handling, retries and reconciliation, is a genuine project of several weeks. A companion application with its own interface sits in the same territory as a small custom build, which on this site we quote from £10,000 to £50,000 for a simple system.

UK agency rates typically run from £75 to £150 per hour, so a fortnight of development work is straightforward to estimate once the scope is clear. If you would like a rough figure before speaking to anyone, our cost estimator will get you within a sensible range.

The saving compared with replacement is usually the point. You are paying for the missing ten per cent rather than rebuilding the ninety per cent that already works.

Where customisation goes wrong

Three failure patterns account for most of the trouble we are asked to fix.

Modifying vendor code directly. It works beautifully until the first update, at which point you either lose your changes or refuse the update and slowly fall behind on security patches. Avoid it.

Customising instead of fixing the process. If the underlying process is muddled, automating it produces muddle at greater speed. Sort the process first, then decide what the software should do.

Building without documentation or ownership. Extensions written quickly by whoever was available, never documented, and forgotten until they break. Insist on documented code you own outright, and on knowing where it is hosted.

Frequently Asked Questions

How do you customise off-the-shelf software without breaking updates?

Extend the package from the outside instead of altering its code. Use the vendor’s documented API, webhooks or plugin framework, and keep your custom logic in a separate service that you host and control. Because you are only consuming published interfaces, vendor updates continue to install normally. Directly editing vendor source files is what breaks updates, and it should be treated as a last resort.

Is it cheaper to customise software or build bespoke?

Customising is almost always cheaper when the package already covers most of your requirements, because you are paying only for the missing functionality rather than rebuilding what works. A bespoke build becomes the better value when the package conflicts with how your business actually operates, when licence costs are high across many users, or when the customisation list has grown so long that you are effectively rebuilding the product anyway.

Can all off-the-shelf software be customised?

No. Customisation depends on what the vendor exposes. Established business platforms usually offer APIs, webhooks and an extension framework. Older desktop products and some smaller cloud tools offer nothing beyond a CSV export, which limits you to scheduled imports and exports. Before committing to any package, check the developer documentation and confirm that the specific data and events you need are genuinely available.

What is the difference between configuration and customisation?

Configuration means using settings the vendor already built: custom fields, workflow rules, report layouts, user permissions. It requires no code and survives upgrades untouched. Customisation means adding new behaviour through code, whether that is a webhook listener, an integration or a plugin. Always exhaust configuration first, because a great many requirements described as customisation turn out to be settings that nobody had located.

How long does a software customisation project take?

A single webhook or alerting service is often a few days of work. A two-way integration between two systems, built properly with error handling and reconciliation, usually takes several weeks. A companion application with its own interface takes longer still and should be scoped like a small software project. The main variable is rarely the coding itself; it is how clearly the requirement and the vendor’s API are understood at the outset.

Who owns the code for a customisation?

That depends entirely on your contract, so check it before work begins. When we build extensions and integrations, our clients own 100 per cent of the code outright, including the repository and the documentation. Some suppliers retain ownership and licence the result back to you, which leaves you unable to change suppliers later. It is a question worth asking directly at the quotation stage.

Getting the last ten per cent

If you have a package that is nearly right, the useful next step is a short conversation about what the vendor’s API actually allows and what the gap is costing you. We do this kind of work regularly, from single webhook services to full integration layers, and we will tell you plainly if replacement is the better answer. Have a look at how we approach custom software development, or get in touch and describe the ten per cent that is missing.