If you are choosing software to run jobs, you will be told that packaged software is cheaper and bespoke software fits better. Both statements can be true, and neither helps you decide. This guide gives you a better way to frame the choice, including the cases where we would tell you not to build anything.
Start with the right question
The question is not "bespoke or packaged?" It is "how much of the way we work is standard?"
If your jobs follow a common pattern that many other businesses share, a packaged product has probably been designed around it already. If your workflow is distinctive, or the way you run jobs is part of why customers choose you, a product built for the average business will keep asking you to change.
Before comparing any products, write down how a job moves through your business from enquiry to payment. Mark each step as "standard" or "ours". That one page will do more to guide the decision than any feature list.
When off-the-shelf software is usually the right choice
A packaged product is often the sensible answer when most of the following are true:
- your process is close to a standard one, and you are happy to adopt the product's way of working;
- your team is small, so a lightweight tool covers what you need;
- you need to start quickly and cannot spare time to specify requirements;
- budget is limited and you would rather pay a predictable subscription;
- you do not need the software to connect with other systems you already rely on.
In these cases, building something bespoke is usually a poor use of money. We would say so, even to our own prospects.
When bespoke, or a configurable foundation, is worth considering
It starts to be worth a conversation when the picture looks more like this:
- your workflow is distinctive and the packaged options keep asking you to change it;
- you run several disconnected tools and re-key information between them;
- you need connections to other systems that packaged products do not offer;
- your team has built workarounds around the software you already own;
- the process itself is part of how you win and keep work.
Repeated workarounds are the clearest signal. If people keep a spreadsheet beside the system to do what the system will not, the system is not fitting the work.
The costs people forget on each side
Every option has costs that do not appear on the first quote. These are the ones that tend to surprise people.
Packaged software. Per-user licences that grow with headcount, paid add-ons for features you assumed were included, limits on how far you can customise, the time and cost of moving your data in, and training. There is also dependency: if the supplier changes the product or the price, you adapt.
Bespoke software. The time your own people spend defining what is needed, which is easy to underestimate. Scope creep, because it is tempting to keep adding. Maintenance and support after launch. And key-person risk: if only one supplier or one individual understands the system, you depend on them.
Data migration deserves its own mention on both sides. Moving history out of old spreadsheets or systems takes effort and care, and it is rarely as quick as it sounds. Ask early what must come across and what can be left behind.
Neither side is free of cost. The useful comparison is not the price on the quote but the total effort and risk over the years you expect to use it.
A plain comparison
| Aspect | Off-the-shelf | Bespoke or configured foundation |
|---|---|---|
| Fit to your process | Good where your process is standard; you adapt where it is not | Shaped around your process, within what has been scoped |
| Speed to start | Can be quicker to begin | Needs time to define requirements before building |
| Running cost pattern | Regular subscription, often linked to the number of users | Build cost first, then agreed hosting, support and change costs |
| Flexibility | Limited to what the product allows | Greater, with each change scoped and agreed |
| Ownership and exit | Depends on the supplier's terms; check how you can export data | Depends on the agreement; confirm what you own and what you are licensed to use |
| Effort from your team | Mainly set-up, data entry and training | More involvement up front, to describe how you work and test what is built |
Treat the table as a prompt for your own notes. Where a row matters a great deal to you, ask each supplier to answer it in writing.
A useful exercise is to mark which rows would hurt most if they went wrong for your business, and weight the decision accordingly. A business with one person ready to own the project will weigh "effort from your team" very differently from one where everybody is already stretched.
The middle path
There is a third option that sits between the two. Start from a configurable foundation that already covers the common parts of running a job, then build only the pieces that are distinctive to you.
This avoids two failure modes. You do not pay to rebuild things every business needs, and you do not squeeze a distinctive process into a product that cannot hold it. The discipline is in the scope: build what is distinctive, and resist building what is merely preferred.
In practice, list your requirements and label each one. Is it something every contractor needs, something you need a version of, or something only you need? The first group is what a good foundation should already cover, the second is what configuration can adjust, and only the third justifies building something new. In SENRAB's case, some needs that many contractors share, such as variations tracking, site forms and subcontractor workflows, are still in the built-to-your-requirements group today, so ask any supplier which side of that line each item falls on.
Ten questions to ask any supplier
Use these with a packaged vendor, a bespoke developer, or us.
- Who owns my data, and in what format can I take it with me if I leave?
- What do I own, and what right do I have to use the system?
- What happens to my system if you stop trading, or if I stop paying?
- Which parts are standard features, and which would be built for me? How is each one priced?
- What are the running costs after launch, including hosting, support, licences and any usage charges?
- How are changes requested, scoped and approved once we are live?
- Who will be my day-to-day contact, and what happens if they leave?
- How will this work with the systems we already use, and which connections would be scoped separately?
- What do you need from my team, and how much of their time will it take?
- What would make you tell me not to buy from you?
The last question is the most revealing. A supplier who can name circumstances in which you should look elsewhere is more likely to be straight with you about everything else.
How SENRAB approaches it
We offer a configurable job management foundation and build what is specific to you on top. Items such as variations tracking, site forms and subcontractor workflows are built to your requirements and scoped per project.
You keep your business data and the right to use your configured system. SENRAB retains ownership of the underlying platform. That is worth weighing against your own exit needs, so ask us to put it in plain terms.
We would tell you not to build when your process is standard, when your team is small and a packaged tool already does the job, when you have not yet mapped how you work, or when nobody on your side can own the project. In those cases a packaged product is the better answer, and the time to find that out is before any money is spent.
If you want a view on where your own business sits, our bespoke business systems service page explains how we work. How pricing works explains what shapes the cost and how to get a figure for your business. The business-case calculator helps you put a number on the status quo.