When not to build it
Custom software is the right answer less often than the people selling it suggest, including us.
Build when the process is genuinely yours and doing it your way is part of how you compete. Buy when the problem is common, because somebody has already solved it, kept it updated for years, and will keep doing so after your project ends.
Three cases where building is the wrong purchase
The first is a solved problem: accounting, payroll, email, invoicing, calendars. Building one of these means paying to reach the starting line that a subscription puts you on this afternoon.
The second is a process nobody has agreed on yet. Software makes a process permanent, and building one before the business has settled the argument means paying twice: once to build it and once to change it after the argument concludes.
The third is a problem you have not yet felt. A system built for the volume you expect next year is a bet, and the version built for the volume you have is cheaper and teaches you which parts matter.
The spreadsheet that already works
Two people, a spreadsheet and a clear convention is a legitimate system, and replacing it with software is not automatically progress. The honest questions are whether the spreadsheet is losing data, whether more than one person needs it at once, and whether an error in it is expensive.
If none of those is true yet, the spreadsheet is the cheapest thing that works and the answer is to wait. Say that out loud, because it is easy to make waiting sound like doing nothing when it is a decision.
When building is the right call
When the process is a genuine difference in how you operate. When every available product needs so much configuration and workaround that you are effectively building anyway, without owning the result. When the data cannot leave your control for a reason you can state.
That last one is a real constraint and it is also the most frequently claimed without cause. Ask what specifically prevents it, and if the answer is a preference rather than a rule, treat it as a preference in the budget.
- Common problem, mature products exist: buy
- Process still being argued about internally: wait, then decide
- Product needs heavy workarounds to fit: build, and count the workarounds you avoided as the return
- Genuine regulatory or contractual constraint on the data: build
Count the cost of the thing you avoid saying
Suppose a product costs 2,000 dirhams a month and a custom build is quoted at 250,000. The build looks worse until somebody notices the subscription runs for years, and better again once the running cost of the build is added to it. The comparison is only useful over the same horizon with both running costs included.
Even then, the subscription buys something the build does not: somebody else keeps it working while you do your job. That is worth a real number, and it is usually left out of the comparison entirely.
What to take from this
- 01Solved problems are bought, not built
- 02Do not build a process the business has not agreed on yet
- 03A working spreadsheet is a system until data loss or concurrency makes it a liability
- 04Compare subscription and build over the same years, running costs included
Ask the question directly
- What about building on top of a product we already pay for?
- Usually the best of both, and the thing to check first is the export path. Extending a product is sound when your data can leave it in a usable form, and a trap when it cannot.
- Everyone in our industry uses the same product. Is that an argument to build?
- Only if the way you operate is genuinely different. Using the same tool as your competitors is not a disadvantage when the tool is not what distinguishes you.
- How do we decide when the answer is close?
- Buy, and revisit in a year with real usage. A reversed buy decision costs a subscription and a migration. A reversed build decision costs the build.
Related answers
AI transformation
Most AI projects fail because they add a chat box next to the problem instead of removing the step that costs the hours. We start from the workflow, and from the systems and the data underneath it.
Web development
New builds, rescues and re-platforms, measured against what the site earns rather than against how it looks. The brand system that carries it is built in the same engagement.
Bring the decision you are stuck on
A call, forty five minutes, no deck. We will tell you if we are the wrong firm.