DEV Community: Eva

What I Check Before Trusting a Digital Product Automation Workflow

Eva — Mon, 09 Nov 2026 13:00:17 +0000

Getting an automation workflow to run is one thing.

Trusting it to handle real orders is another.

When you connect Payhip, Make, Telegram, and Notion, it's easy to focus on whether all the tools are connected. But a successful test doesn't necessarily mean the workflow is ready to handle real customers.

There are a few things worth checking before relying on it.

Here is the checklist I use when thinking about a digital product order workflow.

1. Check whether the payment event is received correctly

The workflow starts with a purchase event from Payhip.

Before moving on, check:

Does Make receive the expected event?
Is the correct product identified?
Is the order reference available?
Does the workflow distinguish a successful purchase from other events?

Don't assume that a connected webhook means everything is working correctly.

Inspect the actual data received by Make.

2. Make sure notifications contain useful information

Telegram notifications are useful because you don't have to keep checking your payment dashboard.

But a notification should tell you something meaningful.

For example:

Product name
Order status
Order reference
Date of the event

Keep the message simple.

Also, avoid including sensitive customer or payment information that isn't necessary for the notification.

3. Keep order records organized

A notification tells you something happened.

A database helps you keep track of what happened over time.

If you're using Notion to organize orders, useful fields include:

Order reference
Product name
Order status
Order date
Customer reference

One thing worth considering is duplicate events.

If the same purchase event is processed more than once, you don't want to create multiple records for the same order.

Using a stable order reference to identify existing records can help prevent this.

4. Think about what happens when something fails

This is easy to overlook.

What happens if:

Make receives incomplete data?
Telegram fails to send a notification?
Notion cannot create a record?
The same event is received again?

A workflow shouldn't be considered reliable just because the successful path works.

Check the execution history in Make and make sure you can identify where a failed operation occurred.

For important steps, consider how errors should be handled and whether a failed operation needs to be retried.

5. Test the whole workflow, not just individual connections

A connected Payhip account, Telegram bot, and Notion database don't automatically make a complete system.

Test the process from beginning to end.

Follow the actual sequence:

Generate a test purchase event.
Confirm Make receives the expected information.
Check that the Telegram notification is correct.
Confirm the Notion record contains the expected fields.
Review the execution history for errors or duplicate processing.

Only rely on the steps you've actually tested.

6. Keep the workflow as simple as possible

It's tempting to add more notifications, database views, and automation scenarios.

But every additional component creates something else to maintain.

For a small digital product business, I'd rather start with a workflow that handles three things reliably:

Recognize an order.
Notify the right person.
Keep an organized record.

More features can come later when there's a real reason to add them.

Final thought

I've spent quite a bit of time working with Payhip, Make, Telegram, and Notion.

One thing I've learned is that connecting tools is only the beginning.

The more important question is whether the workflow can handle the everyday situations that happen after a real customer places an order.

A simple workflow you understand and can maintain is more useful than a complicated one you don't fully trust.

For those building automation for digital products:

What's the one thing you always check before allowing an automation to handle real customer activity?

If you'd like to explore the workflow examples, the project is available here:

NomadOS Automation Examples on GitHub

For the complete starter system:

NomadOS Core — Digital Product Automation Starter System

How to Track Digital Product Orders Without Checking Every Dashboard

Eva — Sat, 24 Oct 2026 13:00:05 +0000

When you sell digital products, getting a sale is only part of the workflow.

You may still need to check the order, confirm delivery, notify yourself, and keep customer information organized.

At first, doing this manually feels manageable. But as you add products and sales channels, information starts getting scattered across different tools.

A lightweight workflow can make this easier without building a custom backend.

The workflow

For a simple digital product business, you can connect four tools:

Payhip — handles digital product sales.
Make — connects the different steps.
Telegram — sends order notifications.
Notion — keeps customer and order information organized.

The basic flow looks like this:

Payhip → Make → Telegram + Notion

A purchase triggers the workflow. Make processes the available order information, sends a notification to Telegram, and records the relevant information in Notion.

The exact setup depends on the event data and connections available in your accounts.

Step 1: Start with the order event

First, identify the event that should start your workflow.

For a digital product business, that might be a successful purchase event received through a Payhip webhook.

Before adding more automation, verify that the event is actually received by Make. Check the execution history and inspect the available data.

This gives you a clear starting point for troubleshooting if something goes wrong.

Step 2: Send a Telegram notification

Next, use Make to send yourself a Telegram message when the relevant event is processed.

Keep the notification simple. Useful information might include:

Product name
Order status
Order reference, if available
A link to the relevant order record, if you have one

The goal is not to reproduce your entire sales dashboard in Telegram. It is to help you notice important events without repeatedly opening different platforms.

Avoid including unnecessary personal or payment-sensitive information in notifications.

Step 3: Record the order in Notion

A notification tells you something happened. A structured database helps you keep track of what happened over time.

You can create a Notion database with fields such as:

Property	Purpose
Order reference	Identify the order
Product	Record what was purchased
Order status	Track the current state
Date	Record when the event occurred
Customer reference	Connect the order to a customer record

Use only the fields available from your event or account. You may need to map the incoming data to your Notion properties.

If the same event can be processed more than once, consider how you will identify duplicate records. An order reference can help when it is available and reliable.

Step 4: Test the workflow before relying on it

Do not assume a successful test in one module means the whole workflow works.

Run a test and check each part:

Did Make receive the expected event?
Was the Telegram notification delivered?
Was the Notion record created correctly?
Does the stored information match the original event?
What happens if a step fails or the event is processed again?

A small end-to-end test is more useful than adding more modules before the basic flow is reliable.

Step 5: Keep the system simple

It is tempting to automate every possible task immediately. But every additional branch, integration, and notification creates something else to maintain.

Start with one reliable workflow. Add more only when a recurring problem justifies the extra complexity.

For example, you might later add delivery checks or customer follow-ups, provided those steps fit your actual selling process and can be tested properly.

The objective is not to automate everything. It is to remove repetitive work without creating a system that takes more time to maintain than the manual process.

Want a starting point?

I’m building NomadOS Core around this kind of practical workflow for digital product creators and indie hackers.

It connects Payhip, Make, Telegram, and Notion, with automation templates and a setup guide for getting started.

If you want to explore the system, you can find the details here:

NomadOS Core — Digital Product Automation Starter System

You can also browse the open-source workflow examples on GitHub.

The most useful automation is the one that solves a real operational problem and remains easy to understand when something goes wrong.

I Built the Automation Before I Solved the Traffic Paoblem

Eva — Tue, 20 Oct 2026 12:11:46 +0000

I Built the Automation Before I Solved the Traffic Problem

When I started building my digital product system, I spent a lot of time connecting tools.

Payhip handled payments and product delivery. Make connected the workflows. Telegram handled notifications. Notion kept things organized.

The technical side was interesting. Every time a workflow worked, it felt like progress.

But then I had to face a less exciting question:

How do people actually find the product?

A working payment flow doesn't bring visitors by itself. Automated delivery doesn't create demand. And a well-organized database doesn't tell you whether anyone wants what you're selling.

I realized I had spent a lot of time improving the system behind the business before proving that enough people cared about the product.

I'm still working on that part.

Instead of adding more features, I'm trying to focus on a few basic things:

Publishing useful content where the right people already spend time.
Making the free resources genuinely useful.
Tracking whether readers move from an article to the repository or product page.
Learning from actual user behavior instead of guessing what to build next.

It's a different kind of work from building automations, and honestly, it's harder to measure progress.

But it may be the more important work right now.

For those of you building small products: how do you balance improving the product with spending enough time getting it in front of people?

How to Debug a 429 Rate Limit Error in Make.com

Eva — Sun, 18 Oct 2026 14:30:06 +0000

How to Debug a 429 Rate Limit Error in Make.com

I ran into a frustrating issue with a Make.com workflow recently.

The scenario was working through most of its steps without any problems. The webhook received the data, Notion created a database item, Telegram sent a message, and the JSON module completed successfully.

Then the HTTP module failed.

The error was:

429 Too Many Requests

The API response also included:

You have exceeded your current request limit.

I was using Alibaba Cloud's Qwen-Turbo model through its API. The first instinct might be to change the API configuration or rebuild the scenario, but neither should be the first move.

Here's how I approached the problem.

1. Find the module that actually failed

When a Make scenario fails, don't assume the entire workflow is broken.

Open the scenario's execution history and inspect the latest failed run.

Look at each module's execution status. In my case, the webhook, Notion, Telegram, and JSON modules had all completed successfully. The HTTP module was the first one to fail.

That immediately narrowed the investigation.

There's no reason to rebuild working modules when the failure is isolated to one API request.

2. Read the actual API error

The HTTP module showed a rate-limit error, so I checked the API provider's request logs.

The response included:

HTTP status: 429
Error code: limit_requests
Error message: You have exceeded your current request limit.
Model: qwen-turbo

This was much more useful than simply seeing a red error icon in Make.

A 429 response generally indicates that a service is refusing a request because a usage or request limit has been reached. The exact limit can vary by provider, model, account, and service configuration.

The important thing is to read the provider's error details rather than guessing.

3. Stop replaying the failed run

It's tempting to click Replay every time a scenario fails.

But if the API is still rate-limiting requests, repeatedly replaying the same run may only produce more failures.

I stopped retrying while investigating the issue.

This also helps avoid unnecessary API calls and makes it easier to tell whether new requests are still arriving from another source.

4. Check for other sources of API traffic

A rate limit isn't always caused by the scenario you're looking at.

Other Make scenarios, local scripts, or applications may be using the same model or account.

I would check:

Whether other scenarios call the same API.
Whether a local application is making requests in the background.
Whether multiple workflows can run at the same time.
Whether the provider's logs show new requests after the scenario is paused.

Don't assume that every request in the provider's logs came from the scenario you're debugging.

5. Add retries carefully

Retries can help with temporary rate limits, but an immediate retry loop can make the problem worse.

A safer approach is to use delayed retries with increasing wait times, for example:

First retry: wait 10 seconds.
Second retry: wait 30 seconds.
Third retry: wait 60 seconds.

These are starting points, not universal settings. The appropriate delay depends on the provider's limits and any retry guidance in its response headers or documentation.

For persistent quota limits, waiting and retrying won't solve the underlying problem. You need to inspect the account or model quota instead.

Also make sure failed runs don't trigger an uncontrolled chain of duplicate requests.

6. Change only what the evidence supports

After identifying the failing module, I avoid changing the model, API endpoint, request body, and credentials all at once.

Changing several things simultaneously makes it harder to identify the actual cause.

Instead, I check the specific limit reported by the provider, make one targeted adjustment, and test again.

If the API request succeeds, I then verify that the downstream modules receive the expected response.

A simple debugging checklist

When an API request fails in Make.com, I now work through this order:

Open the failed execution.
Identify the first module that failed.
Read the complete error response.
Check the API provider's request logs.
Pause repeated requests while investigating.
Check for concurrent traffic and usage limits.
Make one targeted change.
Run a controlled test and verify the downstream steps.

The biggest lesson for me is that a failed automation doesn't always need more complexity.

Sometimes the fastest fix is to stop changing things, find the first failing step, and read what the service is actually telling you.

How do you usually handle API rate limits in your automation workflows? Do you use delayed retries, a queue, or another approach?

How to Test a Make.com Webhook Workflow Before Going Live

Eva — Sun, 11 Oct 2026 14:19:25 +0000

I've learned that getting a Make.com scenario to run once doesn't necessarily mean it's ready for real use.

A webhook can receive a test request, the next module can run successfully, and the data can appear in the right place. Everything looks fine.

Then a real event arrives with a missing field, an unexpected value, or a slightly different payload, and the workflow behaves differently than expected.

Before relying on a webhook automation, I like to test a few things beyond the happy path.

1. Start With a Known Test Payload

First, send a simple test request through the webhook.

Use realistic sample data rather than empty or random values. For example, if you're testing an order notification workflow, include fields such as:

Order ID
Product name
Customer email
Order status
Purchase timestamp

The exact fields depend on your workflow.

In Make, open the scenario, run it in a controlled test, and inspect the output bundle from the webhook module.

Check that the values arrived as expected and that the following modules can access the fields they need.

One small detail worth checking: a field that exists in one test payload may be missing from another. Don't assume every incoming request will have exactly the same structure.

2. Check What Happens When a Field Is Missing

Next, test an incomplete payload.

For example, send a request without an optional customer name or product description.

Ask yourself:

Does the scenario stop unexpectedly?
Does a message get sent with blank or confusing information?
Does the next module reject the request?
Can the workflow still complete safely?

Not every field needs to be mandatory. The important thing is to decide which fields are required and what should happen when they're absent.

For customer-facing messages, I'd rather show a sensible fallback than send a notification full of empty values.

3. Test Duplicate Events

Webhooks can sometimes deliver the same event more than once, depending on the sending system and how retries work.

For an order workflow, that could mean duplicate notifications or repeated records.

Try sending the same test event twice.

If the scenario creates duplicate results, consider whether you need a unique event ID, an order ID check, or another idempotency mechanism.

The right solution depends on the source system and how the workflow is designed. Simply adding a delay won't reliably prevent duplicates.

4. Test the Failure Path

A useful test isn't only one where everything works.

Check what happens when a downstream module fails, a connection needs attention, or a request doesn't contain the expected data.

In Make, inspect the scenario's execution history and review the relevant module output and error details.

Depending on the workflow, you may need error handling, a notification to yourself, or a way to retry failed operations safely.

Avoid assuming that every failure should trigger an automatic retry. If an operation has already succeeded but its response was lost, retrying it without checking the outcome may create duplicate actions.

5. Verify the Final Result

Don't stop when the scenario shows a successful execution.

Check the destination too.

If the workflow sends a Telegram notification, confirm that the message arrived and that the content is correct.

If it writes to Notion, open the database and verify that the record contains the expected values.

If it triggers another service, check that service rather than relying only on the previous module's status.

The goal is to confirm the complete result, not just that the scenario started.

6. Use a Small Go-Live Checklist

Before switching a workflow into regular use, I would check these items:

[ ] A normal test payload works.
[ ] Required and optional fields behave as expected.
[ ] Missing fields don't create misleading output.
[ ] Duplicate events have been considered.
[ ] Failures are visible and can be investigated.
[ ] The final destination contains the correct result.
[ ] The workflow has been tested with realistic data.

You don't need a complicated testing framework for every small automation. Even a short checklist can catch issues that are easy to miss when you're focused on getting the scenario running.

One Last Thing

I've been trying to keep my own automation workflows small enough to understand and maintain.

It's tempting to add more modules whenever a new requirement appears. But before expanding a scenario, I want to know that the existing workflow handles normal requests, unexpected input, and failures in a predictable way.

A workflow that runs once is a good start. A workflow you can troubleshoot when something goes wrong is much more useful.

What's the most common issue you've run into when testing webhook automations?

I Built the Automation Before I Understood the Problem

Eva — Sun, 27 Sep 2026 14:10:28 +0000

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.

I Built the Automation Before I Had Enough Customers

Eva — Sun, 20 Sep 2026 13:00:07 +0000

I made a mistake while building my digital product business.

I built the automation before I had enough customers to need it.

At first, this felt like the right thing to do.

I was using Payhip to sell digital products.

Make was handling the workflows.

Telegram was useful for notifications.

Notion was where I wanted to keep track of orders and customers.

Later, I added email automation as well.

The architecture started looking pretty nice.

Payhip
↓
Make
↓
Notion
↓
Telegram
↓
Email follow-up

Everything had a place.

And then I realized something.

There weren't that many orders.

So why was I spending so much time maintaining the system?

The problem wasn't the automation

The workflows themselves were not the problem.

Most of them worked.

The problem was that I was building for a future version of the business.

I kept thinking:

"What if I get more orders?"

"What if I need another notification?"

"What if I want to track another field?"

"What if I add another product?"

Those are reasonable questions.

But when you're still trying to get people to actually find and buy your product, they can become distractions.

I could spend an hour improving an automation that might save me ten minutes a week.

That doesn't make much sense.

I started looking at automation differently

Before building a new workflow now, I try to ask a few basic questions.

Does this happen often?

Is the process predictable?

Am I doing it manually often enough that it annoys me?

What happens if the automation fails?

And probably the most useful question:

Would I build this if my business stayed small for the next few months?

That last question has stopped me from building quite a few things.

A smaller workflow is often easier

For example, digital product delivery is a pretty good automation candidate.

A customer buys something.

The same type of event happens again.

The delivery process is predictable.

There isn't much value in manually checking every order.

So automating that makes sense.

But something that happens once every few weeks?

I might just do it manually.

It's not worth creating another workflow, another webhook, another database field and another thing to debug.

I also learned something about maintenance

This was the part I underestimated.

When you connect several services together, you don't just create an automation.

You create dependencies.

A webhook can change.

A field can be missing.

An API can return something unexpected.

A workflow can run twice.

A database can have a different structure than you expected.

None of this is particularly scary.

But every additional workflow adds another thing you eventually have to understand.

That's why I'm becoming much more conservative about adding automation.

I'm not trying to build the biggest workflow anymore.

I'm trying to build the smallest one that solves the problem.

What I'm doing now

My current approach is pretty simple.

Build one workflow.

Use it.

See if it actually saves time.

Leave it alone for a while.

Only then decide whether another automation is necessary.

This is also changing how I'm building NomadOS.

Instead of asking:

"What else can I automate?"

I'm trying to ask:

"What repetitive problem am I actually having right now?"

That question is much more useful.

I'm still figuring this out, so I'm curious about other people's experience.

Have you ever built an automation that turned out to be more work than the manual process it replaced?

How to Handle Webhook Errors in Make.com

Eva — Sun, 13 Sep 2026 13:00:12 +0000

Webhooks are one of the easiest ways to connect different tools with Make.com.

They are also one of the easiest places for an automation workflow to break.

A webhook may receive incomplete data.

A field may have a different format than expected.

Another service may return an error.

Or the workflow may simply stop because one step didn't receive what it expected.

I've run into this several times while building digital product automation workflows.

Over time, I've started using a simple approach to make webhook-based workflows easier to debug and maintain.

Start by checking the webhook data

When something goes wrong, don't immediately change the whole workflow.

First, look at what the webhook actually received.

A typical workflow might look like this:

Payhip
↓
Webhook
↓
Make
↓
Process data
↓
Notion / Telegram / HTTP

The first question should be:

Did Make receive the data correctly?

If the webhook didn't receive the expected information, changing later modules won't solve the problem.

This sounds obvious, but it's an easy step to skip.

Check the actual fields

A webhook may receive much more information than you expect.

For example, an order event might contain:

Customer information

Product information

Order information

Payment information

Timestamps

Transaction IDs

Instead of assuming that every field will always exist, check the actual webhook output.

Look for the fields your workflow really needs.

For example:

Customer email

Product name

Order ID

Payment status

If one of these fields is missing, the next module may fail.

Don't assume the data will always be the same

One important lesson I've learned is that external data is not always predictable.

For example, you might expect:

Product name

But sometimes an API or webhook may return:

Product title

Or the value may be empty.

Your workflow should be designed with this possibility in mind.

This is especially important when connecting several different services.

The more services you connect, the more likely it is that their data structures will be slightly different.

Validate important data before continuing

For important workflows, I prefer to validate the data before performing the next action.

The basic idea is:

Webhook
↓
Receive data
↓
Check required fields
↓
Continue if valid
↓
Perform action

For example:

Webhook
↓
Check order ID
↓
Check customer email
↓
Check product
↓
Create order record

This is safer than immediately sending everything to another service.

If the data is incomplete, you can stop the workflow before creating a bad record.

Don't make every error a complete failure

Another useful idea is separating important actions from optional actions.

Imagine this workflow:

Payhip
↓
Make
↓
Create order record
↓
Send Telegram notification
↓
Send customer email

What happens if Telegram is temporarily unavailable?

The order itself shouldn't necessarily be considered a failure.

The most important operation may be recording the order.

The Telegram notification may be secondary.

Thinking about priorities like this makes automation systems much easier to maintain.

Add logging

When a workflow works perfectly, you don't think much about logging.

When something breaks three days later, logging suddenly becomes very important.

A simple log can help answer questions like:

What happened?

When did it happen?

Which order triggered it?

Which module failed?

What data was received?

Without this information, debugging often becomes guesswork.

For a small automation, even a simple Notion database or spreadsheet can be enough for basic logging.

Be careful with retries

Retries can be useful.

But retries can also create duplicate actions.

Imagine a workflow receives an order and creates a record.

The next step fails.

The workflow runs again.

Now you might accidentally create the same order twice.

This is why unique identifiers are important.

For example, an order ID can be used to determine whether the order has already been processed.

The basic idea is:

New event
↓
Check order ID
↓
Already processed?
→ Yes: stop
→ No: continue

This simple check can prevent many duplicate records.

Keep error handling simple

It's tempting to build a complicated error-handling system immediately.

I don't recommend doing that.

Start with the most common failure cases.

For example:

Missing customer email

Missing order ID

Invalid data

API timeout

Service unavailable

Duplicate event

Handle these first.

You can always add more protection later.

Avoid adding unnecessary branches

Another mistake is creating too many branches in a workflow.

A workflow can quickly become difficult to understand:

Webhook
↓
Router
↓
Condition A
↓
Router
↓
Condition B
↓
HTTP
↓
Router
↓
Telegram
↓
Router
↓
Notion

At some point, the workflow becomes harder to maintain than the original manual process.

A simpler structure is often better.

For example:

Webhook
↓
Validate
↓
Process
↓
Record
↓
Notify

The goal isn't to create the most sophisticated workflow.

The goal is to create one that keeps working.

Test with real examples

Testing with one example isn't always enough.

Try different situations.

For example:

Successful order

Different product

Missing optional field

Duplicate event

Failed API request

Unexpected data

This helps reveal problems before real customers encounter them.

I also recommend keeping test data clearly separated from real customer data whenever possible.

Design for failure

One of the biggest changes in how I think about automation is this:

Don't design only for the happy path.

A workflow that works perfectly when everything goes right isn't necessarily a reliable workflow.

Real systems have:

Network problems

API errors

Missing data

Duplicate events

Temporary service outages

Unexpected inputs

A maintainable automation should have at least some idea of what happens when things go wrong.

When should you rebuild a workflow?

Not every error means the workflow needs to be rebuilt.

If one module fails occasionally, you may only need better validation or error handling.

If the workflow has become extremely difficult to understand, however, it may be time to simplify it.

A useful question is:

Can I understand what this workflow does by looking at it for a few minutes?

If the answer is no, the workflow may have become too complicated.

My simple debugging process

When one of my Make.com workflows stops working, I usually go through these steps:

Check the webhook output
Find the first module that failed
Check the input data
Check the output data
Look for missing or unexpected fields
Check whether the external service returned an error
Check for duplicate events
Fix the smallest possible problem
Run another test
Only rebuild the workflow if the structure itself is the problem

This approach is much faster than randomly changing multiple modules at once.

The bigger lesson

Webhook automation isn't difficult because connecting two tools is complicated.

The difficult part is dealing with everything that happens when the data isn't exactly what you expected.

That's why I now think about automation in three parts:

Input

What data did I receive?

Process

What should the workflow do with it?

Output

What should happen after the process finishes?

Then I add one more question:

What happens if something goes wrong?

That question can make a big difference.

Final thoughts

Automation should remove repetitive work.

But a workflow that constantly breaks, creates duplicates, or requires manual debugging can become another source of work.

That's why I prefer simple workflows with clear responsibilities, basic validation, useful logging, and straightforward error handling.

You don't need to build a perfect automation system.

You need to build one that you can understand, test, and maintain.

**Automate repetitive work.

Don't automate complexity just because you can.**

I'm also collecting reusable digital product automation workflows and examples on GitHub.

You can find them here:

https://github.com/Eva-311/hermes-automation-examples

How to Build Maintainable Make.com Automation Workflows

Eva — Thu, 10 Sep 2026 13:00:30 +0000

Automation is easy to start.

Maintenance is the part that usually gets harder.

When I first started building automation workflows, my main question was:

"Can I automate this?"

Later, I started asking a different question:

"Will I still want to maintain this workflow six months from now?"

That second question changed how I design automations.

Here's the approach I'm using now.

Start with one clear responsibility

A common mistake is trying to make one Make.com scenario do everything.

For example:

Webhook → Check payment → Send email → Send Telegram notification → Update Notion → Create customer record → Send follow-up → Update analytics

It looks efficient.

But as the workflow grows, it becomes harder to understand what each part is responsible for.

I prefer to start with one clear purpose.

For example:

Payment → Validate order → Record order

Then another workflow can handle notifications.

And another one can handle follow-up.

The goal is not to minimize the number of scenarios.

The goal is to minimize unnecessary complexity inside each scenario.

Give each tool a specific job

One of the simplest ways to keep an automation maintainable is to give each service a clear responsibility.

For example, in my digital product workflow:

Payhip → Transaction → Make

From Make, the workflow can branch into:

Telegram → Notification

Notion → Order record

Payhip handles the transaction.

Make handles the workflow logic.

Telegram handles notifications.

Notion stores operational data.

This makes debugging much easier.

If a notification doesn't arrive, I know where to look.

If an order isn't recorded, I can check the Notion branch.

If the trigger doesn't happen, I start with the payment event.

Clear responsibilities reduce the number of places you need to investigate.

Validate data before doing anything important

Another problem I encountered was assuming that incoming data would always look exactly as expected.

It usually does.

Until it doesn't.

A webhook might contain:

missing fields
unexpected values
empty customer information
different product data
duplicated events

So I prefer to validate important data early.

Conceptually:

Trigger → Validate → Process → Action

Instead of:

Trigger → Action → Action → Action → Something fails

A small validation step can prevent much bigger problems later.

Don't duplicate logic everywhere

Imagine you have several workflows that need to determine whether an order is valid.

If every workflow implements the logic differently, maintenance becomes difficult.

One workflow might check:

status = paid

Another might check:

payment_status = completed

And another might simply assume the webhook means the payment succeeded.

Now you have three different interpretations of the same event.

Reusable logic and consistent data structures make automation systems much easier to reason about.

Logging is part of the workflow

One thing I think is often overlooked is logging.

When an automation works, you don't think about it.

When it fails at 2 AM, you suddenly want to know:

What triggered it?
What data did it receive?
Which step failed?
Was the customer affected?
Did the order get recorded?
Did the notification get sent?

A simple log can make these questions much easier to answer.

For example, a basic order log could contain:

Order ID
Customer
Product
Timestamp
Status
Error

You don't necessarily need a complicated monitoring platform.

Sometimes a structured record in Notion or another database is enough for a small business.

Design for failure

An automation that works only when everything goes perfectly isn't really finished.

For example:

Payhip → Make → Notion

What happens if Notion is temporarily unavailable?

Or if the incoming data is incomplete?

Or if the same event is received twice?

These situations should be considered during the design stage.

For a small workflow, this doesn't need to become an enterprise engineering project.

But at minimum, I want to know:

What can fail?
How will I notice?
Can the workflow be safely retried?
Could a retry create duplicate data?

These questions become increasingly important as the number of customers grows.

Avoid unnecessary branches

Make.com makes it very easy to keep adding routers, filters, conditions, and modules.

That's useful.

But it's also dangerous.

Every additional branch creates another thing to understand later.

Before adding another condition, I now ask:

"Does this remove meaningful manual work?"

If the answer is no, I probably don't need it yet.

This has helped me avoid building automation just because the tool makes it possible.

Keep the workflow readable

A workflow should be understandable by someone who didn't build it yesterday.

I like using simple names for important modules.

Instead of names such as:

HTTP 4

Notion 7

Telegram Bot 16

Router 3

use names such as:

Validate Order

Create Order Record

Send Telegram Notification

Handle Failed Order

Six months later, these names matter.

Good naming is a small thing, but it reduces cognitive load when debugging.

When should you split a workflow?

I don't think there's one universal rule.

But a useful signal is when one workflow starts having several unrelated responsibilities.

For example:

Order Processing → Customer Management → Email Marketing → Analytics → Support

At that point, I would consider splitting the system into smaller workflows.

For example:

Workflow 1: Payment → Order Record

Workflow 2: Payment → Telegram Notification

Workflow 3: Customer → Email Follow-up

The exact architecture depends on the business.

The important thing is that each workflow should have a reason to exist.

My current rule for automation

I've started using a simple rule:

Automate repetitive work.

Don't automate complexity just because you can.

This sounds obvious, but it's surprisingly easy to forget.

Every automation has a maintenance cost.

You have to understand it.

You have to debug it.

You have to update it when another service changes.

You have to know what happens when something goes wrong.

So the best automation isn't necessarily the one with the most modules.

It's the one that removes meaningful repetitive work while remaining understandable.

A simple architecture to start with

For a digital product business, a small system could look like this:

Customer → Payhip → Purchase Event → Make

From Make:

Notion → Order Record

Telegram → Notification

Start there.

Then add another workflow only when you have a real reason.

Maybe you need customer follow-up.

Maybe you need lead capture.

Maybe you need analytics.

Add it when the manual work becomes a problem.

Not before.

Final thoughts

The biggest lesson I've learned from building automation systems is that the difficult part isn't connecting tools.

It's designing a system that you won't regret maintaining later.

Make.com gives you a lot of flexibility.

That's powerful.

But flexibility also means it's easy to build something much more complicated than you actually need.

So now I try to optimize for three things:

Clarity.

Reliability.

Maintainability.

If an automation can save time without becoming another system I have to constantly babysit, that's a good automation.

That's the standard I'm trying to build toward.

More Automation Examples

I'm also collecting reusable digital product automation workflows and examples on GitHub.

You can find them here:

Hermes Digital Product Automation Library

Why Automation Creates More Work - And How to Avoid It

Eva — Sun, 06 Sep 2026 13:12:00 +0000

Automation is supposed to save time.

But sometimes it does the opposite.

You start with one simple workflow.

Then you add another trigger.

Then another action.

Then an exception.

Then an error handler.

Then a notification.

Then another tool to monitor everything.

Eventually, you realize something:

You didn't remove work.

You created a system that needs to be maintained.

I've run into this problem while building automation workflows for a digital product business.

And it changed the way I think about automation.

The automation trap

A simple workflow might look like this:

Customer buys a product
→ Product is delivered
→ Order is recorded

That's useful.

Then you think:

"Why not notify me on Telegram too?"

So you add Telegram.

Then:

"Why not track the customer in Notion?"

So you add Notion.

Then:

"Why not send a follow-up email?"

So you add an email platform.

Then:

"Why not automatically tag the customer?"

Another step.

Then:

"Why not add an AI decision?"

Another module.

None of these ideas are necessarily bad.

The problem is that every additional step creates another dependency.

More automation means more things to maintain

This is the part that's easy to overlook.

Suppose your workflow uses:

Payhip
Make
Telegram
Notion
an email platform

Now you have several systems that need to keep working together.

If one API changes, your workflow may break.

If a webhook fails, an order may not be recorded.

If a Telegram connection expires, notifications may stop.

If your Notion database changes, the automation may fail.

The automation itself becomes a small software system.

And software systems need maintenance.

The mistake I used to make

My instinct was to automate anything that looked repetitive.

That sounds reasonable.

But repetitive doesn't automatically mean worth automating.

For example, imagine a task takes 30 seconds and happens twice a month.

Automating it might take two hours.

That's not really automation.

That's just moving the work somewhere else.

A better question is:

How often does this happen, and how expensive is it when I do it manually?

That changes the decision.

What I automate now

I try to prioritize three types of tasks.

1. Repetitive tasks

If I perform the same action over and over again, automation makes sense.

For example:

Customer buys a product
→ Record the order
→ Send a notification

That's a predictable workflow.

2. Event-driven tasks

I also prefer workflows that start because something actually happened.

For example:

Payment received
→ Start workflow

This is better than constantly checking whether something happened.

3. Tasks where mistakes are expensive

Some manual tasks are simple but easy to forget.

For example:

recording an order
sending a notification
updating customer status
delivering a digital product

If missing one of these creates a real problem, automation can be valuable.

What I don't automate

I try not to automate things just because they are possible.

For example:

complex workflows used only occasionally
processes that require frequent human judgment
tasks that are faster to do manually
workflows with too many dependencies
systems that I don't fully understand

This last one is particularly important.

If I can't explain what a workflow does in a few sentences, it's probably too complicated.

Start with one workflow

One of the best changes I made was simply starting smaller.

Instead of trying to build an entire automated business at once, I started with one workflow:

Payhip
↓
Make
↓
Telegram
↓
Notion

A purchase happens.

The automation processes it.

The order gets recorded.

I receive a notification.

That's enough.

Once that workflow is reliable, I can decide whether another automation is actually necessary.

Think in systems, not individual automations

There's another lesson here.

A business doesn't need dozens of disconnected automations.

It needs a small number of reliable systems.

For example:

Delivery system

Payment
→ Digital product delivery

Order system

Payment
→ Order record
→ Customer record

Notification system

Important event
→ Telegram notification

Follow-up system

Customer event
→ Email sequence

Each system should have a clear responsibility.

That makes troubleshooting much easier.

A simple rule

The rule I'm using now is:

Automate repetitive work, not complexity.

If automation removes a task I don't want to do repeatedly, it's probably useful.

If automation creates five new things I need to monitor, I probably made the workflow too complicated.

The goal isn't maximum automation

This is probably the biggest lesson I've learned.

I used to think the goal was:

"Automate as much as possible."

Now I think the goal is:

"Remove as much unnecessary work as possible."

Those sound similar.

They're not.

A business with 20 complicated automations isn't necessarily more efficient than one with 5 simple ones.

Reliability matters more than the number of automations.

What I'm building

This is also the reason I'm building NomadOS.

The goal isn't to create another giant automation platform.

Tools like Make already give you enormous flexibility.

The harder problem is deciding how those tools should actually be used in a digital product business.

I'm interested in building practical workflows around real business processes:

digital product delivery
order tracking
customer management
notifications
lead capture
follow-up

The idea is to start with simple workflows and gradually connect them into a system.

Without creating another system that needs constant babysitting.

Final thought

Automation should make your business quieter.

Not louder.

If you're spending more time checking whether your automations are working than you spent doing the original task manually, that's probably a sign to simplify.

Start with one repetitive problem.

Automate it.

Make it reliable.

Then decide whether you actually need the next automation.

That's the approach I'm taking now.

How to Automate Digital Product Delivery with Payhip, Make, and Telegram

Eva — Wed, 02 Sep 2026 14:08:30 +0000

If you sell digital products, one of the first things you'll probably want to automate is delivery.

A typical manual workflow looks like this:

Customer buys a product
→ You receive the order
→ You check the payment
→ You send the download
→ You record the customer
→ You send a confirmation

It works.

But once you start getting more orders, doing the same steps manually becomes unnecessary work.

I wanted a simple way to connect the tools I was already using.

The workflow I ended up with looks like this:

Payhip
↓
Make
↓
Telegram
↓
Notion

Here's how it works.

1. Payhip handles the purchase

The customer purchases a digital product through Payhip.

Payhip becomes the starting point of the workflow.

Instead of manually checking every order, the purchase event can trigger the next step.

The important part here is that the automation starts with an event.

You don't want to constantly check whether something happened.

You want the system to tell you when it happened.

2. Make handles the automation

Make sits between the different services.

The basic idea is:

Payhip event
→ Make receives the data
→ Make processes the order
→ Make sends the information to the next service

This's where you can decide what should happen after a purchase.

For example:

record the order
notify yourself
send customer information to another system
trigger another workflow

The nice thing about this approach is that you don't need to build a custom backend just to connect a few services.

3. Telegram handles notifications

I use Telegram for notifications because I don't want to constantly check dashboards.

For example, when a new order arrives, Make can send notification like:

New order received

Product: NomadOS Lite
Customer: customer@example.com

This turns the workflow into something I can monitor without opening Payhip every few minutes.

4. Notion stores the data

The final step is recording the order in Notion.

For example, my database can contain:

Customer	Product	Status	Date
customer@example.com	NomadOS Lite	Paid	2026-09-02

Now the order doesn't just trigger a notification.

It becomes part of a simple customer/order database.

This becomes much more useful when you have multiple products.

The complete workflow

The basic architecture looks like this:

Payhip
↓
Purchase event
↓
Make
↓
┌───────────────┐
│ Process order │
└───────┬───────┘
↓
┌────┴────┐
↓ ↓
Telegram Notion
↓ ↓
Notify Record

The important thing is that each tool has a relatively simple responsibility.

Payhip handles the transaction.

Make handles the automation logic.

Telegram handles notifications.

Notion stores the information.

What I learned

The interesting part wasn't actually connecting the tools.

The difficult part was deciding what not to automate.

It's easy to keep adding another step:

"Maybe I should automate this too."

Then another one.

And another one.

Eventually, the automation itself becomes something you have to maintain.

So I've started following a simple rule:

Automate repetitive work.

Don't automate complexity just because you can.

Start with one reliable workflow.

Then add another only when the manual work actually becomes a problem.

That's the approach I'm using while building my own digital product automation system.

#How I built an automated digital product workflow with Payhip,Make,Telegram and Notion

Eva — Fri, 31 Jul 2026 14:00:23 +0000

How I built an automated digital product workflow with Payhip,Make,Telegram and Notion

Selling digital products sounds simple:

Create a product → receive payment → deliver the product.

But the operational workflow quickly becomes messy.

You need:

Payment handling
Customer notifications
Delivery automation
Order tracking

So I built a lightweight automation stack using:

Payhip
+
Make
+
Telegram Bot
+
Notion

The architecture

Customer Payment
↓
Payhip
↓
Make Automation
↓
Telegram Notification
↓
Notion Database

Example workflows

1. Telegram Order Notification

When a customer purchases a product:

Payment event triggers automation
Telegram receives notification
Order information is recorded

2. Digital Product Delivery

After payment confirmation:

Delivery workflow starts
Customer receives instructions
Order status is tracked

Why I open sourced this

Many creators don't need a complex backend.

They need simple, reliable automation that connects existing tools.

You can find the complete workflow examples here:

👉 GitHub Repository:
https://github.com/Eva-311/hermes-automation-examples

Questions for other builders:

What tools are you currently connecting manually in your workflow?