When to buy an off the shelf tool, and when buying quietly stops working

Start from buy, not from build

If a tool exists that does the thing, is maintained by a company whose whole business is doing that thing well, and fits how you already work, buy it. You will get it this week instead of next month, someone else pays for the maintenance, and the fixes arrive without you asking.

The uncomfortable version, from a shop that builds custom systems for a living: a large share of the businesses that come to us asking for a custom build need something else. They need the tool they already pay for to be configured by someone who understands the workflow, or they need two tools they already pay for to talk to each other. Neither of those is a build.

• The workflow is common. Booking, invoicing, email sequences, e-signatures, payroll. Thousands of businesses do this identically, which is exactly why good products exist for it.
• You are the first automation you have ever run. Buy something, run it for a quarter, and learn what your actual constraints are. Almost nobody guesses those correctly in advance.
• The volume is low. A task that happens twice a month does not repay a build, however irritating it is. Irritation and frequency are different measurements.
• You need it working before you can prove it matters. A tool is the cheapest experiment available. Run the experiment first.

The two layers, and which one you are really asking about

Almost every real system has two layers, and confusing them is where the argument usually goes wrong.

The boring layer. Calendar, CRM, invoicing, payments, e-signature, phone numbers, storage. These are commodities. They are solved, they are maintained by companies with hundreds of engineers, and building your own is close to indefensible.

The seam. What happens between those tools: how an enquiry gets read, what counts as urgent for you, which job you decline, when a follow-up fires and when it stops, what gets written where, who gets escalated to and under what condition. This layer is yours. It is the part that reflects how your business actually runs, and it is the part no product ships with, because the product cannot know it.

When someone says "we need custom automation", they almost always mean the seam. When someone says "just use a tool", they almost always mean the boring layer. Both are right about the layer they are looking at.

The thresholds where buying stops winning

These are the specific conditions, not general vibes. If none of them apply to you, buy the tool and stop reading.

1. The tool does most of it, and the missing part is the part that makes money. A product that covers the routine and fails on your one profitable exception is not a partial win, it is a system your staff will work around by hand, which is what you were trying to stop.
2. The workflow crosses three or more tools and the glue becomes the product. One connection between two apps is a connector job. Six connections with conditional logic, retries and exceptions is software, and it deserves to be treated as software rather than as forty connector steps nobody can read.
3. Your seat count and your workload have stopped agreeing. Per-seat and per-contact billing is a fair model for software people use. It is a poor fit for a job that runs unattended at 3am and needs no seat at all. When you find yourself buying access for a machine, the model has drifted away from what you are doing.
4. The data cannot go where the tool wants to put it. Under Law 25 you owe your customers specific things about where their information lives and who can reach it. Some tools make that answerable and some do not. When a compliance obligation collides with a hosting decision you do not control, that is a build reason, not a preference. The detail is in the Law 25 guide.
5. The vendor's roadmap has become your bottleneck. You have filed the feature request, you got a sympathetic reply, and it has been nine months. If your operation is now waiting on someone else's release schedule, you have discovered the real cost of renting the answer.
6. You cannot get your own data out in a usable shape. Not the presence of an export button. Can you get the full history, with the relationships intact, in a format something else can read? If the answer is no, every additional month makes leaving harder, and the decision is quietly being made for you.

What you own in each case

Ownership is the dimension buyers underweight most, because it only becomes visible on the day you want to change something. This is what the two answers actually give you.

What leaving actually looks like

Ask this before you commit to either answer, because both have an exit and only one of them is usually described honestly.

Leaving a tool means the logic goes with the vendor. Your sequences, your rules, your branching and your history were expressed in their interface, and none of it transfers. What transfers is a spreadsheet of contacts. The work of rebuilding is not the data migration, it is the six months of accumulated decisions nobody wrote down.

Leaving a build partner should mean an afternoon of handover. That is only true if you set it up that way at the start, so make it an explicit requirement rather than a hope.

• Ask for the repository, not access to it. Code in an account you own, from the first commit, not transferred at the end as a goodwill gesture.
• Ask whose name is on the accounts. Hosting, database, API keys and phone numbers should be yours with the builder invited in, never the reverse.
• Ask who the documentation is written for. A runbook aimed at your operations manager is handover. A README aimed at developers is a file.
• Ask what happens on the day you say stop. The answer should be a date and a checklist, and you should hear it before you sign anything.

The answer that is usually right: buy the layer, build the seam

In practice the good version of this decision is not a choice between two columns. It is a line drawn in the right place.

Buy the calendar. Buy the CRM. Buy the invoicing, the payments, the phone numbers and the storage. Do not build any of it, and do not let anyone talk you into building any of it.

Then build the part that is genuinely yours: how an enquiry is read and answered, what your rules are for urgency and for work you decline, what the follow-up does and when it stops, what gets written back into the tools you bought. That layer is small, it is specific to you, and it is where the return is.

This is also why the honest scope for most first projects is narrow. One workflow, built on top of what you already run, in production in a couple of weeks. Preparing your business to automate covers what to have ready before that starts.

A decision you can make this week

1. Write the workflow down as it happens today. Every step, including the ones a person does in their head. Most build-versus-buy arguments are really disagreements about what the workflow is.
2. Mark each step: common or ours. Common means thousands of businesses do it the same way. Ours means it reflects a decision specific to your operation.
3. Search for a product that covers the common steps. There almost certainly is one. Shortlist two and note precisely which of your steps each one cannot do.
4. Look at what is left. If the leftovers are cosmetic, buy the tool. If the leftovers include the step that decides whether you win the job, you have found the seam and you know what to build.
5. Check the exit before you commit. For the tool, try the export today rather than in two years. For the build, get ownership and handover written into the scope.