Custom software vs off-the-shelf: a decision framework that will not waste your budget
Buy the product, or build your own? Companies burn budgets on both wrong answers. A practical framework: when off-the-shelf wins, when custom pays, and the hybrid route most businesses should actually take.
Every few years a company faces the same fork: the spreadsheet chaos has become unbearable, the packaged product almost fits, and someone says “why don’t we just build our own?” Both directions have graveyards. Off-the-shelf implementations that never matched how the business works; custom builds that took two years and shipped half of what was promised. The framework below is how we argue it in writing before a dirham is spent.
When off-the-shelf wins
Buy the product when the process it covers is not what makes you different: accounting, payroll, email, HR records. These are commodity processes: the packaged product is cheaper, faster to deploy, and maintained by someone with thousands of customers. The mistake is not buying commodity software; the mistake is bending your differentiating processes to fit it.
When custom pays
Build when the process is your edge: how you quote, how you schedule production, how you serve customers in a way competitors do not. Custom software there is not a cost, it is the mechanism that makes the advantage repeatable and scalable. The other clear case: when re-typing between systems consumes hours daily. Integration software is unglamorous and pays for itself with embarrassing speed.
The hybrid route most companies should take
Keep the packaged core (ERP, accounting) and build the thin custom layer around it: the quoting portal on top of the ERP, the customer app that reads from it, the dashboard that joins it with the webshop. You get the vendor’s maintenance on the commodity part and your own advantage on the layer that matters, without a two-year mega-project.
The four questions to ask before deciding
Is this process a differentiator or a commodity? What does the packaged product cost over five years, licences and forced upgrades included? What does the custom build cost over the same five years, maintenance included, not just the build price? And who owns the code if we part ways with the developer? (If the answer to the last one is not “we do, in writing”, walk away.)
Where builds actually fail
Rarely on technology. They fail on scope nobody wrote down, on a fixed deadline meeting an unfixed wishlist, and on discovery skipped to “save time”. The fix is boring and works: a paid discovery phase that produces the architecture and a written proposal for release one, with its scope and its commercial terms in it. Small enough to ship in months, real enough to prove the value. Anyone who quotes you a big number for a big build without discovery is guessing with your money.
What is the manual work costing, and when would a build pay for itself?
Put in the manual task and the build cost you have been quoted, and this works out the annual cost of the hours and how long the saved hours take to cover the build. Every box starts empty and every figure is yours.
Your own internal cost of an hour of the people doing this task, salary and everything you pay on top of it, divided by the hours they work. It is your number about your staff. It is not a Vega Sky rate and we do not publish one.
AEDIndicative, and built entirely from figures you enter. Every box starts empty, including the build cost: we do not publish a price for a build, ours is set after we understand the scope and arrives as a written proposal, so the figure is one you have been quoted or have budgeted. The arithmetic assumes the hours removed are hours people actually give back, which is worth asking out loud before you build.
Start with a conversation
An initial consultation with a consultant rather than a salesperson, about your IT, security or systems question.