The question comes up in almost every project. Both answers are defensible, and the wrong choice is paid for over a long time. Here is the framework for deciding.
The decisive criterion: is your process an advantage?
If the way you work sets you apart from your competitors, adapting it to standard software amounts to erasing that advantage. If on the contrary your process is ordinary — payroll is payroll — bespoke development makes you pay dearly for what already exists.
Put the question this way: am I doing something distinctive here, or am I doing what everyone does with different habits? Many claimed specificities fall into the second category.
What the market does well
Regulated, standardised functions: accounting, payroll, tax returns. These areas change with the law, and a vendor tracking those changes for hundreds of customers will do it better and more cheaply than you.
What bespoke development does well
Business processes specific to your activity, interconnection between existing tools, and needs no vendor covers because the market is too narrow. Our ChèquePrint and FuelManager applications are exactly that case.
The costs people forget
On the off-the-shelf side
Configuration, often longer than expected. Training. The specific development still needed despite everything. And the cost of adapting your processes to the tool, which is a real organisational cost.
On the bespoke side
Corrective maintenance across the whole lifespan. Regulatory changes you will have to fund alone. Documentation, without which changing supplier becomes very expensive. And the risk of depending on a single developer.
The middle path
Often the most sensible: an off-the-shelf product for the regulated base, complemented by specific development on the processes that differentiate you, the two communicating through documented interfaces.
That assumes the chosen product has open interfaces. It is a criterion to check before signing, not after.
Precautions with bespoke development
- Require ownership of the source code, written into the contract in black and white
- Insist on technical documentation delivered with the application
- Provide for direct access to the database
- Split into successive releases rather than one single delivery
- Define the scope of maintenance and its cost precisely
The first point matters most. Without ownership of the code, you are renting a tool with no way to change supplier.
Frequently asked questions
Does custom software always cost more?
To buy, often; over time, not necessarily, especially if the off-the-shelf product requires many adaptations or a per-user subscription that grows with headcount.
How long does it take to build a business application?
From a few weeks for a focused tool to several months for a complete system. Splitting into successive releases lets you use a first version quickly.
What happens if the supplier disappears?
That is the risk to cover contractually: ownership of the code, documentation and database access ensure another supplier can take over.
Our approach
Systomap builds bespoke business applications and deploys SOLVIO for the management base. Let us discuss what you need.
