When I started building my digital product automation system, I thought I knew what I was doing.
I had a simple idea.
A customer buys something.
The system should handle the repetitive work automatically.
So I started connecting things.
Payhip for the purchase.
Make for the workflow.
Telegram for notifications.
Notion for tracking.
Later, MailerLite for email follow-up.
The individual pieces weren’t particularly difficult.
Getting them to work together was the interesting part.
And I enjoyed it.
Probably a little too much.
I kept finding things to automate
Once the first workflow worked, I started seeing more opportunities.
“Maybe I should automate this too.”
Then another thing.
Then another.
Before long, I had workflows handling things that weren’t actually causing me much manual work.
Technically, they worked.
But that wasn’t the right question.
The better question was:
Was the automation actually solving a problem?
Sometimes the answer was no.
The part I underestimated
When you build a workflow yourself, it’s easy to focus on whether the workflow works.
Does the webhook fire?
Does Make receive the data?
Does the Telegram message arrive?
Does Notion get updated?
Does the email get sent?
If all of those are working, it feels like you’ve built something useful.
But there’s another layer.
Does this process happen often enough to justify automating it?
Do I actually understand the process yet?
What happens when the input isn’t what I expected?
What happens when a real customer does something I didn’t anticipate?
Those questions only became obvious after I started using the system.
Some problems only appeared later
One thing I learned from working with webhooks is that the data you expect isn’t always the data you receive.
A test payload can look perfect.
Then a real event comes in with a missing field or a slightly different value.
A workflow that looked completely reliable suddenly needs another check.
The same thing happens with business processes.
You can design the workflow in your head.
But real usage tends to find the parts you didn’t think about.
That’s one reason I’m less interested in automating a process before I’ve used it manually.
Manual work isn’t always wasted time.
Sometimes it’s how you learn what the automation actually needs to handle.
I changed how I build workflows
I used to start with:
“How can I automate this?”
Now I usually start with:
“How does this process actually work?”
I’ll run it manually.
I’ll see where I repeat myself.
I’ll notice where things go wrong.
I’ll see which steps are predictable.
Then I’ll decide what is worth automating.
This sounds slower.
In practice, it can save a lot of rebuilding later.
A simple example
Imagine a digital product order.
The manual process might be:
Customer buys
↓
Check the order
↓
Deliver the product
↓
Record the customer
↓
Send a notification
↓
Follow up later
I don’t necessarily need to automate every one of those steps immediately.
Maybe the first useful automation is simply:
Customer buys
↓
Payhip event
↓
Make
↓
Record order
↓
Telegram notification
That’s already useful.
After using it for a while, I might discover that customer follow-up is becoming repetitive.
Then I have a real reason to automate that part too.
This changed how I think about NomadOS
NomadOS started as an automation project.
But the more I build it, the more I think the important part isn’t the automation itself.
It’s the decisions around the automation.
What should be automated?
What should stay manual?
Where should the data live?
What happens when something fails?
How much maintenance is reasonable?
When should a workflow be split into smaller workflows?
Those questions are harder than connecting two services.
They’re also much closer to the problems I actually want NomadOS to help with.
What I’m doing differently now
I try to keep each workflow responsible for one clear thing.
I validate important data before doing something irreversible.
I think about duplicate events.
I add logging when I need to understand what happened.
And I try not to add another automation just because I can.
The last one is probably the hardest.
There’s always another integration you can add.
There isn’t always a reason to add it.
The lesson I’m taking from this
I still like building automation.
I still think it can remove a lot of repetitive work for a small business.
But I don’t want to build automation for the sake of having more automation.
I’d rather have three workflows that I understand than fifteen workflows that I have to babysit.
That’s probably the biggest change in how I’ve been building NomadOS.
Build the process first.
Understand the problem.
Then automate the part that is actually worth automating.
I’m still learning this as I go, but it’s already changed the way I build my workflows.