The default should be buy. Somebody has almost certainly built a product for your problem, and a product carries the cost of its own maintenance, security and updates across thousands of customers rather than just you. Build only when buying genuinely does not fit.
Buy when
-
The problem is common
Invoicing, bookings, payroll, help desks. If ten thousand businesses have your problem, a good product exists and it will beat anything custom on price and reliability.
-
The process is not your advantage
Nobody wins customers by having a distinctive way of filing expenses. Save custom work for the things that actually differentiate you.
-
You need it now
Buying is days. Building is weeks. If the pain is acute, buy something adequate now and revisit later.
Build when
-
The gap is the join, not the tool
You already own good tools that do not talk to each other. That gap is rarely a product, because it is specific to your combination. This is where most automation work actually lives.
-
The process is genuinely yours
If how you do it is why customers choose you, buying a generic version flattens the thing you are selling.
-
Every product forces a compromise you cannot make
If you have honestly evaluated three and each needs you to change something that matters, building is now the cheaper option.
The three signals that mean wait
The process changed twice this year. Automating an unstable process locks in something about to be wrong. Let it settle.
Nobody can explain it end to end. If three people describe the task differently, you do not have a process yet, you have a habit. Write it down before you automate it.
The payback needs three years. Anything that far out is a guess. Find a better first task and come back to this one.
The middle option people forget
Buy the product, then automate the join. Most businesses do not need a custom system; they need the product they already pay for to receive data automatically instead of by hand. That is a far smaller piece of work than building, and it is usually where the hours actually go.
Questions we get asked
How do we evaluate an off-the-shelf tool properly?
Run your three most awkward real cases through a trial, not the demo data. Products look identical until you give them the invoice with two purchase orders on it.
Is custom always more expensive?
To build, usually. Over five years, not always, once you count per-seat licensing on a growing team and the workarounds a product forces on you.
What if we build and then a product appears?
That is fine if your build is documented and exportable. Keep the process knowledge, switch the tool. It is only painful when the build was undocumented.
Can we start with a product and automate around it later?
That is usually the best sequence. Buy the system of record, then automate what feeds it. It keeps the risky custom work small and specific.