✍️In this post,I want to break down a simple automation system we built for handling digital product sales automatically.
The goal was to remove manual work from:
.lead handling
.order processing
.product delivery
.CRM logging
We used a combination of:
.Telegram Bot(user interface)
.Make(automation engine)
.Webhooks(trigger layer)
.Notion(CRM database)
.Payhip(payment+delivery)
🧠System overview
The flow looks like this:
User → Telegram Bot → Webhook → Make Scenario → Notion + Payhip
1.Telegram Bot as the entry point
We used Telegram as the main interface because:
.easy user interaction
.supports real-time messaging
.no frontend needed
Users can:
.send messages
.trigger commands
.start interactions
2.Webhook trigger layer
Every incoming Telegram event is sent to a webhook.
This allows us to:
.capture user actions
.pass structured data to automation system
.decouple UI from backend logic
3.Make as the automation engine
Make handles the main logic flow:
.parsing incoming data
.routing conditions
.calling APIs
.transforming payloads
Example scenarios:
.new lead→create Notion record
.purchase→trigger delivery flow
.message→AI response(optional)
4.Notion as CRM system
We use Notion to store:
.users
.leads
.orders
.status tracking
Each event updates the database automatically.
This gives a simple CRM layer without building a backend.
5.Payhip for payment+delivery
Payhip handles:
.checkout flow
.payment processing
.product delivery
Once payment is confirmed:
→Make receives webhook
→system updates Notion
→user gets delivery message via Telegram
⚙️Why we built it this way
We didn't want to built a traditional SaaS backend.
Instead,we focused on:
.no server infrastructure
.no frontend development
.minimal maintenance
.fast iteration
This stack allows a solo builder to run a fully automated digital product business.
🧩What the system actually solves
This setup removes manual work in:
.responding to leads
.tracking customers
.delivering products
.updating CRM
It replaces all of that with automation.
⚠️What we learned
Even though the system works technically,we realized something important:
Automation alone is not the value.
What matters more is:
.clarity of outcome
.simplicity of flow
.how users perceive the system
🚀Next step
We are now refining this system into a more focused use case:
A sales automation system for solo creators selling digital products
Instead of a "tool stack",we are shaping it into a clear productized system.
đź’¬Question
If you were building a solo business today,would you prefer:
.simple automation systems like this
.or fully custom-built backend solutions?
Top comments (3)
It's interesting to see how you've leveraged Make and webhooks for this Telegram automation system. We've gone down similar paths for internal automations and MVPs, particularly when the goal is to validate a workflow or get a proof-of-concept out the door extremely quickly. The ability to stitch together services like Payhip and Telegram with minimal custom code is a significant advantage for rapid iteration in the early stages.
My experience has been that while these low-code orchestration tools offer substantial speed, the real test often comes when you need to handle more complex error states, very specific data transformations that aren't natively supported, or when transaction volume starts to push the limits of what a visual builder can manage without becoming unwieldy. We typically find ourselves at a crossroads where some critical path logic eventually gets extracted into a small, purpose-built service, perhaps a serverless function, to gain finer control and more robust error handling.
It's always a balancing act between initial development velocity and long-term maintainability and flexibility. For product delivery, reliability is paramount, so considering where those no-code components sit in your critical path and how you'd either scale them or replace them with custom code if performance or custom logic becomes a bottleneck is a key part of the planning. It's a pragmatic approach for building fast, and understanding those inflection points is what makes it sustainable.
You hit on the exact crossroads I keep thinking about.For a solo builder,running out of steam or building for an empty room is usually a much bigger threat than infrastructure limitations.My philosophy right now is to lean entirely into development velocity-I would absolutely love to hit the transaction volume limits where Make starts to sweat,because that means I actually have a business!
The visual builder trap is incredibly real.The second you try to build robust error-handling,retries,or complex nested conditions,a visual canvas becomes a total nightmare to manage.The hybrid approach you mentioned-extracting the critical path logic into a small serverless function while letting things like Make and webhooks just handle the basic glue-is almost certainly the long-term play here.Keep the no-code stuff for the easy plumbing,but let actual code handle the fragile parts.