We built an automation system...but nobady cared
We spent weeks building a Telegram automation system.No one cared.
A week ago,we thought we had something valuable.
We built a system called Hermes---a Telegram-based automation stack using Make,Notion,and Payhip.
The idea was simple:
automate digital product sales end-to-end.
Webhook→Telegram→AI processing→Notion CRM→Payhip delivery.
Technically,it worked perfectly.
Everything ran 24/7.
No manual work needed.
But there was a problem.
Nobody cared.
Not because it didn't work-
but because nobody understood why they should use it.
We realized something painful:
👉We built a tool.
👉But people don't buy tools.
👉They buy outcomes.
So we started asking a different question:
Instead of:
"What can this system do?"
We asked:
"What problem does this actually solve?"
And the answer changed everything.
We are no longer building:
.a Telegream bot
.an automation tool
.or a Make workflow system
We are now thinking in a different direction:
→ A system that helps creators sell digital products automatically
Not automation for the sake of automation.
But:
.automatic lead capture
.automatic sales handling
.automatic delivery
.automatic CRM logging
Same stack:
.Telegram(interface)
.Make(logic engine)
.Notion(CRM)
.Payhip(payments)
Different framing.
Different product.
Different story.
What we learned:
Building infrastructure is easy.
But without a clear user-facing outcome,it's invisible.
Now we are rebuilding Hermes as:
-A sales automation system for solo creators selling digital products.
Not a tool.
A system that runs your business in the background.
If you are building solo tools or automation systems:
What's your biggest struggle right now?
Would love to hear how other are thinking about this.
The next test might be more concrete than asking whether solo creators need automation.I’d find 5 creators who already sold a digital product through Payhip, Gumroad, DMs, email, Notion, or spreadsheets, and ask them to walk through their last real sale from first message to delivery.Where did the lead come from? How did payment happen? How was the product delivered? Where was the customer recorded? What almost got missed?
If the same messy step shows up across a few sellers, that’s probably Hermes’ first wedge.
If not, “sales automation for solo creators” may be a cleaner story, but still not a clear workflow.
"People don't buy tools. They buy outcomes." This is such a clean way to put it.
I'm promoting TankSync, a niche aquarium app — and reading this made me realize why our positioning shift mattered. We don't just say "track water parameters." We say "understand WHY your water changes." That one word — why — turns a feature into an outcome.
Still working on getting that message in front of the right people though. 10 downloads so far, mostly from cold outreach. The reframe helped clarity. Distribution is still the harder part.
The shift from 'what it does' to 'what problem it solves' is the right move, but I'd say there's one more layer: figuring out the specific trigger moment — the exact situation where a solo creator thinks 'I need this right now.' Is it after manually processing their fifth sale on a Saturday? After losing a lead because they couldn't respond fast enough? That trigger moment is usually the most powerful place to start the pitch, because it reaches the buyer exactly when the pain is freshest. The 'runs your business in the background' line is strong — pairing it with one specific before/after scenario that makes that trigger tangible could really land.
Everyone here is right that outcome beats feature list, but I'd push on something before you rewrite the copy again. A Make + Notion + Payhip stack is catnip to people who could just build it themselves, so sharper outcome wording mostly pulls in more of that crowd, and they poke at it and leave. The ones who'd really pay are creators who would never touch Make in their life.
When I had a similar 'works but nobody bites' tool, the thing that changed it was showing it to a non-technical friend who runs a small coaching thing. She didn't care how it was wired, she cared that a lead got an invoice without her opening her laptop. That reaction told me I'd been demoing to the wrong room the whole time.
So before another messaging pass, I'd go find five people who can't assemble this themselves and watch them react. If they light up, you've got a packaging job and you're close. If they shrug too, the stack is solving something they don't really feel, and no amount of rewording saves that.
This's exactly the reality check I needed before wasting another week endlessly tweaking the copy.Moving sideways by rewriting headlines doesn't fix a targeting issue.I'm going to take your advice and get this in front of five completely non-technical users this week just to watch their raw reactions.That should tell me instantly whether I have a packaging problem or if the value isn't there.Appreciate the solid advice!
This title hit me hard.
I'm currently in early customer discovery for a tool
targeting freelancers who work with international clients.
The biggest thing I'm trying to avoid is building
something nobody asked for.
What was the earliest signal you missed that told you
the problem wasn't real enough?
The biggest signal I missed was letting perfect code hide a vague problem.Because the backend logic was running perfectly 24/7.I tricked myself into thinking I was making real progress.It's a classic developer trap-we hide in the code editor because building infrastructure is the comfortable part.If you find yourself spending weeks coding up deep features for freelancers before seeing if they'll even click a basic signup page or reply to a raw,15-second demo video,pull back.Total silence after you build is the loudest signal that the problem wasn't urgent enough.
I’d make the first demo brutally specific: “here is the messy manual sale flow today, here is the same sale after Hermes.” If the buyer can see one annoying job disappear, the stack matters less. Also worth picking one creator niche first, because “solo creators” can still be broad when you get to actual copy and pricing.
Spot on.I actually put together a short,15-second product demo showing data moving from Telegram to Notion,but framing it strictly as a "before vs.after" contrast to show a specific manual headache vanishing makes so much sense.When people can actually see an annoying,messy manual task get completely deleted in real time,they stop caring whether the backend is running on Make or magic.Definitely restructuring my next video clip to highlight that exact friction loop disappearing.
I had a version of this with my own launch — PivtTravel's pitch was originally "multimodal routing + delay-based connection scoring," which is accurate but reads like a feature list. The moment it landed better was switching to "tells you if your train connection is actually safe before you find out the hard way." Same product, but one version describes the engine, the other describes the moment someone's stressed at a junction wondering if they'll make it.
One thing I'd add to what's already been said here: even after you nail the outcome-framing, it's worth testing whether the outcome you've landed on is the highest-frequency pain, not just the most technically interesting one to solve. I built around connection-safety first because it was the most novel thing technically, but I'm now realizing something more common (like waitlist-confirmation anxiety, in my case) might've been the stickier hook all along. Worth checking if "sales automation for solo creators" is the most-felt pain your audience has, or just the cleanest one to frame.
The trap of building around what's technically novel or"clean"to solve is incredibly real for developers.When you're deep in the workflow engine,setting up seamless database integration and webhooks feels amazing because it's a satisfying engineering puzzle.But like you found out with your connection safety feature,the user couldn't care less about how cool the tech is.Your pivot is a great reminder that the stickiest hook is usually something incredibly mundane and high-frequency.rather than the feature that was the most fun to build.
This is painfully relatable. Sometimes the thing you build is technically useful, but the market only cares once you describe the exact painful moment it fixes.
I’m finding that broad labels like “automation” or “AI workflow” can sound abstract, while “here is the moment where your workflow breaks” gets much better reactions.
Did you eventually find one specific use case where people immediately understood it?
You hit the nail on the head-abstract labels are a silent killer for conversions.We fell right into that trap early on by calling our system a "Make workflow engine."The specific use case that finally turned things around was narrowing it down to solo creators selling digital products on platforms like Payhip.The moment we stopped pitching the tech stack and started talking about lead capture and instant CRM logging into Notion the second a sale happens,people instantly got it.Removing that specific post-sale bookkeeping chore was the hook.
I'd separate the system into two stories: the workflow it replaces and the decision it improves. "Telegram + Make + Notion + Payhip" is infrastructure; "a creator can capture a lead, take payment, deliver the asset, and know what happened without checking five tabs" is the outcome. The first sales demo should probably start with the current manual mess, not the automation diagram.
thank you
"Building infrastructure is easy, but without a clear user-facing outcome it's invisible" — this hit home. I'm in the same spot with my own product: it works, but the hard part was never the building, it's getting people to see why it's for them.
To answer your question: my biggest struggle right now is distribution, not the product. What's shifted things a little for me is writing about the problem I solve rather than the thing I built — when I describe the pain, the right people show up; when I describe features, nobody does. Sounds like you've landed on the same lesson the hard way. Good luck with the rebuild.
thank you
Yep. People almost never buy the mechanism first. They buy the moment when something annoying finally stops being annoying. I ran into the same thing with DictaFlow. Saying "AI dictation app" got polite nods, but saying it fixes typing friction in the apps where normal dictation falls apart got a much clearer reaction. Outcomes first, mechanics second. Otherwise, you're asking people to admire the plumbing.
Those ”polite nods" are the most dangerous trap in indie hacking.I got so many of those when I was pitching Hermes as a "Telegram webhook system".People say"wow,cool tech!" and you trick yourself into thinking you have product-market fit.But a polite nod never pulls out a credit card.Like you saw with Dictaflow,shifting the pitch to the friction dies is the only way to get a real "take my money" reaction.Glad you cracked that code too!
That realization is bigger than the automation stack itself. Features explain how something works. Outcomes explain why anyone should care. The interesting part is that your product didn't really change—you just found the problem it was actually solving. That's often the difference between something people admire and something they buy.
thank you
We're currently shifting from"automation tool thinking"→"business system thinking."
Curious if others here have gone through the same shift.