Off-the-Shelf or Bespoke Software: Which Fits Your Business?

01

The application debate has more than two sides

Imagine a distribution business onboarding new trade customers. Sales gathers the enquiry, operations checks company and delivery details, finance approves a credit limit and a manager signs off exceptions. The information begins in email, moves into a spreadsheet, appears again in the CRM and eventually reaches the accounting system.

The spreadsheet was a sensible beginning. It gave the team a quick way to agree the columns, test the checks and keep work moving. As volume grew, the same file became harder to trust. People made copies, formulas changed, attachments sat elsewhere and nobody could see a complete audit trail for one decision.

Management now has three proposals. One supplier recommends a standard customer onboarding product. Another wants to build a new platform. A third suggests connecting the tools already in use. All three could be reasonable. None can be judged from a feature list alone.

The useful question is not whether off-the-shelf or bespoke software is better. It is which parts of the operation are standard enough to rent, which parts need configuring or connecting, and which parts create enough value to justify owning them.

02

Start with the workflow before comparing products

Software demonstrations make decisions look clean. A salesperson shows contacts, dashboards, automations and reports using tidy sample data. The buyer recognises many familiar words and assumes the product must fit. The gaps appear later in the handovers, exceptions and information the demonstration did not include.

Follow one real customer through the current operation instead. Record where the request starts, who changes or checks it, which information is repeated, what can block the work and what must be visible afterwards. Include the awkward case, not only the happy path.

For the distributor, a useful scenario would include a customer with two delivery locations, missing credit information and an exception that needs director approval. Ask every proposed route to show how that case moves from enquiry to an approved account without private notes, copied files or unexplained work outside the system.

This creates a fair comparison. It also stops the business paying to reproduce every current habit. Some steps exist because the old tools are awkward rather than because the operation needs them.

03

A controlled spreadsheet can still be the right answer

Spreadsheets are not failed software. They are flexible, familiar and excellent for exploring a process before the rules are settled. A small team with low volume and one clear owner may not need an application yet.

The spreadsheet route remains credible when the information is not highly sensitive, very few people edit it, the calculations are visible and checked, and the consequence of a mistake is limited. Version history, protected ranges, validation and a documented owner can make a temporary operational workbook much safer.

The warning signs are operational rather than fashionable. Several copies circulate. Access is broader than the job requires. Important formulas can be overwritten. Documents live in separate folders. Staff cannot tell who changed a decision. Reporting depends on one person repairing the file before a meeting.

At that point the business has not necessarily proved it needs bespoke software. It has proved the current control no longer matches the importance of the work.

04

Buy a standard product when the process is genuinely standard

Off-the-shelf software is strongest when many organisations need substantially the same result. Accounting, payroll, email, payments and general customer relationship management are mature categories because the core jobs are widely shared.

Buying gives the distributor a maintained product, an existing support route and a faster path to live use. Other customers help fund security work, integrations and improvements. The business can test the product before committing to a development programme.

The trade-off is that the provider controls the roadmap, packaging and platform rules. The distributor may need to adopt the product's language and process. That is sensible when the difference is merely habit. It becomes expensive when the product cannot represent a rule that protects margin, controls risk or supports the customer experience.

A standard product should pass the complete workflow test with acceptable compromises. Eighty percent feature coverage is not useful if the missing twenty percent contains every approval and exception that matters.

05

Configuration is different from custom development

Many products can be configured with fields, permissions, stages, forms and automations. That middle route can fit the real workflow without creating a new codebase for the business to own.

For the distributor, configuration might add a credit review stage, separate delivery locations, role-based approvals and a dashboard for incomplete applications. If those facilities are supported by the product, they are normally safer than forcing the same behaviour through unofficial workarounds.

Configuration still needs discipline. Too many custom fields and brittle automation rules can turn a standard product into a private puzzle. Document the important settings, test changes and make sure somebody inside the business understands why the workflow was configured that way.

Ask what will survive an upgrade, what needs a higher subscription tier and what can be exported if the business later leaves. A cheap configuration can become expensive when every useful improvement depends on one specialist partner or locked feature.

06

Integration can remove the worst friction without replacing everything

Sometimes each existing product performs its own job well. The failure is the space between them. Staff copy a new customer from the CRM into finance, save documents to a separate folder and update a tracking sheet because no system receives the final status.

An integration can move approved information, return identifiers and show failures without replacing the tools people already understand. It can be a focused and valuable piece of custom work even though the business is not commissioning a whole application.

The distributor could keep the CRM for sales and the accounting system for credit and invoicing. A small service could validate the approved record, create or update the finance customer and return the account status. Staff would review exceptions instead of retyping every ordinary case.

Connections need ownership too. APIs change, credentials expire and duplicate messages happen. Useful integration work includes authentication, mapping, logs, retry rules, monitoring and a clear manual route when another service is unavailable.

07

Build when the specialist workflow is worth owning

Bespoke software earns its place when the important process cannot be supported safely by available products and the difference is valuable enough to fund and maintain. It may create a stronger customer service, make a specialist decision repeatable or give the business control over information and change it cannot sensibly rent.

For the distributor, the distinctive part may be the way trade accounts are assessed across company history, locations, commercial terms and delivery risk. A focused onboarding portal could collect the evidence, guide the review, record decisions and connect the approved result to the CRM and finance system.

That does not mean rebuilding email, document storage, accounting and every standard facility. Mature products and frameworks should still provide common foundations. The bespoke layer owns the workflow and business rules that create value.

Custom development also transfers responsibility. The organisation needs clear source-code ownership, business-controlled accounts, hosting, tested backups, monitoring, security maintenance and a route for future changes. Control is useful only when the business is prepared to exercise it.

08

Compare the four routes using the same evidence

The table below is a starting point. It describes the normal shape of each route, not a guaranteed score. A carefully controlled workbook can be safer than a badly built application, and a mature product can be more adaptable than a rigid custom system.

Score the options against representative workflows, data, users and exceptions. Avoid awarding points for features nobody needs or assuming that a custom build can solve an unclear process simply because anything could be coded.

09

Compare total cost, not the first invoice

A monthly subscription looks cheaper than a custom build because the supplier spreads product development across many customers. A custom proposal looks expensive because the business sees the delivery cost directly. Neither figure describes the whole decision.

For a product, include licences, implementation, higher tiers, specialist configuration, data migration, integrations, training and the manual work that remains outside the product. Consider how prices change with users, records, storage or transactions.

For bespoke software, include discovery, build, migration, hosting, monitoring, support, security updates, dependency upgrades and future changes. Include the internal time needed to make decisions and help staff adopt the service.

Then compare the cost of the problem. How much staff time is spent re-entering and checking? What is delayed? Which mistakes create commercial or regulatory exposure? What opportunity cannot be served? A solution is not good value merely because its invoice is small.

10

Data, security and exit belong in the buying decision

Every route relies on other software. A bespoke application still uses frameworks, libraries, hosting and external services. An off-the-shelf product still depends on the supplier's security, continuity and commercial decisions.

The GOV.UK Service Manual recommends technology choices that allow later change, minimise total cost of ownership and keep control of stored data. The National Cyber Security Centre also advises organisations to understand third-party components, support lives and responsibility for security. Those are useful tests for a private business too.

Ask where the data lives, who can access it, how permissions are reviewed, how activity is recorded and how information can be exported. Ask what happens if the supplier raises prices, removes a feature, is acquired or closes. For a custom system, ask the same questions about the developer, repositories, accounts and deployment knowledge.

There is no route without dependency. The goal is to choose dependencies the business can see, govern and change when necessary.

11

Prototype the requirement most likely to change the answer

A long requirements document can make an option sound possible without proving that it works in the operation. Test the requirement that creates the greatest uncertainty before committing to the full route.

The distributor could configure a trial product around the difficult credit exception and use representative data. It could prototype the specialist review screen and simulate the CRM and finance connections. Staff could then complete the same case through both approaches.

Measure completion time, missing information, corrections, handovers and whether managers can reconstruct the decision afterwards. Ask users where they still leave the system. A realistic prototype can expose a poor fit while changing direction is still affordable.

The result may support buying, building or a hybrid. Discovery has done its job when it makes the next investment safer, not when it manufactures a reason to fund software.

12

The hybrid answer is often the strongest

The distributor does not need to choose one philosophy for every system. It can buy the common capabilities, configure what the product supports, integrate stable handovers and build only the workflow that creates distinctive value.

That route keeps the accounting provider responsible for accounting, the CRM provider responsible for general contact management and the bespoke portal responsible for the specialist onboarding journey. Clear interfaces allow each part to change without forcing the business to replace everything at once.

A hybrid architecture is not automatically simple. It needs clear data ownership and careful failure handling. Its advantage is commercial focus: custom investment is concentrated where fit and control matter most.

Good software judgement is partly the ability to decide what not to build.

13

Choose what the business really needs to own

A spreadsheet, product, integration and custom application are tools, not strategies. The right route fits the importance and maturity of the workflow, the acceptable compromises and the organisation's ability to own the result.

Keep the spreadsheet while the process is small and learning matters more than control. Buy and configure when the work is common and the product fits the real cases. Integrate when good systems are separated by repetitive handovers. Build when the specialist workflow creates enough value to justify control and continuing responsibility.

For the distributor, that may mean keeping trusted commercial systems and funding one focused onboarding service around the decisions those products cannot represent. The answer becomes clearer once the team follows a real case, prices the friction and tests the riskiest assumption.

If your business is comparing products with a bespoke build, I can review the operation, test the options and leave you with a practical recommendation before a large licence or development commitment is made.