Before You Automate, Ask If You Should Be Doing This at All

I've spent twenty years building things that automate other things. I can usually see the automation opportunity in a problem within five minutes of hearing it. That instinct has been useful. It has also been wrong.

The spreadsheet wasn't the problem

She manages a marketing agency. Five clients: two high-ticket, three low-ticket. Her team tracks every hour — SMM work, offline requests, concierge services, admin. She keeps a spreadsheet. She knows exactly where the time goes.

She came to me for advice about operations.

My first instinct kicked in immediately: show me where the time drains. I work closely with SMM agencies — I'm building a product for this specific problem — and I've seen this pattern before. Content assets scattered across WhatsApp and Google Drive. Reports assembled by hand every week. The same manual steps, same person, every Friday. I started mapping what could be automated: content generation, file organisation, report exports, post scheduling.

We discussed it for twenty minutes. The signal was already there: every time she described something that was eating hours, she named a specific client, not a specific task type. Not "reporting takes too long" — but "this one client needs a different format every week." Not "content creation is slow" — but "this client keeps changing the brief." These weren't process inefficiencies. They were client relationship problems wearing process problems' clothes.

She asked the right question before I did

The time-consuming tasks weren't a process problem. They were a client mix problem.

The three low-ticket clients weren't just paying less. They were generating most of the operational noise — concierge requests, offline tasks, admin overhead that didn't scale down proportionally with their fees. I was about to design an automation layer on top of a business structure that was working against her.

Then she asked the question herself:

"What if I don't need to automate any of this — what if I should just raise my prices?"

I stopped. That was it.

Not "how do we do this faster?" but "should we be doing this at all?"

The math, without any automation

Say she raises her prices by 50%. One of the three low-ticket clients leaves — the one generating the most noise was always going to be the first to leave on price. The other two stay. Two clients at 1.5x equals three clients at the original rate. The revenue holds.

Same revenue. One fewer client. A significant amount of reclaimed capacity. Time to focus on her two high-ticket clients — the ones worth growing. Time to promote her own agency instead of grinding through admin for clients who were never going to scale with her.

That's one option. Not the only one. But it costs nothing to model, it takes twenty minutes to think through, and it doesn't require writing a single line of code.

Two modes, one wrong for this conversation

There are two distinct modes I operate in during these conversations.

The first is the builder. Twenty years writing code, 30+ products — some still running, some in the graveyard — and I have a strong instinct to find a problem and start moving toward a solution. Show me where your team wastes time and I'll find you something worth building. This mode kicks in fast. It has shipped a lot of real things.

Automator, a music publishing pipeline I built in 2021, came from exactly this instinct: repetitive tasks, high volume, predictable steps, no ambiguity about whether the work should exist. It still runs autonomously today, under ten minutes a day. That was the right call. The difference between that problem and this one: those tasks existed regardless of who the clients were.

The second is the person who has watched enough builds fail to know that building is a process, not the goal. The goal is an outcome. Sometimes the outcome is reachable without building anything.

The tension between these two is something I notice now when a conversation feels off — when I'm twenty minutes into mapping a problem and realise I'm solving the wrong one.

Does this work need to exist at all?

The tell here was the client structure. She wasn't describing an operations problem. She was describing a pricing strategy problem that looked like an operations problem from the inside. Every hour her team spent on low-ticket admin was an hour unavailable for clients who could actually grow the business.

Automation would have made that situation faster. It wouldn't have made it better.

This applies beyond agencies. Whenever a founder comes to me wanting to build a tool or automate a process, the first question I ask now is: does this work need to exist in the first place? Not "can we build this?" or "how long would it take?" — but "if we removed this entirely, what would actually break?"

Often: less than they expected.

Three questions I now ask before mapping any automation:

• Who created this process, and why does it still exist? Many processes outlive the reason they were introduced. Nobody removed them because nobody questioned them.
• If this task disappeared tomorrow, who would notice — and would that actually be a problem? The answer tells you whether you're solving a real constraint or maintaining inherited inertia.
• Is this task repetitive because the work is repetitive, or because the relationship is? Automation handles the first. The second requires a different conversation entirely.

Before you hire an engineer, subscribe to a no-code tool, or spend three months building something — spend an hour asking whether the problem is what you think it is. Sometimes it's an operations problem. Sometimes it's a pricing decision, a client you should have dropped six months ago, or a process that only exists because nobody questioned it.

Building is a process. Figuring out what to build — or whether to build at all — is the actual work.