Joshua Anthony
Every few weeks we sit in a first meeting with an organisation that has already talked itself out of custom software. The reasons are almost always the same three, they are repeated with total confidence, and they are usually wrong in ways that cost the organisation money for years. Having built custom platforms for public sector bodies, banks, telecoms and NGOs since 2011, we want to take those three beliefs apart properly, and also be honest about the cases where they hold.
Misconception one: custom software is too expensive
This belief survives because the comparison behind it is rigged. Organisations put the sticker price of an off-the-shelf licence next to a custom development quote and stop there. That is not a cost comparison. It is a comparison between one vendor’s first invoice and another vendor’s total price.
A real comparison prices the full life of each option. On the off-the-shelf side, that means licence fees that scale per seat every year, forever. It means the customisation and consulting work needed to make a generic product fit your operation, which for serious platforms routinely exceeds the licence cost itself. And it means the workarounds: the spreadsheets, manual re-entry and shadow processes your staff invent to plug the gaps a generic tool cannot fill. Those workarounds are the most expensive part because they never appear on any invoice. They show up as payroll hours, data errors and decisions made on stale information, compounding quietly for as long as the system is in use.
Custom software inverts that cost curve. The investment is concentrated up front, and what you get for it is a system with no per-seat licence meter running, no gap between how the software works and how your organisation works, and an asset you own rather than rent. Over a five to ten year horizon, which is how long core systems actually live, the maths frequently favours building. Not always, but far more often than the sticker price comparison suggests.
Misconception two: custom takes too long to be worth it
This one comes from a real place. The industry earned this reputation through waterfall projects that disappeared for eighteen months and returned with something nobody wanted. But the failure there was the delivery method, not the idea of building.
A well-run custom build is scoped in phases against your actual priorities. The first release contains the workflows that matter most, ships in months rather than years, and starts generating value while the rest is still being built. Compare that honestly against the off-the-shelf timeline, which is rarely as instant as the demo implies. By the time a generic enterprise platform has been configured, customised, integrated with your existing systems and rolled out to staff who must now adapt their processes to fit it, a phased custom build has often already been live for a quarter.
There is also a category of work where the timeline question answers itself: systems that must integrate with infrastructure global products were never designed for. We build platforms that connect to mobile money rails, national payment gateways and public sector systems, and that operate in environments where connectivity cannot be assumed. No amount of configuration makes a product built for a Northern European office park handle those requirements. The customisation project never ends because the fit was never possible.
Misconception three: custom software is only for large enterprises
This is the most persistent of the three, and our own project history is the counterargument. Some of the highest-impact platforms we have built exist for one simple reason: no product on the market addressed the problem at any price. Revenue collection tailored to a specific country’s legal framework. Vocational training delivered to learners without reliable connectivity. Microbanking for rural savings groups. Nobody sells these off a shelf, and the organisations that needed them were not all large. What they had in common was a problem specific enough that generic tools ignored it.
Size is the wrong variable. The right question is how much of your operation is specific to you. An organisation whose processes are genuinely standard can and should use standard tools. An organisation whose competitive advantage, regulatory environment or delivery model is unusual will find that off-the-shelf software quietly forces it to become more ordinary, because the software only supports what everyone else does. For those organisations, building is how they stay themselves.
When off-the-shelf really is the right answer
Credibility requires saying this part too. If your need is email, accounting, HR administration or any function where your requirements match everyone else’s, buy the product. The market has invested thousands of engineering years into those tools and you will never match that economy by building. We tell prospective clients this regularly, sometimes to their surprise, because recommending a build where a product would do is how a development firm burns its reputation.
The honest decision rule looks like this: buy for functions where you are like everyone else, build for the functions that make you different, and be rigorous about which is which. Most organisations need both, connected properly. That last part, the connecting, is where a lot of the real engineering lives.
The cost of believing the misconceptions
The organisations held back by these beliefs are not the ones who evaluated custom software and chose against it. They are the ones who never ran the evaluation, because “too expensive, too slow, not for us” ended the conversation before it started. Meanwhile their teams spend hours each week on workarounds, their licence costs climb with every new hire, and their systems define what their operation can be instead of the other way around.
If any of that sounds familiar, the evaluation is worth running. Get in touch and we will give you an honest read on whether your problem calls for building, buying, or a combination of the two.
