3
4 Comments

I built the automation before I had enough customers

I think I made a pretty common mistake while building my digital product business.

I automated too much, too early.

I had Payhip for selling products.

Make for connecting things.

Telegram for notifications.

Notion for tracking.

Then I added email automation.

On paper, it looked great.

A customer buys something.

The order gets processed.

The information gets recorded.

I get a notification.

The customer gets follow-up emails.

Everything is supposed to happen automatically.

The problem?

I didn't have enough customers yet.

So instead of spending most of my time improving the product or getting people to see it, I was spending time checking whether my automations were working.

A webhook didn't behave the way I expected.

A field was missing.

One workflow needed to be changed because another workflow depended on it.

Then I would think:

"Maybe I should automate this part too."

That's when I realized I was solving a problem I didn't really have yet.

The automation itself wasn't the problem.

The timing was.

I was building for the business I imagined having instead of the business I actually had.

So I've started changing how I build.

Now I ask myself:

Does this happen often enough to automate?

Will this actually save me time?

What happens if it breaks?

And probably the most important question:

Would I still build this if I only had a few customers?

Sometimes the answer is no.

And that's okay.

I'm still building automation systems.

I just don't want the system to become another thing I have to manage.

Right now, I'm trying to build the smallest workflow that solves the real problem in front of me.

Then I'll add more when I actually need it.

I'm curious how other indie hackers handle this.

Do you build your systems ahead of growth, or only automate after the manual work becomes painful?

on September 20, 2026
  1. 1

    There is a cheap test I wish I had used earlier: compare how many times a week the thing actually runs against how many hours it took to wire up. If a workflow fires twice a week and cost six hours, it has to survive months before it breaks even, and most early workflows get rewritten well before that. The other cost is the one you are pointing at: at low volume, doing it by hand is the only place you find out what customers actually do after they buy. Automating early does not just waste the hours, it removes the one feedback channel you had while the numbers were still small enough to read.

    1. 1

      Yeah, that’s a really good way to look at it. I’ve definitely spent too long building workflows that didn’t run often enough to justify the setup. And the point about manual work being a source of feedback is something I hadn’t really considered before. I’m starting to think that’s one of the biggest reasons not to automate too early.

  2. 1

    I actually took the opposite approach. I kept things manual while we were figuring out the product and getting our first users, then started automating once the repetitive work became a real bottleneck. That made it much easier to know what was actually worth automating.

    1. 1

      Yeah, I’m starting to realize that too. Doing something manually for a while makes it much clearer what’s actually worth automating. I definitely automated a few things earlier than I needed to