Short answer: most SMEs should buy off-the-shelf software for most tasks, and build only where the company genuinely differs from its competitors. You're rarely unique in invoicing, payroll or office work. In how you produce your own service, you often are. Between the two there's a third route: a low-code or no-code platform, faster than custom development and more flexible than a packaged product.
The question rarely comes up cleanly. Usually it surfaces as "our current system can't do this", followed by someone saying "then let's build our own". Sometimes that's the right call. Often it's just a more expensive route to the same problem.
What experience says
The UK government's purchasing guidance is the clearest neutral set of decision criteria we know. It says building is justified when:
- the need is unique or rare;
- few suppliers can meet it;
- commercial products can't be adapted or integrated;
- the organisation needs to own the technology;
- and the organisation is able to manage the development.
Buy when a product meets most needs through configuration with little customisation. The guidance also stresses that every customisation raises cost, complicates maintenance and restricts upgrades.
Point 11 of the UK Service Standard adds: look at the total cost of the technology over its whole life, and avoid lock-in.
The risk: black swans
The biggest risk in custom development isn't the average overrun but the rare, very expensive derailment. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects. The average cost overrun was 27%, which is still manageable. But one project in six became a "black swan", with an average cost overrun of 200% and a schedule overrun of almost 70%.
Two lessons come back again and again in the Standish Group's long-running CHAOS reports: small projects succeed far more often than large ones, and iterative, agile projects have a much higher success rate than waterfall ones. The exact figures should be treated with care because the definitions have changed over the years, but the direction is clear: small, iterative steps carry less risk.
The three routes
| Off-the-shelf | Low-code / no-code platform | Custom development | |
|---|---|---|---|
| Good when | the process is industry standard | a unique process built from standard blocks | a truly unique need or competitive edge |
| Time | days, weeks | weeks, months | months, years |
| Upfront cost | low | medium | high |
| Flexibility | low | medium to high | high |
| Maintenance | the vendor's | shared | yours |
| Main risk | you adapt the process to the product | platform lock-in | overruns, black swans |
For many SMEs the middle route is best. The platform provides user management, the database, forms, permissions and reports, and the company's process is built on top, with no or little code. The price is platform lock-in: check up front how data can be exported and what happens if the platform's prices or terms change.
What we've seen
Two earlier projects of our team show the middle route well.
A vaccine production calculator. At the US subsidiary of an international animal health company, researchers and bioengineers calculated vaccine composition, dosage and production processes in spreadsheets and on paper. We built a calculation and record-keeping system on the QuickBase platform that guides users through the process and makes resource needs, lead time and raw material use predictable. It went live in six months and is used by 20 researchers and engineers.
Mobile audits. At the same company, vaccine storage and use on customers' farms were audited on paper. A web and mobile audit system was built on the OutSystems low-code platform, integrated with Bureau Veritas, producing an official certificate. Our team led development and provided project management and the architecture. It went live in four countries in eight months.
Neither would have worked with a packaged product, because the process was unique. And neither would have been worth writing from scratch, because the platform provided most of the backbone.
Total cost, not the first price
An off-the-shelf product costs a subscription; custom development costs a project fee. You can only compare them over the whole lifecycle. Work through five items for at least five years:
- implementation or development: the initial work;
- subscription or hosting: servers, licences, platform fees;
- maintenance and updates: security patches, operating system and browser changes, regulatory changes;
- further development: because needs change;
- exit: what it costs if you ever want to switch.
The biggest hidden cost of custom software is maintenance. In an off-the-shelf product, the vendor carries the cost of regulatory changes, security updates and new browsers. In a custom system, you do. If the software touches invoicing, tax or data protection rules, every regulatory change means another development round, and you don't set its deadline.
Who owns the code?
This is the point most SMEs forget in the contract. Rules differ by country, but the pattern is similar in many jurisdictions:
- code written by employees as part of their job usually belongs to the employer, unless agreed otherwise;
- code written by an external contractor does not automatically become yours: the contract has to transfer the rights or grant you a licence.
Hungary is a typical example: its copyright act makes economic rights in software transferable and gives them to the employer for work done by employees, but nothing is automatic with an external developer.
With an off-the-shelf product, the law usually gives a lawful user some basic rights (use, bug fixing, a backup copy), but the source code stays with the vendor.
In practice: for custom development, the contract should cover handing over the source code and documentation, the transfer of rights or an exclusive licence, and the fact that the data is yours. The UK guidance also recommends break clauses of two years or less and clear terms on data and intellectual property.
The common fourth route: off-the-shelf plus a custom add-on
The choice is rarely either/or. The most common good solution in an SME is an off-the-shelf backbone (business system, invoicing, office suite) with only the genuinely unique part built separately and connected through a well-documented integration.
The precondition is an open product: a well-documented API through which data can flow in and out. Weigh that during selection as seriously as the features.
Five common mistakes
"Nobody has done this before." Most processes that look unique at first are a variant of an existing product category. Before you start building, search thoroughly and ask a few vendors.
The process isn't written down. If the developer learns the process during development, the project becomes discovery, not development. Process first, software second.
Everything at once. Every idea collected over the years goes into the first version. That's the recipe for a black swan. Keep the first version narrow and make it work.
No owner. A custom system needs an internal owner who knows what it's for and decides on further development. Otherwise the software becomes the development company's product, not yours.
No exit plan. If the development company closes or becomes unreachable, do you have access to the code, the documentation and the server? If not, your company depends on a system nobody can maintain.
If you do build: keep it small and visible
If custom development is the right answer, the way you run it matters as much as the decision. Agree on a narrow first version that real users can try within weeks, not months. Ask for working software at short, fixed intervals rather than progress reports. Keep a written list of what is in scope for each step, and put new ideas on a separate list for later. And make sure someone on your side has the time to test each version and say clearly what's wrong. Most custom projects don't fail because the developers can't code; they fail because nobody on the customer's side had time to look until it was too late.
Five questions before you decide
- Do we differ from our competitors in this process? If not, buy.
- Could we change the process to fit an existing product? That's often cheaper than adapting the product to the process.
- Is there a platform on which the process can be built with no or little code? If so, that may be the middle route.
- Who will maintain it in five years? If there's no answer, custom development is risky.
- What's the exit plan? How do you get your data back if you need to switch?
What to do now
- Write down the process you need software for, including your most complicated everyday cases. One or two pages are enough, but include who does what, with which data, and the common exceptions.
- Look at two or three off-the-shelf products using the same cases.
- Look at a platform-based solution too, if the products don't fit.
- Work out the total cost over five years, including maintenance and exit.
- For custom development, split it into small steps: a narrow working version first, then extensions.
- Put the fate of code, documentation and data in the contract.
If you're not sure which route is right and want an independent look at your requirements, have a look at our custom software development and IT consulting services.
FAQ
When is custom software worth it?
When the need is genuinely unique, few suppliers can meet it, products can't be adapted, and the company can manage the development and maintain it long term. Typically where the process is part of your competitive edge.
How much more expensive is custom development?
It depends on the task, but lifecycle cost matters more than the initial price, because maintenance and further development are yours. The risk is higher too: in one large sample, one IT project in six overran its budget by 200% on average.
What is a low-code or no-code platform?
A development environment where most of an application is built with visual tools and little or no code. A unique process is ready faster than with fully custom development, but you need to weigh the risk of platform lock-in.
Who owns the source code if an outside company develops it?
Only what the contract says. In many jurisdictions, rights in contractor-written code don't transfer automatically. Put the transfer of rights or an exclusive licence, and the handover of source code and documentation, in the contract.
How can the risk of custom development be reduced?
With small, iterative steps: a narrow working version that users try out first, and only then extensions. Research shows small projects succeed far more often than large ones.
Sources
- GOV.UK – Define your purchasing strategy
- GOV.UK Service Manual – 11. Choose the right tools and technology
- Flyvbjerg, Budzier – Why Your IT Project Might Be Riskier Than You Think (arXiv 1304.0265)
- OpenCommons – CHAOS Report on IT Project Outcomes
- Planning Planet – Successful Projects: What We Really Know
- Hungary – Act LXXVI of 1999 on Copyright (in Hungarian)
