I built a Telegram AI tool for myself. Users immediately wanted different things
Today I received valuable feedback from the first users testing CoTel.
When I started building this service, I was mostly solving my own problems and thinking from my own experience of using Telegram. I wanted a tool that could help me analyze chats, answer questions about message history, and find important information faster.
Of course, I thought this could also be useful to other people. But until you actually put a product in front of real users, you still see it mostly through your own context.
And today I felt that very clearly.
One of the first things I heard was:
“It would be really useful to search not only channel posts, but also comments under posts.”
And I realized I had never even thought about that use case myself. So I never implemented that functionality.
But the moment someone said it out loud, it immediately made sense to me why that could be extremely valuable for many users.
I also received very interesting feedback from a journalist who works heavily with Telegram.
He said he really liked the idea of the product and would genuinely use a tool like this in his workflow. But almost immediately, he pointed out things I also hadn’t thought about.
For example:
— he needs direct links to the exact Telegram messages found through AI;
— manually searching for those messages afterward is inconvenient;
— it would be much more useful for him to work with entire groups of chats instead of a single chat.
That part was especially interesting to me.
Because for him, Telegram is no longer just a messenger — it’s a research environment and an information source. He has dozens of topic-based chats organized into folders, and his natural workflow is asking questions across an entire group of sources at once.
Meanwhile, I hadn’t even implemented Telegram folders in the interface because I personally barely use them.
Now I’m already thinking about how to build that functionality.
I think this is one of the most interesting moments in building a product:
at some point, you stop building a tool only “for yourself” and start seeing how differently other people approach their own workflows and problems.
That’s why early feedback feels so important.
The most encouraging part is realizing that the service may actually be genuinely useful to people. Some users already told me they would actively use it — and even pay for it — if the features most important to them appear in the product.
Right now I’m continuing to work on the landing page, improving UX, and collecting more feedback.
Some ideas will go into the second iteration of development, because at some point it’s important to stop adding features and actually release the MVP instead of disappearing into endless development forever.
my next post about costing problems here -
https://www.indiehackers.com/post/i-thought-limiting-users-to-n-requests-per-day-was-enough-for-cotel-turns-out-it-s-a-path-to-bankruptcy-63d3502470
The journalist use case is interesting — searching across entire chat folders instead of single chats is a completely different product scope than what you started with. That tension between "build what I need" vs "build what users need" is real. The folder-based search sounds like it could be the actual killer feature though. How are you deciding which feedback to prioritize for the MVP vs pushing to v2?
Funny enough, this is probably one of the most common questions people have asked me in the comments
Honestly, this is my first SaaS, so right now I’m learning on the fly how to make these kinds of decisions.
At the same time, based on the feedback I’m getting, I’m trying to shape a clearer vision of the product and identify the set of features that would already feel valuable enough for at least a few categories of users I’ve interacted with so far.
And of course, I also evaluate the development effort and complexity of implementing each feature before deciding whether it belongs in the MVP or later versions.
That's a solid approach — mapping features to user categories instead of just building a flat backlog. The development effort filter is smart too. I've seen too many MVPs bloat because the founder tried to serve every use case at once. One thing that helped me: instead of asking "what features do users want," ask "what's the one thing that would make them pay today?" It forces you to cut ruthlessly.
Thanks for the advice — that actually make sense.
One filter that may help here: separate feedback into "workflow blockers" and "expansion ideas."
Direct message links sound like a blocker for the journalist use case, because without source traceability they still have to redo the work manually. Folder-level or multi-chat querying might be the next workflow layer, but it is worth testing whether people will pay for a smaller version if the answer is always tied back to exact sources.
That keeps the MVP from becoming endless, while still letting user feedback decide the roadmap.
Yes, you’re right — I actually already have a backlog folder where I collect not only ideas from early testers, but also my own ideas that appear during development.
I’ve already implemented displaying Telegram folders in the chat selection list for analysis, but I’m still thinking about whether I should introduce true multi-chat/group analysis at this stage.
Because that decision is also deeply connected to architecture questions around request cost calculation, LLM usage, and pricing logic — and that quickly becomes a much bigger and more complicated problem to solve properly.
So I’m trying to approach that part carefully.
Thanks again for the feedback.
That sounds like the right place to slow down.
Showing folders in the UI is a useful discovery step because it lets users express the workflow. But true multi-chat analysis changes the economics, not just the interface.
I’d probably split it into two tests: first, collect real cross-chat questions people want answered; second, estimate the cost/latency of answering those questions reliably. If the same workflow repeats and the unit cost is predictable, then it is a product path rather than just feature expansion.
Yes, many people in the comments have also pointed out the product economics side of this problem.
And honestly, that’s one of the questions I’m actively thinking about right now.
Exactly. That’s the right problem to keep visible.
Once usage cost changes by workflow, pricing is not a later packaging task anymore. It becomes part of the product design: which requests are cheap, which need batching, and which ones need clearer limits before users rely on them.
nice!
This is such a great example of why real user feedback matters more than any amount of “building in isolation.”
What stood out to me most while reading this wasn’t just the product itself, but the shift in perspective you described — the moment when a founder stops designing purely around their own habits and starts discovering completely different mental models from actual users.
That transition is incredibly important, and honestly, a lot of products never reach it because the creators stay trapped inside their own workflows for too long.
The feedback about searching comments under posts is a perfect example.
From your perspective, the original problem was already well-defined:
analyze chats, search history, retrieve information faster.
But the moment someone mentioned comments, the product instantly expanded from being a “chat utility” into something closer to a contextual knowledge engine for Telegram.
And the journalist feedback is even more interesting.
What he described reveals something much bigger:
for many people, Telegram is no longer just communication software — it’s becoming an operating system for information gathering, research, monitoring, and intelligence workflows.
That changes the entire product positioning.
Features like:
— AI search across multiple chats,
— folder-level querying,
— direct source links,
— traceable message references,
aren’t just “nice UX improvements.”
For power users, they are the difference between:
“interesting demo”
and
“daily professional tool.”
The part about needing direct Telegram links especially resonated with me.
That’s exactly the kind of workflow detail that only appears when real users try solving real problems with a product.
AI-generated answers are useful, but professionals still need:
verification,
context,
source traceability,
and the ability to jump directly into the original conversation.
Without that, even good AI summaries create friction.
What’s also refreshing is that you didn’t react to feedback defensively.
A lot of builders subconsciously filter feedback through:
“Well, that’s not how I personally use it.”
Instead, you immediately recognized:
“I never thought about this because I don’t use Telegram that way.”
That mindset is honestly one of the strongest indicators that a product can evolve into something genuinely valuable.
Another thing I really liked:
you’re resisting the temptation to endlessly add features before launch.
That’s one of the hardest balances in product development.
Because once users start giving good ideas, the roadmap explodes overnight.
Suddenly every conversation creates:
“oh we should add this,”
“we also need this,”
“this workflow matters too.”
And before you realize it, the MVP disappears under infinite iterations.
Shipping early while still listening carefully is probably the healthiest approach.
Especially for products like this where the most valuable insights only emerge through real-world usage patterns.
Honestly, I think you’re discovering something bigger than a Telegram search tool.
You’re uncovering how people are starting to treat fragmented chat ecosystems as searchable knowledge bases — almost like personal or collaborative memory systems.
And that space still feels very underbuilt.
The most promising sign in your post wasn’t even the feature ideas.
It was this sentence:
“Some users already told me they would actively use it — and even pay for it.”
That’s the signal every early-stage builder hopes to hear.
Because it means the pain is real enough that people already imagine the product inside their workflow before it’s even fully finished.
Really excited to see where CoTel goes next.
This feels like the kind of product whose real use cases only become visible after more people start touching it.
Thanks a lot for the detailed feedback — I really appreciate it.
To me, it feels strange to build a product only around my own workflows if the goal is to create something useful for many different people. Everyone uses Telegram differently depending on their work, habits, and personal context.
If I focus only on my own use cases, I’ll probably miss a lot of potential users and valuable workflows.
What matters most to me right now is that even in its current MVP state, CoTel is already saving me time in real situations. That’s the main reason I continue building it.
I still don’t fully know what the final shape of the product will become after more feedback and real-world usage. But I’ll try not to lose the core idea behind it:
an assistant that helps people deal with large amounts of information inside Telegram and save time — whether for personal tasks or work.
This is probably one of the most valuable stages of building a product. The moment real users start breaking your assumptions is usually where the actual product starts to appear. The journalist example especially stands out because it shows how different workflows can completely change what matters in the UX. Features like direct message linking and chat grouping sound much more important once you hear the real use case behind them. Also good that you seem open to adapting instead of forcing the original vision. A lot of founders struggle with that early on. Nice progress so far 🙂👍
Thanks for the thoughtful feedback!
I think one of the hardest parts right now is learning how to adapt to real user workflows without losing the original focus of the product at the same time.
The journalist feedback is gold. That shift from "tool I built for myself" to "tool that fits someone else's workflow" is one of the hardest pivots to make mentally, because you have to let go of your own assumptions about how the product should work. The folders/grouped-chat idea especially, it sounds like a completely different product from what you started with, but it's probably the real one.
Thanks for the feedback! I’m not completely sure I agree that this is becoming a completely different product.
Like I mentioned in earlier comments, to me this still feels more like expanding usability and improving the workflows around features that already exist, rather than changing the core idea itself.
At the end of the day, it’s still an AI-powered tool for analyzing and navigating information inside Telegram — the workflows around it are just becoming broader and more flexible as different users interact with it.
Very Inspiring... If you are looking for contacts to help boost your sales and marketing... I have lists of high networth persons and could tailor customers that could either invest or boost customer sales. We have also helped founders get featured on Forbes, Bloomberg and many more. shoot me a message on telegram @caseyimafidon
Thanks for reaching out. Right now I’m mainly focused on improving the product itself and collecting feedback from early users during the MVP stage.
I’ve saved your contact and may reach out a bit later once I feel the product is more ready for expansion.
Interesting.
the journalist piece is the most interesting signal in this whole post — but worth pausing on it. before building folder support because of one ask, the question is: are there 4-5 more people using telegram as a research workspace? if yes, that's a real segment and the product probably forks (research-mode for journalists/analysts vs personal-chat-mode for you). if no — folder support is one loud user's feature creep.
the trap with "1 user asked, sounds reasonable, let me build it" is each one feels small but they stack up to a product that serves nobody well. easier filter: 3+ independent people describing the same workflow, not just requesting the same feature.
how many of the other testers were describing journalist-shape workflows vs your original personal-chat shape?
Actually, another tester also mentioned wanting to query multiple chats at once — they just didn’t explicitly frame it as “folders” or grouped chat querying.
So I do think there may be a broader use case there beyond journalism specifically.
My own personal workflow is much more point-to-point: I usually think in terms of asking questions about a few specific chats manually.
But I realize a much wider audience uses Telegram as a work environment, and for those users, querying across multiple sources simultaneously could be genuinely valuable.
And that’s probably not limited to journalists either — it could apply to SMM specialists, investors, recruiters, analysts, researchers, and other people constantly monitoring multiple information streams.
The harder part for me right now is not only the UX itself, but also how to handle the LLM cost model behind workflows like that, because querying across many chats changes token usage and may complicate my current request-limit system quite a bit.
So I’m thinking about that separately while also analyzing real request costs during testing.
But overall I agree with your point that it’s important not to overreact to single requests and instead look for repeated signals across multiple users and conversations.
The cost-model angle is the actually-hard half — once you go cross-chat, you're not shipping a feature, you're shipping different product economics.
Single-chat = bounded token cost per query. Cross-chat = unbounded unless retrieval is architected differently (chunk + rerank, embeddings cache, per-chat summarization), and that decision shapes pricing more than UX.
It also probably forks the audience: a journalist on a story might pay $30/mo for unlimited cross-chat, a casual personal user $5. Two products with the same surface, very different unit economics.
One question, if useful — when you first shipped CoTel, what specific user-behavior were you expecting to see that would tell you "this is personal-chat shape" vs "this is research-workspace shape"? Was the journalist signal a surprise, or did it confirm something you already half-suspected?
If unpacking this live is useful, I'm doing informal research interviews with solo founders on exactly this kind of fork-in-the-road decision logic — happy to do a 30-min call if it's a fit. No pitch, just learning from how you're thinking about it.
Otherwise — keep posting, the thread itself is gold.
Honestly, when I started building the MVP, I wasn’t thinking about different categories of end users at all.
I built CoTel mostly out of personal curiosity and a desire to solve my own problems. Only later, while using the raw MVP myself, I realized it was already saving me time — and that maybe this could be useful for other people too.
So I didn’t really follow the “classic” product process with user interviews and requirement gathering before development. That mindset is only starting to appear for me now.
At this stage I’m thinking much more about:
what workflows repeat,
which features are truly important,
and what should make it into the first public version.
And yes — the journalist workflow was unexpected for me, because my own workflows simply don’t look like that.
But now I can clearly see why this becomes valuable for professional use cases.
And I think you’re absolutely right that professional users may end up paying significantly more, because they use these workflows daily and spend real working time on them.
Which brings me directly to the hardest part: pricing and cost architecture.
That’s actually what I want to write my next post about, because figuring out:
how to price these workflows,
how to account for expensive cross-chat requests,
and how to reflect that inside usage limits and plans —
is turning into a very serious and surprisingly difficult problem.
And thanks for the offer to talk — I’d enjoy discussing this more and hearing about your experience. I’m currently in maternity leave with a small baby, so my free time is very limited right now, but I may reach out once I can properly make time for it.
Thanks for the honest read on your build process — that "solved my own problem, then realized others might want it" arc is super common for solo founders but rarely discussed this openly. Makes the post more valuable.
On pricing/cost architecture (since you said that's your next post topic) — one frame that might be useful: the cleanest way I've seen "two products, same surface" resolved is a credit pool with weighted operations. Each query consumes credits, but cross-chat queries cost 5-10x personal-chat ones (matching their actual token cost).
You get:
On the call — totally understood on the maternity leave timing, no rush at all. Whenever makes sense for you (3 weeks, 3 months — your call). If a sync call is hard at any point, even 3 specific questions over DM or voice notes would be useful — happy to shape it around what works for your time. Looking forward to your pricing post either way.
Yes, I’ve actually already started thinking in the direction of a credit-based model and how to calculate those credits properly.
And that’s exactly where things become interesting, because there are several variables affecting the real cost:
the depth of Telegram history being analyzed,
the LLM model being used,
and even the complexity level of the analysis itself.
So right now I’m trying to better understand how to balance all of those factors without making the pricing model too confusing for users.
The three-variable framing (depth × LLM tier × analysis complexity) is the right axis to think about — most credit systems collapse two of those and end up with surprise bills. The trap usually isn't the math, it's the moment a power user hits a 3x cost spike on a query that "felt the same" as cheap ones.
One pattern that's helped some early-stage tools: instead of exposing all three variables to users, bake two into the credit cost itself (depth + model tier as a hidden multiplier) and only let users explicitly choose the third (analysis complexity) via a clear "Quick / Deep / Full" toggle. That way users feel one knob, not three.
No rush on any timeline — totally understood. Even when CoTel launches publicly, I'd be curious to read the post about how you landed on the final structure. Take care of the little human first.
Yesterday I actually wrote a full post about this exact problem, so I’d be very interested to hear your thoughts and comments on it.
You can read it here:
https://www.indiehackers.com/post/i-thought-limiting-users-to-n-requests-per-day-was-enough-for-cotel-turns-out-it-s-a-path-to-bankruptcy-63d3502470?utm_source=chatgpt.com
Last Friday a tester said one line that broke the same kind of assumption for me. I'm building a tiny iOS memo app solo — a one-tap "send this note to my email" — and I'd never thought to support sending to multiple addresses. The second she asked for it, the single-recipient default became visibly mine, not the product's. Your "search comments under posts" example has the exact same shape — an invisible default that only an outsider can name. How long do you sit with a request like that before shipping it?
At this stage I still don’t have a huge amount of feedback, but I consider the feedback I do get extremely valuable, because almost every conversation creates some kind of new insight in my head.
Usually it’s a scenario I simply hadn’t thought about before — but once I hear it, it suddenly feels very reasonable and important.
At the same time, I’m already trying to learn how to filter out excessive feature expansion so I don’t disappear into endless development.
That said, two of the features the journalist suggested are actually things I started implementing almost immediately, because I personally became curious to test them in practice too.
But I think you definitely need to be careful with that kind of excitement 😅
The 'users immediately wanted different things' moment is the most useful data point in early product life — way more signal than feature requests in a survey. The trick is figuring out which divergent ask is a real new segment vs. just one loud user. Did you see any clustering in the asks, or was it all over the map?
Honestly, it’s still probably too early to confidently identify clear user clusters.
But at the same time, the requests already don’t feel completely random.
I’m starting to notice that many of them converge around a few repeating themes:
source traceability,
working across multiple chats/folders,
better information navigation,
and reducing manual context reconstruction.
What changes is mostly the workflow around those needs depending on the type of user.
For example, I originally approached this as an “information overload” problem.
The journalist approaches it more as a research and verification workflow.
Other users are already thinking more about monitoring, signal tracking, or topic-based subscriptions.
So the core problem still feels shared:
too much fragmented information inside Telegram.
But the shape of the solution starts changing depending on how a person works with information — professionally or personally.
And I think you’re absolutely right that one of the hardest things right now is understanding:
“is this an actual emerging segment”
or
“is this just one very specific user request.”
I probably won’t fully understand that until there’s a much larger volume of real usage and repeated behavioral patterns.
Right now I only have 3 testing users, so I’m currently waiting for more people and more feedback 😅
This is a strong signal that CoTel is not just a Telegram search tool. The journalist use case points to something bigger: Telegram as a research layer, where people need to search across channels, comments, folders, and source groups with exact message-level citations.
That feels much sharper than “AI chat history search.” The real pain is workflow continuity. If someone uses Telegram as their knowledge base, they need answers that link back to the original message, not just summaries that create more manual search work.
One thing I’d watch is the CoTel name. It is short, but it may not immediately carry the research/workflow intelligence angle. If this becomes a broader AI layer for Telegram-heavy researchers, journalists, analysts, and operators, Xevoa .com would feel more expandable and platform-grade.
Also, CoTel is actually short for “AI Copilot for Telegram,” so for now I don’t really see a strong reason to make the name more complex just for branding purposes.
At least at this stage, I think the name still reflects the core idea pretty well — it’s essentially a copilot for working with Telegram.
How many workflows and capabilities eventually grow on top of that is a separate question.
Maybe I’ll change my opinion later, but I think it’s still too early to think seriously about rebranding.
I think you’re right about one important thing here: once people start using Telegram as a real information environment instead of “just a messenger,” the workflow expectations change dramatically.
And yes, source traceability and continuity become extremely important in that context. Especially for people doing research, journalism, monitoring, or analytical work.
At the same time, I’m still trying to be careful not to over-expand the positioning too early.
Right now I still see CoTel primarily as an AI assistant for working with Telegram information flows. The research-oriented workflows are growing naturally on top of that, but I don’t want the product to lose focus by trying to become “everything for everyone” too early in the MVP stage.
So for now I’m mostly paying attention to which workflows repeatedly appear across different users, and which requests are actually becoming common patterns instead of isolated edge cases.
As for the name — interesting point. I honestly haven’t thought much about rebranding yet because right now I’m much more focused on validating workflows and usefulness first.
By the way, I’m curious — how did you come up with the name Xevoa? What’s the logic or association behind it?
That makes sense. I would not push CoTel away too early either if it is still helping you validate the core Telegram assistant wedge.
The reason Xevoa came to mind is that it feels less tied to Telegram itself and more tied to the workflow layer above it.
To me, CoTel explains the starting point: copilot for Telegram.
Xevoa feels more like what the product could become if the repeated patterns are research continuity, source tracing, channel intelligence, saved context, and operator workflows across Telegram-heavy information environments.
So the logic was not “make the name more abstract for branding.” It was more that if the product becomes the intelligence layer over Telegram information flows, the name should not trap it inside the initial copilot description.
I agree it is probably too early to force a rebrand. But it is not too early to watch whether users are describing the product as “Telegram copilot” or as “the place where I search, verify, and continue work across Telegram sources.” Those are different category signals.
If that second pattern keeps repeating, I would seriously pressure-test the name before CoTel becomes too baked into users’ memory. happy to connect privately if you want to think through that naming/category layer more cleanly.
Yes, I understand much better now what you mean, and I’ll definitely keep observing and thinking about these questions as more users and workflows appear.
That makes sense. I’d keep validating the repeated workflows first.
The only thing I’d watch is timing. If those workflows keep pointing toward research continuity, source tracing, and Telegram intelligence rather than just “copilot for Telegram,” then the name becomes worth revisiting before CoTel gets too baked into users’ memory.
If Xevoa ever becomes a serious candidate rather than just a naming reference, better to discuss it privately at that point.
Here’s my LinkedIn if you want to connect later:
https://www.linkedin.com/in/aryan-y-0163b0278/
This is one of the hardest transitions in product building:
realizing users are not trying to reproduce your exact workflow, they’re solving their own.
The journalist example is especially interesting because it changes the positioning from:
“AI assistant for Telegram chats”
to:
“AI research layer for Telegram knowledge networks.”
The requests also make total sense:
Feels like the product becomes much more powerful once the workflow expands beyond personal chat search into structured research workflows.
Also agree with your MVP point — there’s always tension between:
“one more feature”
vs
“ship before it becomes endless internal development.”
I think the positioning itself probably doesn’t change that much in this case — it’s still an AI assistant for working with Telegram chats.
What changes is the layer of workflows and usability around it. The assistant simply becomes smarter and gains more ways to explore and work with information inside Telegram.
And yes, it’s definitely exciting when the workflow grows beyond your original personal use cases.
The important part now is making sure the product doesn’t fall apart under the weight of too many additional features and lose its original positioning along the way.
That makes sense. I think the core product can stay focused, but the workflow surface expands as real users show where the value actually is.
For example, “AI assistant for Telegram chats” is still the simple positioning, but underneath that, journalists, researchers, founders, and operators may all need different ways to verify, organize, and trace information.
The tricky part is deciding which of those workflow requests strengthen the core product, and which ones turn it into a feature maze.
Deep links, comments, and folder/group-level querying feel like they strengthen the core because they improve trust, context, and retrieval — not just add random features.
This comment was deleted 3 days ago.
This is the part of building that humbled me too 😅
You think people will use the product like you do, then one user shows a completely different workflow you never imagined.
Yes, I think this is probably one of those “startup founder growing pains” that almost everyone has to go through 😅
At some point you realize that building an MVP only from your own perspective is very limiting, even if the original pain is real.
And honestly, I think experiences like this are what later teach founders to spend much more time talking to potential users and validating workflows before building too much.
This is the core tension of building for yourself vs. building for a market. We ran into the exact same wall built an AI research tool that solved our own pain (manual competitor analysis), then realized users were arriving with completely different expectations. How different were their requests from what you'd built?
Honestly, the core request turned out to be quite close to what I originally built. The differences appeared more in usability and workflow expansion rather than in the underlying problem itself.
I initially built CoTel around my own relatively narrow use cases: getting answers to specific questions from chat history and creating subscriptions around topics I care about.
But even the first users immediately started suggesting things that make the workflow much more practical:
working with Telegram folders, deep-links to found messages, comment indexing, and other UX improvements.
So the core tasks remain the same — what changes is the way users interact with them.
And that feedback is extremely valuable, because even if a product technically solves a problem well, people still won’t use it if the real-world workflow feels inconvenient.
What happened in your case?
Did you end up reworking core features or even changing the positioning of the product after talking to real users?
Thanks for getting back to me! I think my last message was a bit of a mouthful, so I’m not sure I quite got the gist of it. Could you break it down for me in plain English?
What I meant is that users mostly wanted the same type of product I originally imagined.
The main difference was not the problem itself, but how they wanted to use the product in practice.
For example, I originally built CoTel mainly for:
— asking questions about chats,
— searching information in chat history,
— getting summaries.
But users quickly started suggesting things that make those workflows more convenient:
— searching across multiple chats,
— opening direct links to messages,
— searching inside comments,
— using Telegram folders.
So the core idea of the product stayed the same.
What changed was my understanding of how different people want to interact with it.
Did something similar happen with your product too?
It sounds like our team is in a very similar boat. We built Bunzee.ai for solo founders and PMs who are drowning in 50 Excel tabs trying to write a product spec. We help validate their ideas before MVP development and even suggest business strategies. Because of this, we confidently placed a giant text area right on our dashboard, assuming users already had an idea ready to go.
It's been over a month since launch, and after gathering a lot of feedback, we realized our assumption was off. Users actually want us to focus on more niche markets and highly segmented targets. We're currently communicating with our dev team every day to build out these improvements.
By the way, this made me curious about CoTel. The chat market is already heavily saturated with countless products, so what would you say is CoTel's unique advantage? I ask because a chat app isn't something a user can just switch to on their own it requires a network effect where their contacts need to be on board too.
I think you’re partly right that there are already many products connected to messaging platforms.
But at the same time, when I personally tried solving this problem, I couldn’t really find a product that worked the way I wanted. And interestingly, the people testing CoTel also said they hadn’t come across something similar before.
I think part of the issue is geography and user categories:
some people actively search for tools like this for work,
while others don’t even realize this kind of workflow can be optimized until someone shows it to them.
If you can reach the right user and say:
“hey, you could save a huge amount of time by letting AI handle part of this information overload,”
some people immediately understand the value.
And to clarify — CoTel is not trying to become another chat app.
It’s more of an assistant layer for overloaded Telegram workflows:
helping people analyze, search, summarize, and navigate large amounts of Telegram information instead of manually sitting inside endless chats all day.
I’m also not claiming the idea itself is completely unique.
Right now I’m mainly focused on Telegram because I want to make the product feel complete and genuinely useful there first. Later, if there’s real demand, I could imagine expanding similar workflows to other messengers too.
Thanks for the reply! Your breakdown of CoTel's vision and purpose made everything click for me.
I totally agree with your point people pay for apps that do exactly what they need: save time, cut out the busywork, and maximize productivity. If CoTel can truly digest and navigate the massive chaos of Telegram data so we don't have to monitor endless chat feeds all day, count me in. I’d happily be a paid user to get that time back.
It looks like you're executing a really smart niche market strategy.
Our team started Bunzee.ai for very similar reasons. We made it for the people drowning in 50 open Excel tabs trying to validate their ideas. It's also for that solo founder who has a eureka moment on a Saturday, opens Claude to build an MVP, but stops to think, 'Will this actually work as a business?'
If you're interested, you should throw CoTel into Bunzee and see what it says. I'd be super eager to hear your firsthand feedback!
I visited your landing page, and honestly, the idea behind the service wasn’t immediately obvious to me.
I was asked to write some kind of idea into the text field, but I didn’t really understand what the service would actually do with it or why I should put my idea there in the first place.
I also struggled to quickly understand the positioning:
what exactly the product is,
what problems it solves,
and who it is for.
I tried scrolling further, but eventually stopped because I got tired of searching for a simple explanation of what the service actually does.
So maybe it would help to rethink the landing page flow and the way information is presented from top to bottom.
Anyway, that’s my current honest feedback. Maybe I’ll come back and take another look later.
As a founding member, I completely share your thoughts on user friction, though I'm curious why our hero section packed with descriptions and samples to avoid scrolling didn't quite click.
We target a niche market like CoTel but want to be clear to non-ICP users, so I hope you'll explore the actual Dashboard since judging only the landing page is like judging a book by its cover.
Could you take a deeper look inside Bunzee and let me know exactly which parts of the experience felt off to you?
This is such a real product-building moment.
One of the hardest transitions is realizing:
users are not buying your exact workflow — they’re trying to solve their own.
And often the most valuable use cases come from people using the product in environments you never originally imagined.
The journalist example is especially interesting because it changes the positioning completely:
from “AI assistant for Telegram chats”
to potentially:
“AI research layer for Telegram knowledge networks.”
That’s a much bigger and more powerful category.
The requests also make total sense:
• direct deep-links to messages → critical for trust & verification
• comments indexing → where a lot of real signal actually lives
• folder/group-wide querying → transforms it into a research workflow instead of chat search
The strongest insight in your post is probably this:
“unsupported assumptions from the founder become obvious only after real usage.”
That’s why releasing early matters so much.
Also completely agree with your MVP point. There’s always tension between:
“just one more feature”
and
“ship before the product becomes an endless internal project.”
From an AI product perspective, explainability + source traceability will probably become huge advantages here, especially for researchers, journalists, analysts, and investigators.
Emmanuel here 👋
I work heavily with AI workflows, developer tooling, automation, and product systems, and I’d genuinely be interested in testing CoTel and providing detailed UX / workflow feedback from a real usage perspective.
Very promising direction.
https://teams.live.com/l/invite/FAAk3iOSJkDyS11JQE?v=g1
Honestly, when I first started this project, my main goal was simply to use AI technologies to make working with huge amounts of information inside Telegram easier.
But the more feedback I receive, the more I realize how differently people use the exact same tool.
But that’s where another challenge appears: an MVP still has to remain an MVP.
At an early stage, it’s incredibly easy to fall into endless development, because every new idea suddenly feels important and reasonable. And now that the first real users have appeared, I’m feeling very clearly how important it is to separate:
what is truly critical for most users right now,
and what can wait until later iterations.
I think this is probably a separate skill you also have to develop while building a product.
Because honestly, after the first user conversations, my brain is already starting to overheat a little from the number of ideas, workflows, and edge cases that suddenly need to be considered.
But at the same time, this is an extremely important and valuable stage.
And yes — I’d be very happy to share access to CoTel and would genuinely appreciate any feedback that helps make the product more useful and easier to work with.
The landing page is still in development, but beta access to the working area is already available here: https://cotel.onrender.com/new-analysis.html
After registration, you can open the Help section from the profile menu — I added basic instructions there to help people quickly understand the main functionality.
And of course, feel free to ask me any questions directly.
This comment was deleted 3 days ago.