I build custom software for a living, and my most common recommendation is to buy something instead. That is not modesty. A product with thousands of customers has had its bugs found by other people, and someone else is on the hook to keep it running.
Custom software is the right answer less often than people selling it suggest, and more often than people who have been burned by it believe. Here is how I draw the line.
Buy when the problem is ordinary
If the task is one every business like yours has, such as scheduling, invoicing, payroll, email marketing or bookkeeping, a product already exists and it is almost certainly better than what you would commission. Its makers have spent years on edge cases you have not met yet.
The test is simple: can you describe what you need using the product's own vocabulary? If you want "recurring invoices with late-payment reminders", buy. That is a feature list, and somebody sells it.
Buy when you are not sure the process is right yet
Custom software fixes your current process in place. If you are still working out how you want to quote jobs or onboard customers, a flexible off-the-shelf tool lets you change your mind for free. Building first means paying to change your mind later.
Build when the work crosses tools
The most common good reason to build is not a missing feature. It is a gap between two products you already use. Your scheduling tool knows a job finished; your invoicing tool does not; a person carries the information across by hand.
No single vendor will fix that, because neither one owns the whole path. A small piece of software that watches one system and updates the other is often a small build, and it removes a task that happens dozens of times a week. This kind of connecting work is most of what small businesses need built.
Build when the tool makes you work its way
Sometimes a product does the job but forces a workflow that costs you time on every use: five screens to do what should take one, or a required field that means nothing in your trade. If you do that task all day, the friction adds up, and a narrow tool shaped around your actual steps can be worth it.
Be careful here. "I don't like the interface" is not the same as "this costs me an hour a day". Measure it first. I describe how in how to measure what repetitive admin work costs you.
Build when the process is the thing you sell
If how you do something is the reason customers pick you, that is worth owning. A product everyone can buy gives you the same process as your competitors.
The costs people forget
For buying: the monthly fee is the small part. The larger costs are the hours spent adapting your work to the tool, the data you cannot easily get back out, and price changes you do not control.
For building: the invoice is the small part. Software needs looking after. The services it connects to change, and something has to notice when it stops working. Ask anyone quoting you a build what happens in month seven. I wrote about that in monitoring automations that watch themselves.
A short checklist
Before paying for anything custom, answer these:
- Have you tried the built-in automation in the tools you already pay for?
- Is there a product for this exact job, and have you used its trial?
- Has the process been stable for a few months?
- Can you say how many hours a week the problem costs?
- Who will maintain what gets built?
If the first two answers are "no", start there. It is cheaper than a build, and you will learn exactly what you need if you do end up building.
Working through that decision for each repeatable task in a business is what my Workflow & Automation Audit does: every workflow gets a verdict of automate, buy, or leave alone. If you want to do a first pass yourself, start with what to automate first.