Configure, build, or both

Start by asking whether the process is common

If thousands of companies do roughly what you do, in roughly the same order, somebody has already built software for it. Invoicing, scheduling, email sequences, expense approval. Buy those. The version you'd build would be worse and you'd be maintaining it forever.

The test is whether you could describe the process to somebody in your industry and have them recognise it immediately. If yes, it's common, and common means buyable.

Then ask what the tool doesn't do

This is where most decisions actually get made. You buy the tool. It does about seventy per cent of the job. The remaining thirty per cent goes into a spreadsheet somebody maintains by hand, and that person becomes the integration layer.

Three questions decide what happens next.

How many hours a week does the thirty per cent cost? Under two, live with it. Over five, it's worth building something. Between the two, it depends on whether it's growing.

Is the thirty per cent the same every time? If it's a mechanical transformation, it can be automated with configuration. If it requires judgement, it either stays with a person or needs something built that supports the judgement rather than replacing it.

Does it touch two systems that don't know about each other? That's the most common shape of a build in a company with no engineers, and it's usually the cheapest one to justify, because the hours are countable.

When to build outright

When the process is what makes you different. If your quoting method, your routing logic or your assessment approach is why customers choose you, an off-the-shelf tool will make you average at it. This is the one case where building is obviously correct and people still hesitate.

When the data has to be right rather than mostly right. Configured automations are excellent at moving data and poor at guaranteeing they moved all of it. If a missing record is a compliance problem or a customer problem, you want something that knows what it processed and can prove it.

When you've already outgrown three tools. Companies often arrive with a stack of four subscriptions doing overlapping jobs, held together by manual steps. At that point the cheapest option is usually one thing that does the job, not a fifth subscription.

When the honest answer is neither

Sometimes the right answer is that the process isn't stable enough to automate. If it changed twice this year and will change again, automating it now means rebuilding it in six months.

The other case is volume. Automating something that happens four times a month rarely pays back, however annoying those four times are. Annoyance and cost are different measurements and it's worth checking which one you're reacting to.

The hybrid, which is what most jobs actually are

The real shape of most work is: configure the parts other people have solved, build the part that's yours, and connect them properly.

That means using an off-the-shelf tool for authentication, payments, email delivery and storage, and writing custom code only where your process is genuinely different. It costs less than building everything, it survives longer than configuring everything, and it means the custom part is small enough that one person can understand it.

The mistake in both directions comes from treating it as an identity question. It isn't. It's a question you answer per component, and the answer is usually different for each one.