Stop automating broken processes

My ops manager custom built an incredible platform for us. And I told him to shelve it.

We're in the middle of a heavy lift right now—re-engineering our entire onboarding process and recruiting offer. Everything from the moment a client says yes through onboarding, recruiting (when necessary), and onboarding the new salesperson into our fractional sales management program.

Lots of moving parts.

So we get into one of the early planning meetings, and my ops manager—who, by the way, is brilliant. Tech nerd. Sharp, creative. If we're building anything in tech, AI, or automation, he's our guy—comes in with a custom platform he built to manage the new process.

He gave a full demo. Pipeline view, automation between steps, sales can see what delivery's doing, delivery can see what customer success is doing.

Honestly? The demo was pretty sweet.

And I said: This isn't what we need right now. Let's table it.

Not no. Not now. Here's why.

When you're rolling out a new process, the first question is: are we actually ready to systematize and automate this?

If you study people who have been serially successful—Elon Musk, Alex Hormozi, others who've started, scaled, and sold multiple businesses and proven it's not luck—they share a fundamental belief. Automate and systematize things last.

Elon used to be a disciple of automation. He believed the output-to-input ratio made it the obvious play for virtually everything. But what he learned—and what I keep relearning—is that it's actually a trap.

Here's what happens. You start focusing on systematizing the process, and you stop asking whether this is even the right process. Does it have steps you don't need? Are there things that should be eliminated entirely, not automated?

What most companies do—what my ops manager was about to do—is see a big, complex process, identify a need for efficiency or consistency, and jump straight to "how do we systematize this?"

It's natural. You keep asking yourself, will this scale? And you start engineering for scale before you've even proven the damn thing works. And who wants to scale something that doesn’t work?

But there's a second layer to premature automation. (Going to reuse that one.)

Once you automate something, you're immediately less agile.

If we rolled out this new process and this new platform with all the code and automation tied to it—yeah, it'd be cool. But there's no way this process is already perfect. It's brand new. It's going to require a lot of iteration.

And once it's been systematized and automated, you build a reluctance to change the stuff that needs to be changed. You've invested in it. It's wired in. Making adjustments becomes harder, not easier.

The only way to fix a prematurely automated process is to un-automate it and work backwards. So just don't do it to begin with.

Automate once the process works as well as it possibly can. Not before.

Before you go vibe coding a new proprietary system—whether it's because you love coding, because you get the dopamine hit of seeing something you built, or because you're creatively avoiding the shit that actually needs to get done—stop and ask: should I buy or should I build?

Building software is easy right now. I built my son a spelling bee app in 90 minutes—mobile, preloaded with voices, context for the word, the whole thing. And I don’t know shit about coding.

AI makes building new things easy. And it's easy to convince yourself that if it's custom, it's going to be better.

But have you factored in the ongoing development cost? The maintenance? The changes you'll need as technology evolves?

The companies your software is competing again have a massive head start, some of the best talent in the world, and some of the best data on what actually needs to be built. Your version may be custom, but is it better—and will it stay better?

And here's something people don't think about. When you build your own thing, you have unlimited optionality. You can do anything with it. And unlimited optionality makes decisions harder, not easier. Having parameters, boundaries, and limitations is can be incredibly helpful. It forces focus.

Then there's key-man risk. My ops manager said it was easier to build something than it was to learn how to integrate something. But like I told him, “It may be easier for you, but is it easier for the business?” What happens if he gets hit by the beer truck tomorrow? I’ve got to hire a developer every time I want to make a small change in my process.

So, be brutally honest with yourself. Are you getting that much benefit from building something from scratch that it offsets all the other costs and risks?

Even if the buy-versus-build math works out. Even if building your own thing is marginally better. You’ve got ask yourself, “Is this the highest-leverage use of that person's time?”

In our case, I have an AI sales coach I need developed. We have other opportunities to incorporate AI into our business and client offers. So was custom-building a CS platform for the customer journey the best use of my ops manager's time?

Not even close.

That's a question a lot of people skip. They go straight from "can we build this?" to building it, without ever asking "should we be spending our time on this versus something else?"

This wasn't a hard no. It was a pause.

Before we jump in with this platform, let's go through the process. Is this ready to automate? Do we know enough about the process and its effectiveness to lock it in? Have we done a proper buy-versus-build evaluation? Have we looked at the opportunity cost?

The answer to all these questions was no.

So for now, we focus on implementing the process manually. Running it, measuring it, evaluating whether it's working.

Then we determine how to systematize it by asking—what do we need to automate, which platform should we be on, and does it make sense for our internal resources to build this, or do we buy from companies that've been building this stuff for years?

With all of you building your own software right now, I thought our discussion may be useful to share.

Let me know what you think by commenting here.

Adios,

Ray

P.S. — I recorded a podcast on a similar topic for those of you who are vibe coding CRMs as your next product line. If you're an IT company going down that route, it might be worth a listen. Here it is. Sorry in advance if it’s harsh.