Custom software (also called bespoke software) is software written for one business instead of adapted to it. The size does not decide it: a small internal tool for one team is custom software, and so is a platform several departments share. It usually covers web applications, business platforms, internal tools, integrations and APIs.
Custom, configured or off-the-shelf?
The practical difference is who adapts to whom. With a product, your process bends to the software. With custom software, the software is shaped to your process. There is also a middle option that is often overlooked: many platforms can be configured heavily or extended with plugins and integrations, which suits a lot of businesses and costs far less than a build.
| Off-the-shelf | Configured platform | Custom | |
|---|---|---|---|
| Fit to your process | You adapt to it | Partly adapts, within limits | Built around it |
| Time to start | Days | Weeks | Months, usually in stages |
| Cost shape | Subscription, per user | Subscription plus setup | Build cost, then running cost |
| Control over changes | Vendor's roadmap | Mostly the vendor's | Yours |
| Main risk | Workarounds pile up | Hitting the platform's ceiling | Building the wrong thing |
When it is worth considering
- Workarounds are someone's job. Exports are copied between systems by hand, and the person doing it is one of your most experienced.
- Numbers stop agreeing. Two systems hold the same facts and nobody is sure which is right.
- The process is how you compete. Forcing it into a generic tool removes the advantage.
- Licence costs scale badly. Per-user pricing grows with your team while the value of the tool does not.
- Fragile integrations. A failure between tools stops the business.
A good test: if your team spends more time working around the software than using it, you are already paying for custom software. You are just not getting it.
When it is not
It is not worth it when a good product already does the job. Payroll, email, accounting and most standard processes fall in this group. It is also the wrong move when the requirements are still unclear and change every month, when nobody inside the business will own the software after launch, or when the real problem is a process or training issue that software will not fix.
What drives the cost
There is no honest single figure. A realistic estimate depends on scope (workflows, screens, rules), integrations, users and roles, data migration (often the most underestimated part), compliance and security such as UK GDPR, and running costs after launch. Ask for an estimate that lists its assumptions. A number with no assumptions is a guess. Building in stages helps, because you can stop or change direction after each one.
Questions for any supplier
- Who owns the code when the project ends, and do you get full access to it?
- Are the people you meet the people who build it?
- Is progress shown as working software in stages?
- What happens after launch, and who fixes problems?
- How is your data handled?
- What would make them say no? A good company can tell you which projects it would not take.
Start with the problem, not the technology: write down what is going wrong, who it affects and what it costs in time each week.
The full guide is on the Cognivise blog. For how we approach builds, see custom software development.
Top comments (0)