17 July 2026 · 6 min read
Off-the-shelf software spreads its development cost across thousands of customers. Any argument for building has to beat that, and frequently it does not.
Short answer
Custom software is worth building when your process is genuinely a competitive advantage, when per-seat licensing has overtaken build cost, when data is retyped between systems daily, or when no product fits without a documented workaround. Outside those cases, buying is usually the better decision.
01 Straight talk
The honest test, applied before anybody writes code.
02 The test
Before comparing features, ask what your team does outside the system. The spreadsheet kept alongside the CRM. The WhatsApp group that exists because the software cannot route something. The paper notebook. Each of those marks a gap between what your systems do and what your business needs.
If those workarounds are small and occasional, buy a product. If they are documented, trained into new staff, and consuming a meaningful part of somebody’s week, that is the case for building — and it is a far more reliable signal than any feature comparison, because it is measured in hours rather than in checkboxes.
The third possibility is the one most often missed: neither. Frequently the answer is connecting two systems you already pay for, which costs a fraction of either option and removes the retyping that was the actual complaint.
03 Risk control
Software projects fail by growing, not by being technically hard.
— Questions
It scales with the number of distinct processes, user roles and integrations rather than with the number of screens. A fixed price for a defined first version, quoted after mapping the process, is more useful than an hourly estimate against an open scope.
A focused first version is usually weeks rather than months, deliberately. Long projects are where scope grows and budgets fail. Getting something small into real use early tells you more than a requirements document written before anybody used anything.
It is the right question to ask a small supplier. The answer is documentation and conventional technology — commented code, a documented database, and a stack many developers know. You should not be dependent on one person specifically.
Frequently, and it is usually cheaper. A purpose-written extension to a product your team already knows beats replacing it, and an integration between two existing systems is cheaper than either.
— More
AEO & GEO · 6 min
This is the single most common technical misunderstanding in AI search right now, and acting on it incorrectly can remove a business from Google Search altogether.
ReadAEO & GEO · 8 min
Almost every argument about generative engine optimisation comes from conflating two completely different things: what a model learned when it was built, and what it fetches when it answers.
ReadSEO · 7 min
It is still one of the most commonly sold local SEO tactics in India, it works briefly, and it is a named spam pattern in Google’s own documentation.
ReadFree consultation · No obligation
The reasoning on this page is public because I would rather be judged on it than on a claim. If you want it applied, that is the service.
Name, number, email, what you need.