Start with the process, not the software
The question is never "should we build software". It is "what does this process require, and does anything already do it well enough".
Answer in that order and most decisions become straightforward.
Buy when the process is standard
Accounting, payroll, email, storage, basic CRM, helpdesk, e-commerce for conventional catalogues — these are solved problems. Products exist that have absorbed thousands of businesses' requirements.
Building your own is expensive, slower, less reliable, and produces a system whose entire maintenance burden is yours forever.
If your process is fundamentally the same as thousands of others, buy.
Build when the process is your advantage
Custom development is justified when:
- The process differentiates you. Something you do differently, and that difference is why customers choose you.
- Nothing fits without heavy modification. If a product needs so much customisation that upgrades break, you are building anyway, on someone else's foundation.
- Integration requirements are unusual. Connecting systems that no standard connector supports.
- Data ownership or compliance demands control that a hosted product cannot provide.
- Licensing economics break at your scale. Per-user pricing that becomes irrational as you grow.
The hybrid pattern most SMEs need
Standard products for the core — accounting, CRM, e-commerce, communication — with small custom applications for the two or three processes that are genuinely unusual, connected through documented integrations.
This gives you reliability and support where the problem is solved, and control where the problem is yours. It also keeps custom code small enough to maintain.
Counting the true cost of building
Development cost is the visible portion. The full cost includes:
- Requirements and design time from your own team.
- Testing and the inevitable rework.
- Data migration.
- Training and change management.
- Hosting and infrastructure.
- Ongoing maintenance, security patching, and dependency updates.
- Support when something breaks at an inconvenient time.
- The cost of the developer relationship ending, and someone else having to understand the code.
Budget maintenance as a recurring annual cost. Software that is not maintained becomes a liability quickly.
The failure mode: building the wrong thing well
The most expensive projects are not those that fail technically. They are those that are delivered on time, work correctly, and are not used, because the requirements described how someone believed the process worked rather than how it actually worked.
Prevent it by:
- Observing the process in operation, not only interviewing managers about it.
- Involving the people who will use it daily in design.
- Building the smallest useful version first and putting it in front of real users.
- Being willing to change the specification when reality contradicts it.
Phasing custom builds
- Phase one: the single most painful process, solved end to end for one team.
- Measure: is it used daily, and did it remove the pain.
- Phase two: adjacent processes, informed by what phase one taught you.
- Then: integrations, reporting, and refinements.
Any project that plans to deliver everything at once, months from now, should be restructured. Long unvalidated build cycles are where budgets disappear.
Protecting yourself in custom development
- Own the source code, in writing, in your repository.
- Own the infrastructure accounts.
- Require documentation as a deliverable, not a favour.
- Insist on standard, widely used technologies rather than an unusual stack only one developer understands.
- Plan for a handover as though it will happen, because eventually it will.
Signals you should have bought instead
- Your custom system is being modified to resemble a standard product.
- Maintenance consumes more attention than the process it supports.
- Nobody currently employed understands how a core module works.
- Upgrades to underlying dependencies are being avoided out of fear.
If two or more apply, evaluate replacing that component with a product and keeping only the genuinely distinctive parts custom.
The rule of thumb
Buy your commodity. Build your advantage. Keep the custom surface as small as it can be while still covering what makes you different — and treat maintenance as part of the purchase, not as a surprise that arrives in year two.
