From the blog
When to build custom software
and when to buy off the shelf
Most organisations ask "build or buy". That is almost always the wrong question — and it is the one that gets projects stuck.
"Build or buy" assumes there are two complete options and that one has to be chosen. In practice, almost every system we have seen in production is a mixture: something bought, something built, and a strip of connective tissue between them. The practical question is not which option to pick, but where the boundary runs — what an off-the-shelf product is allowed to dictate to you, and what has to be decided at your end.
The four questions below are the ones we ask in the first specification meeting. They are not meant to lead to a single answer; they are meant to put that boundary in the right place.
Four questions that decide it
- Is the process itself your advantage? Bookkeeping, payroll and stock control are processes every organisation performs in more or less the same way — and there an off-the-shelf product wins, because every change you ask for is pure cost. But when the process is the way you deliver your service, fitting it to a product means giving up exactly what sets you apart.
- Does regulation dictate the process? This is where flexibility has a real price. In the forms platform we built for Isracard, the hardest requirement was not functional but regulatory: knowing exactly what the customer signed and when, years back if needed. From that follows the rule that a form version cannot change once it has been sent. A requirement like that is not an add-on to an existing product — it is architecture.
- How many existing systems have to be connected? The more the new system has to talk to what you already run, the larger the part no product will bring with it. The messaging system we built for the FIBI Group is not impressive because of the messaging; it is impressive because actions can be carried out in the bank's systems from inside that same conversation, and documents produced — up to approving a loan with a digital signature.
- Who will change this a year from now? This is the most neglected question, and the one that determines the real cost. If every change of wording, every new field and every new process needs a software release, you have paid for a system that will age. In Sheba's appointment booking, the clinic's own staff set up a new service, change wording and add a question to a questionnaire themselves — a new clinic goes live through configuration, not through a release.
The answer is almost never either-or
The two projects we are asked about most illustrate this from both directions.
A product that grows into a process: the forms platform is an existing product — an editor, version control, a return path carrying the data, and accessible signed document output. At Isracard it was not deployed as-is; the process the organisation actually works by was built around it. The generic part was saved; the specific part was built.
Development that yields a reusable skeleton: Sheba's appointment booking was built for Sheba and is connected to its systems, and we will not sell it as an off-the-shelf product. But the questionnaire-and-mapping engine, the permissions model, the waiting list and document handling do not depend on Sheba — another healthcare organisation gets them connected to its own appointment store, without rebuilding each one.
In other words: the right boundary does not run between "product" and "development", but between what is generic at your organisation and what is not.
And what about cost
The honest comparison is not licence price against development price, because the two costs surface at different times. Development cost is visible up front, clearly, and it is the one that frightens. The cost of an off-the-shelf product emerges later: in the manual work somebody does to bridge what the product does not do, in a process bent to fit the software rather than the other way round, and in every change that has to wait for the vendor.
So the question worth asking is not "what does it cost" but "what will it cost to change this in two years". Systems we put into production in 2009 are still running, and we still maintain them — that is the span over which the real cost becomes clear.
Questions we get
So when should we buy off the shelf?
When the process is generic, when no regulatory requirement dictates how you work, and when the number of connections to existing systems is small. Under those conditions an off-the-shelf product will go live faster and cost less — and we will tell you so.
Can we start with a product and move to custom development later?
You can, and sometimes that is the right path — on one condition: that your data stays yours, in a format you can leave with. A product that locks the data turns the move into a project of its own.
How long does a custom system take?
The specification sets the scope, so we do not commit before it. For scale: Isracard's forms platform reached production within two months of the specification — the full case study.
And for your project
If you are in the middle of this decision, the first conversation is usually the most useful one: what the process is, what you already run, and how much of it is genuinely unique. From there it is far clearer what to buy and what to build. See also custom software development and integration between systems.
Let's talk about the project
A first technical call, with no commitment.