Custom software beats another subscription when one specific problem keeps costing you real time or money and no tool you can buy fits it without workarounds. It loses when a setting in a tool you already pay for would solve it, or when you cannot yet say what the problem is. Here is the checklist I use to decide, and the examples behind it.
The case where building won
Atlas is the CRM I built for my own work. I was paying more than 1,500 euro a year for a CRM that did not fit what I needed, and leads, emails and deals lived in different tools. So I built one on a single shared data model, with every customer in one timeline. It is live today in four editions (Sales, Recruitment, Construction and HR/Payroll), and Beacon and Vecta write straight onto the same customer record.
Notice the size of it. It was a thin layer over tools the team already used, joined together around one problem: what happens to a lead in the first hours. That is often the right scale.
What custom work really buys you
Argus is a product I built for my own use: an Instagram roster monitor for agencies. The supplier you can actually buy data from returns only the twelve most recent posts and quietly ignores requests for more. A tool that compared that window against a stored archive would announce that a whole back catalogue of posts had been deleted, when nothing had happened. I had to design around that limit from day one.
That is the real difference. Off-the-shelf software is built for the average case. When your case is not average, the gap shows up as a workaround, then as a mistake. Custom software lets you build the edge case in, instead of living with it.
Build or buy: the checklist
Lean toward building when most of these are true:
- You can state the problem in one sentence and say how you would measure it fixed
- The problem sits in the middle of how you win work or serve customers
- Every tool you tried needs two or three workarounds to fit
- Your data is scattered across tools that do not talk to each other
- The cost of the problem, in hours or lost customers, is bigger than the cost of the fix
When not to build
This part matters more, because a wrong build is expensive. Do not build when:
- A setting, an integration or a different plan in a tool you already own would fix it
- The process changes every month, so you would be coding a moving target
- You cannot say what success looks like
- Nobody on your side will own the software once it exists
- A subscription costs less than the time you would spend arguing about the build
Before any build, I ask whether a better process would do the job first. Sometimes the answer is a short document and a changed habit, not code. I would rather tell you that on the free call than sell you something you do not need.
“The best custom software solves one problem so well that you forget it is there. If it needs a manual to explain, I built too much.”
One more example, on scale
Global Explorers Club, a travel membership community, needed one fast landing page to test demand for a new retreat programme before a full site. Their old site scored 34 on PageSpeed Insights. The new page reached 96 or higher, and the time to interactive fell from 5.2 seconds to 1.1. The point is the scope: one page, one goal, built before anything bigger was committed.
Questions to ask whoever builds it
Who owns the code when it is done? What happens when you need a change in six months? How will you know it works? A good builder answers those without hesitating. If you want a second opinion on a quote you have received, the software page explains how I work, and the free call is the quickest way to get my honest view.