Bespoke or off-the-shelf,
and the third option.

The choice is usually framed as two options: commission a system built around the firm, or buy a package and work the way it works. Both are real, and both are usually priced on the wrong question. The useful question is where the build starts, and who pays for the distance between that starting point and the way your firm runs.

What commissioning from scratch buys

A system written from an empty screen fits the firm on the day it is specified. The difficulty is everything it has to contain before it can do the part you commissioned it for.

Every contractor needs the same foundations. User accounts and permissions, a record that cannot be quietly edited, document storage, exports, hosting, backups, and a phone app that passes store review. None of that is what makes your firm different. In a from-scratch build, all of it is paid for again, line by line.

Then there is time. A commissioned system does nothing useful until enough of it works to replace what it is replacing. The specification is written by people who have not yet used the thing, and the first real week on site rewrites it.

The longer cost is keeping it running. Owning the code sounds like security, and it is, until the developer who wrote it moves on. Phone operating systems change every year and store rules change with them. A system with one customer and one person who understands it carries a risk that no contract clause removes.

What a package buys, and what it asks of you

A package reverses the economics. The foundations are shared across every customer, so each one pays a fraction of them. The product is proven before you buy it, and somebody else maintains it.

What it asks in return is that the firm adapts. The approval route is the one the product has. The timesheet knows the pay types the product knows. The valuation follows the format the vendor chose for its average customer, and the roadmap is set for that customer too.

Firms absorb this in small ways. A spreadsheet runs next to the system for the part it does not cover. A form is filled in twice because the software asks for things in a different order. Each workaround is minor, and together they are how a firm pays for software while still keeping the old records.

The third option: a working core, adapted to the firm

There is a route between the two. The build starts from a platform already running real contractors, so the shared foundations exist, are maintained and have been tested by daily use. The effort goes into the parts where your firm is genuinely different.

Done properly, the forms, approval routes, pay rules and documents follow the way the firm already works. Anything else the firm needs is built. It then becomes part of the platform rather than a separate copy kept for one customer.

That last point is the one to test. A vendor that adapts one core and maintains it as one product is offering the third option. A vendor that takes a separate copy of its code for each customer is selling a from-scratch build with a head start. The maintenance problem arrives with the first upgrade.

Three checks separate them. Is the core in daily production at firms you can speak to, and for how long? Are your changes delivered on the same release as every other customer's? Will the vendor state in writing what a change costs after go-live?

Either the firm changes to suit the software or the software changes to suit the firm. Somebody pays for the difference either way.

What “we can customise it” should mean in writing

The phrase covers everything from renaming a field to building a new module, so on its own it tells a buyer nothing. Four questions pin it down.

1. Who pays for changes after go-live? They can be included in the fee, drawn from a prepaid budget, or quoted at a day rate each time. The last is the arrangement that quietly stops a firm asking.
2. Who owns a change once it is built? If it lives in the core platform, it is maintained and survives upgrades. If it lives in a copy built for you alone, ask who maintains it when the core moves on.
3. What happens to your data if you leave? Ask for the format, the timescale, the cost and what is included. Records without their photographs, attachments and audit trail are a partial history, and the gaps show during a dispute.
4. Who makes the change? A developer who works on the platform itself, or a partner configuring it from outside. The answer decides whether a request becomes a change or a ticket in somebody else's queue.

Get all four answers on paper before the contract, not at the first change request. Answers given on a call tend to be remembered differently by each side.

Where the risk sits on each route

Set side by side, the three routes differ less on the monthly figure than on who carries what.

• From scratch, the firm carries the build cost, the timescale, the specification risk and the maintenance. In exchange it gets a system nobody else has.
• With a package, the vendor carries the build and the maintenance. The firm carries the cost of working around whatever the product does differently.
• With an adapted platform, the vendor carries the core and the adaptation. The firm carries the job of explaining clearly how it works.

None of those is free. The decision is which of the three costs your firm is best placed to carry, and for how many years.

Where to start, on Monday

Write down three things your firm does differently from a competitor of the same size. A pay rule, an approval route, a document a client insists on, a way of pricing. Those three are the part of the specification that matters.

Put them to every vendor on the list as a written question, and ask how each would be handled: configured, built, or worked around. The answers sort the vendors into the three routes faster than any demonstration will.