Buying Software
We build custom software. It is also true that a good share of the businesses who ask us about it would be better served buying something that already exists, and saying so early costs less than discovering it during a build.
The usual framing — cheaper versus more flexible — is not much use, because it compares a subscription against a project fee and stops there. The comparison that matters is about fit, and about which costs each option hides.
Accounting, payroll, email, calendars, file storage, basic CRM, e-commerce checkout: these are processes your business performs but did not invent. Thousands of companies do them nearly identically, the regulations are shared, and the existing products have absorbed years of edge cases you have not thought of yet.
Building any of these yourself means paying to rediscover problems that were solved a decade ago. The right answer is almost always to buy, and to adapt your process to the product rather than the reverse.
The case for custom is narrower and more specific than most vendors admit. It holds when:
A subscription's hidden costs are process distortion and accumulation. You reshape how you work to match the product, gradually and without deciding to, and a seat price that is trivial at four people is not trivial at twenty. Data export is usually possible and rarely pleasant.
A custom build's hidden costs are the ones vendors are quietest about. Software needs maintenance — dependencies age, platforms change, browsers move. There is no support desk unless you arrange one. And the first version will be wrong in places, because the specification was written before anyone used it; the budget has to survive a second pass.
Any custom quote that does not mention what happens after launch is describing half the engagement.
The framing is rarely all-or-nothing in practice. Buy the commodity systems — accounting, email, storage — and build the narrow piece that carries your actual competitive process, connected to the rest. That is why our own packages are shaped the way they are: an Automation Sprint covers one repeating workflow across existing tools rather than replacing them, and an App MVP is deliberately one core flow rather than a system.
Take the process you are considering. Write down, in order, what actually happens today — every step, every decision point, every place something waits for a person.
Then look for existing products and check them against that list honestly, counting each step the product cannot do and each one where you would have to change how you work.
If the gap is small, buy, and change your process. If the gap is in the steps that make you different from your competitors, that gap is the specification for a build — and it is now small enough to price properly.
If you have not written the list, neither decision is informed yet, and that is the cheapest work available to you this week.
If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.
More from the blog
Buying Software
Five things decide what a custom system costs, and a feature list is not one of them. What scope, integrations, data migration, approvals and support each do to a quote — and what you can do to lower it honestly.
Operations
Spreadsheets do not fail gradually — they fail in four recognisable ways. Knowing which one you have tells you whether you need a better spreadsheet or something else entirely.