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.
This hit me because I'm going through the
exact same realization right now.
I built an AI appointment booking system —
technically solid, runs 24/7, syncs calendars,
handles everything automatically. And for weeks
I pitched it as "an AI booking tool." Silence.
The shift that's slowly working for me: I stopped
saying what it does and started leading with the
specific moment of pain it kills. For a service
business, that's "you're mid-appointment, your
phone rings, that caller books someone else —
and you never even knew you lost them." Same
product, completely different reaction.
Your reframe from "Telegram automation stack" to
"a system that sells your digital products in the
background" is exactly that move. The stack was
never the product. The freedom from manually
handling every sale is.
My biggest struggle right now, honestly, is the
same underneath yours — going from "I built
something that works" to "someone who doesn't
know me trusts it enough to pay." Turns out that
gap has almost nothing to do with the tech and
everything to do with whether they feel the
problem before they see the solution.
Curious — when you reframed Hermes, did the
actual conversations with creators change, or
just the messaging so far?
That gap between "it works" and "someone trusts it enough to pay" is the absolute hardest part of the solo builder journey. When I made the pivot with Hermes, the type of objections I got changed entirely.
Before, people would argue about why they should use Telegram over email. After reframing, the questions became all about reliability: "What if a webhook fails?" or "How do I know my files actually got delivered?". It actually forced me to spend less time talking about the cool tech stack and more time designing robust, self-healing safeguards so they could actually trust the outcome.
What if a webhook fails?" is such a beautiful objection to get because it means they are already visualizing themselves using it! They're worried about it breaking because they've already accepted the value of it running.
That's a great lesson. It really highlights that trust isn't just about a polished UI, but showing the user you've anticipated everything that could go wrong on the backend. Definitely taking notes on this for my booking system!
Showing them that you’ve already anticipated the worst-case scenarios and built self-healing guardrails does more to build trust than a pretty dashboard ever could. Good luck with the booking system! Calendar sync edge cases are an absolute beast, but making those safeguards obvious to the user will change everything.
The shift from we built this system to this fixes a specific pain is the hardest transition for technical founders. I have seen the same pattern building automation tools. The stack works but adoption does not come from engineering. What has been the most telling signal so far that your new framing is actually reaching people who would not have engaged with the old one?
The absolute biggest signal is that I don't have to spend paragraphs explaining the product anymore.With the old "automation tool" framing,I had to try so hard to describe what the system actually achieved,and I usually just got polite nods from people trying to be nice.Now,the second I frame it as a background sales system that automatically captures leads and handles delivery,the lightbulb goes on instantly.People either immediately get it because they feel that exact bottleneck,or they don't.Cutting out that middle ground of confusion has been huge.
I completely agree. Features explain how your product works, but outcomes explain why someone should care. Reframing the product around the user's end result is often more valuable than adding another feature.
thank you
Really like this framing — same infrastructure, but a much clearer outcome. The line “people don’t buy tools, they buy outcomes” is exactly the hard lesson for many AI products.
I’m building in the meeting-recording/notes space, and I’m seeing something similar: “AI meeting notes” is less compelling than “turn every recording into decisions, risks, owners, and follow-ups people can act on.”
My biggest struggle right now is translating backend reliability and processing work into a simple user-facing promise.
Curious — how are you testing whether the new “sales automation system for solo creators” framing resonates? DMs, landing page signups, or paid pilots?
Right now,I'm testing the new framing mostly through direct DMs and short,15-second screen recording demos rather than just waiting for landing page signups.A sign-up button can be deceiving because people love free tools,but showing a creator a quick video of a specific manual chore disappearing from their workflow gets a much faster.raw reaction.If their ears perk up and they ask"how do I get this",I know the outcome hit the mark.Love your reframe on the meeting notes app,by the way-turning a raw recording into actual,actionable follow-ups is a killer outcome.
That makes sense. A short demo showing the chore disappearing is probably much stronger than explaining the automation behind it.
I’m seeing the same thing with meeting notes. “AI notes” sounds generic, but showing the before/after is clearer: raw recording or messy transcript → decisions, risks, owners, and follow-ups someone can actually use.
The backend reliability matters, but users only care once they can see the outcome in their own workflow.
Are you finding DMs work better after someone has already commented or engaged, or are cold DMs working too?
Honestly,warm DMs after someone interacts with a post win by a mile.Cold DMs are just brutal-they feel spammy,the conversion rate is terrible,and it's a quick way account flagged or restricted by platform algorithms if you send too many.But when someone leaves a comment about a specific bottleneck,they've already validated that they have the pain.Dropping into their DMs with a 15-second clip feels like a helpful,natural continuation of the conversation rather than a cold sales pitch.
That makes a lot of sense. Warm DMs feel much more natural because the person has already shown some interest.
I like the idea of using a short demo clip instead of a long explanation. It shows the outcome quickly and makes the message feel helpful, not salesy.
I’m learning the same thing with MeetIQ. Instead of explaining “AI meeting notes,” it’s probably better to show a messy recording becoming clear decisions, risks, owners, and follow-ups.
The product only starts to feel real when people can see their own problem disappear.
That before/after visual for MeetIQ is going to be killer.Honestly,nobody wants to read a feature list about AI summaries,but seeing a chaotic 10-minute transcript turn into a clean checklist of owners and deadlines?That's pure magic.It triggers that immediate"I need this"reaction.Let me know when you drop that demo,I'd love to see it!
This resonates with my experience as a senior ERP, full-stack, AI integration, and automation engineer. I've learned that customers rarely buy automation itself. They buy business outcomes. I've built technically sophisticated workflows that generated little interest, while simple solutions that clearly saved time or increased revenue gained traction immediately. The shift from "automation platform" to "a system that helps creators sell digital products automatically" is exactly the kind of reframing that creates value. The technology stack matters far less than the problem being solved.
Hearing this from a senior automation engineer makes me feel a lot better about making this mistake.It's honestly comforting to know that even seasoned pros fall into the trap of building over-engineered workflows before nailing the actual business case.When you're capable of building complex systems,it's so incredibly hard to look past the tech stack and remember that the customer literally only cares about saving time or making more money.Really appreciate the validation!
Reframing from tool to outcome is right, but "nobody cared" is usually a distribution problem wearing a positioning costume: the same stack with a new story still fails if the people with that pain never see it. Before rebuilding, go DM 10 specific creators who sell digital products, offer to set the whole flow up for them by hand, and charge for it. If you can't get 10 yeses doing it manually the framing isn't the issue, and if you can, they'll hand you the exact words for the page.
Love this advice.Offering to set up the entire flow by hand for 10 specific creators and actually charging money for it's the ultimate reality check.If I can't get people to pay me to do the heavy lifting for them manually,then a automated software tool definitely won't save them either.Plus,doing it manually means I get to see exactly where they get confused or stuck in the process.Time to close the code editor and start sliding into some DMs this week.
The trigger moment point in the comments is the real unlock here. Most teams stop at "people buy outcomes not tools" and treat that as the lesson, but knowing the outcome people want still isn't enough if you don't know the exact moment they realize they need it.
Weeks of building Hermes probably felt productive the entire time because the automation actually worked. That's the trap with infrastructure-style products. Functioning correctly and being wanted are two completely different things, and only one of them shows up while you're building.
Man,you hit the nail on the head.Building the infrastructure for Hermes felt incredibly addictive and productive because every green checkmark in the backend felt like a mini-win.You get so hooked on solving the engineering puzzle that you convince yourself a flawless system equals a guaranteed success.Realizing that a perfectly running backend has absolutely nothing to do with whether someone actually wants to buy it was a brutal but necessary wake-up call.
The green checkmark addiction is real and it's sneaky because it mimics the feeling of making progress without any of the market feedback that would tell you whether progress actually matters. A perfectly functioning backend is the most convincing way to stay busy without learning anything.
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.
This hits the nail on the head. When I look at my own workflow before building Hermes, my "messy step" was constantly switching between checking Payhip checkouts, delivering files, and manually updating my Notion CRM to keep track of customers. It was a constant mental drag. Asking other creators to map their exact transaction flow is the absolute best way to see if they're drowning in that same manual swamp, or if their biggest bottleneck is actually somewhere else entirely.
Exactly. Your own flow gives one strong candidate: payment → delivery → customer record.The important part now is not letting Hermes’ current workflow define the answer for everyone else.I’d run the five conversations without describing Hermes first, then record only: where they switched tools, what they still checked manually, and what almost got missed.If 3 of 5 point to the same handoff, that’s probably the first wedge. If the answers scatter, “sales automation for creators” is still too broad.Would you post back just: completed / top repeated messy step / count?
"Not letting Hermes's current workflow define the answer"is a massive really check.As builders,our default mode is to show off our toy rather than actually listen to the user.It's so hard to sit there,watch someone complain about a manual step,and not immediately interrupt with"my tool fixes that!"I'm going to challenge myself to treat these five chats purely as a diagnostic exercise.No pitching,just mapping out exactly where they switch tools and what they're checking manually.I'll definitely report back with the top repeated messy step once I've the data.
That’s the right setup. The no-pitch rule matters because otherwise Hermes starts shaping the evidence again.One guardrail: don’t force a “top” step if the answers scatter. Keep the 3/5 bar — if nothing reaches it, “5 completed / no repeated step” is the result.Same questions for all five, then completed / repeated step / count is enough. I’ll wait for the data.
thanks
"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.
Total solidarity on distribution being the absolute hardest part.Shifting the messaging makes the page convert better,but actually getting the right eyes on it's a whole different beast.Honestly,getting 10 downloads from pure cold outreach is a great start for a super niche app like TankSync.
Thank you for the kind words, Eva! Hearing that 10 downloads is a great start honestly makes me feel a lot better about the grind. Wishing you the best with your project too! 🙌
thank you
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.
Pairing the high-level"runs in the background" promise with a gritty,tangible scenario makes total sense.It stops the headline from sounding like abstract marketing fluff.I'm definitely going to build a quick,side-by-side breakdown on the page:the manual copying-and-pasting chaos vs. Hermes handling the lead capture,CRM logging,and delivery automatically.Making it that literal should make the value proposition click way faster.
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.
yeah, this tracks with what i found too. talking about "context management" or "handoff tooling" got polite nods, but the moment i asked specifically "what do you do when the ai session dies mid-task and you have to explain everything to a new one," people immediately had an answer, usually a strong opinion.
the use case that clicked hardest wasn't even the technical crowd it was people who don't code professionally. a tax lawyer and a school admin both described the exact pain in more detail than most of the "context hygiene" power users, who already have their own workaround and probably won't pay for a cleaner one. the narrow, painful moment beat the broad category every time.
It's wild how non-coders describe the pain so much better than power users.Tech people immediately get bogged down trying to categorize the with fancy jargon,but a tax lawyer or a school admin will just give you the raw,unpolished truth about why a specific task makes their day miserable.Using their exact,everyday vocabulary on a landing page is a hundred times more effective than any clever marketing copy we try to brainstorm in isolation.
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
Thanks. The useful next step is probably not another automation diagram, but a manual walkthrough of one creator's messy current process: where leads arrive, where payment happens, where delivery happens, and where follow-up gets lost. That walkthrough usually gives better sales copy than the stack itself.
"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
You're welcome.
I'm curious—do you think you found better messaging, or did you actually discover a different business than you thought you were building?
Those often end up being two very different things.
We're currently shifting from"automation tool thinking"→"business system thinking."
Curious if others here have gone through the same shift.