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?
Thanks for writing this up. Bookmarking it for later.
I hope this helps you.
Really relatable. How much time do you put into this each week?
Whenever I'm not busy, I spend most of my time on this.
I’ve been thinking about this too.
I think there’s a useful distinction between automating a process and documenting a process.
When something is still changing, I’d rather make the workflow repeatable first, even if I’m doing parts of it manually. Once the same steps keep showing up, then automation becomes much easier to justify.
Otherwise, it’s easy to end up maintaining an automation for a problem that hasn’t really become a problem yet.
100%. I've pretty much adopted a 'do it manually 10 times first' rule now. If I find myself running the exact same 5-step routine ten times without changing anything, then it deserves an automation. Anything before that is usually just an excuse to write code instead of doing sales.
What made you pick this stack over the alternatives?
Honestly, speed and zero maintenance. I was already using Payhip for checkouts, and Make is visual enough that I could wire up Telegram alerts and Notion logging in under an hour without writing custom backend code or hosting serverless functions. It was just the path of least resistance to get a working workflow going.
Interesting approach. What was the hardest part to get right?
Honestly, handling edge cases in the Make webhooks. A standard Payhip order worked fine,spent way too much time debugging edge cases for orders I didn't even have yet.
Curious how long it took before you saw the first real results?
Appreciate the honesty here, most people only share the wins.
thanks
Building systems before you have enough customers is a sneaky stall. Doing a free text-only week for getting the next real customer action done — one done line + one next step a day. Happy to run one with you.
Love how lightweight this accountability setup is—one line done, one next step, zero fluff.
Thanks. If you want a free text-only week for the next customer step, just say — happy to run one.
There’s another downside to automating too early: you stop seeing the weird cases.
When you manually process ten customers, every awkward request and broken assumption is right in front of you. Automate it too soon and those lessons turn into silent edge cases.
Early manual work is inefficient, but sometimes that inefficiency is exactly where the product knowledge comes from.
Yeah, that’s something I’ve definitely underestimated. Some of the weird cases only show up with real customers. I was probably too focused on making the workflow work before I fully understood the process myself.
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.
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.
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.
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