Business systems / Explainer
Ready-made software or a bespoke system: which fits your business?
A customer accepts a quote. You change the status in one system, copy the details into a job sheet and message somebody to get the work started. The software has recorded the sale, but you are still joining the process together by hand.
That is the sort of job I want to see when we talk about business systems. It tells me much more than a list of features. Where does the information arrive, what happens to it, and which parts are you repeating every time?
We have built bespoke CRMs for small businesses, including our own. I like being able to shape the screens and actions around how we actually work. Small businesses should be able to consider that option alongside a software subscription, with a clear view of what each would involve.
Follow one job through the working day
Pick a recent enquiry and trace it through to the finished job. Include the spreadsheet beside the main system, the email somebody has to find and the message that tells the next person to start. Those extra steps are part of the process, even if they never appear in a software demonstration.
Ask the person doing the work to show you. If they say, "We put that in the notes because there is no field for it," find out what happens to that detail later. It might be harmless. It might be the instruction somebody needs before ordering parts or booking a visit.
Write down the few things the system must handle well. For a quoting process, that could be the right customer details, an approved price and a clear handover when the quote is accepted. Use those requirements to judge both an existing product and a proposed build.
When a ready-made package is enough
If an existing product handles your main job and the people using it can find their way around, it deserves a proper trial. A simple appointment diary or a straightforward customer list may already have a suitable tool. Check the settings and features you are paying for before adding another system.
Configuration can make a difference. Your own fields, sensible stage names and a saved view may solve the problem without custom development. Ask to see those changes using sample records like yours, rather than judging the product from a polished demonstration full of somebody else’s data.
I would be comfortable recommending an existing tool that does the job. You still need to check the subscription, the features included in that plan and who will help set it up. The decision gets harder when the important part of your process sits outside what the product can do.
When the workarounds justify a bespoke system
Look at the workaround you repeat most often. Perhaps accepting a quote should create a job, allocate the next task and make the right documents available. If staff carry that sequence between screens every time, we can look at bringing it together in one action.
A bespoke system lets us decide what the record contains, what each person sees and which steps belong behind a button. A survey-led business can have its survey stage. A job that needs a manager’s approval can wait for that decision before moving forward. The working language can be yours.
This matters to me because we use a tailored CRM ourselves. I want the information close to the task, with fewer interruptions between deciding what to do and doing it. That experience is part of how I approach systems for other small businesses.
GOV.UK’s purchasing guidance identifies gaps in available products, integration needs and flexibility as reasons to consider building. It also recognises buying or combining approaches. That is useful background for the choice; the recommendation for your business should come from trying your actual process.
Keep the software that already does its job
A bespoke system can sit alongside the tools you want to keep. Your accounts can stay in the accounts package while a tailored job screen handles the work before an invoice is raised. The aim is to decide where each record belongs and remove the repeated copying between them.
We check what the existing services allow before promising a connection. An application programming interface, or API, is a route software can use to exchange information. Access can depend on the product, plan and permissions. The proposed connection needs to be checked against the systems you actually have.
Decide which system owns each fact. If a customer changes an address, where should it be corrected? If an invoice is paid, which record confirms it? Test what happens when an update is delayed or a connection fails, so staff can see what still needs doing.
Compare the full cost of using both options
A subscription price and a build quote pay for different things. Put them beside the cost of getting started and keeping the system useful. Include the time staff will spend on workarounds, checking records and learning the new process.
Use the same expected number of users and a period that covers the contract commitments. Ask what happens when you add a person, need another connection or change the process. Bespoke software also needs hosting, maintenance and support; allow for those from the start.
GOV.UK’s technology guidance highlights total ownership cost, control of data and the ability to change direction. Those are practical questions to put to either supplier before committing.
| Part of the cost | Ready-made package | Bespoke system |
|---|---|---|
| Getting started | Setup, configuration, importing records and training | Planning, prototype, build, importing records and training |
| Ongoing use | Subscription, user charges and any paid features | Hosting, maintenance, support and any connected subscriptions |
| Connections | Included integrations and any extra service or plan needed | Building and maintaining the agreed connections |
| Changes | What the settings allow and what needs a different plan or product | The work and quote needed to alter the system |
| Daily admin | The steps people still do outside the package | The checking and manual work left after the build |
| Leaving later | Available exports, account closure and moving the records | Code and data handover, documentation and moving the hosting |
Source: GOV.UK: choosing technology
Try the awkward job before committing
Give the existing product and the proposed bespoke system the same job to do. Start with an ordinary enquiry, then change something: the customer corrects an address, a quote needs revising, or the person responsible is away. Watch how the next person finds the record and continues the work.
For a bespoke project with us, you can try the key screens in a prototype before paying a deposit. I want the person who will use it every day to click through it. They are much more likely to notice a missing step than somebody looking only at the design.
Use sample records and inspect the result. If a button is meant to create a job, check the job it created. Try clicking twice. If something cannot be completed, check that the unfinished work is visible to the person who needs to deal with it.
Know who will look after it
Before signing, get the ownership, access and support arrangements in writing. For a package, ask what can be exported and what format the files arrive in. For a bespoke build, ask about the code, database, hosting accounts and the notes another developer would need.
Our web application service gives you ownership of the code and database once the final invoice is paid, with repository access and handover notes. Connected services still have their own accounts and terms. Discuss those alongside updates, backups and the process for requesting a change.
Start with the part of your working day that needs attention most. A few records and a walkthrough of the current process give us enough to begin. I would much rather get one useful workflow working properly than fill a new system with features you never use.
Sources
Checked on 23 October 2026.
- GOV.UK: define your purchasing strategy
Government purchasing guidance on build, buy and combined approaches, product fit, integrations and ongoing upkeep. The small-business examples and recommendations here are Garreth’s.
- GOV.UK: choosing technology
Total ownership cost, data control, existing systems, prototyping and retaining the ability to change direction.
- Flying Penguin: web application development
Our published prototype-before-deposit process, connected business systems and code/database ownership and handover after final payment.