Wow,, your comment really resonated with me.
There’s a lot of insight in how you framed it.
I’ve actually been thinking about this as primarily a technology problem and, somewhat embarrassingly, I’m building something to try to address it.
When teams talk constantly across chat, calls, and meetings, a lot of the real work gets buried in the noise. Decisions are made. Tasks are implied. Commitments are spoken out loud and then they dissipate.
What we’re building is a system that extracts only the actionable parts from those conversations, turns them into tickets, assigns them automatically, and in some cases even lets AI execute the task directly. Humans do what only humans should do. AI handles what can be automated.
Recording conversations is important but motion is what creates value.
If nothing moves, nothing compounds.
I don’t think adding another storage location solves the problem.
Understanding relationships and triggering execution might.
Would genuinely love your thoughts on whether that’s directionally correct or if I’m still treating a wetware problem as software.
You're right. Rather than trying to stand out in a unique way, it's better to look like something already trusted and established. Thanks for the insight!
Thank you, this is incredibly valuable feedback. You've hit on a critical point about trust and privacy, and I want to be very clear that we agree with you completely.
If my description made it sound like a "Big Brother" tool that monitors conversations, that's a total failure of my explanation, and I'd like to clarify.
The "automatic extraction" is not a secret surveillance process. The AI assistant is designed to act like a helpful teammate, not a spy. It operates openly in-channel and essentially asks, "Hey, that sounds like a to-do item. Should I create a ticket for you?"
The key is that
the user is always in control. Nothing gets turned into a formal to-do item without a user's explicit confirmation or manual click.
So the goal isn't to monitor the "real" chats, but to help the team capture the action items they've already publicly agreed to, acting more like a personal assistant for the team members themselves, not for management.
You are absolutely right about the human nature to CYA in team environments, and our design philosophy must respect that.
This feedback is a gift because it shows our messaging is causing the exact wrong impression. Thank you again. With this clarification, does the concept feel less like surveillance and more like a potentially useful tool?
We're building a simple app that lets you automatically extract and manage to-do tickets right from your team's conversations.
I'm building this because my team and I constantly face a problem: actionable items get lost in the stream of our chat app (Slack, Teams, etc.), or we waste time manually moving them to a separate task manager like Jira or Notion. This manual copy-pasting is our biggest friction. When you move a task, you lose the original context of
why that task was created in the first place.
This context-switching kills our productivity.
Our solution makes this process seamless. Here’s how it works:
You chat with your team, yourself, or an integrated AI assistant.
The AI understands the dialogue (e.g., "Could you fix the deployment bug by Friday?") and automatically suggests creating a to-do ticket from that message.
Of course, you can also manually turn any message into a ticket with a single click.
Each ticket is intrinsically linked to the conversation thread, so the full context is always preserved. These tickets can then be managed on a Kanban board or a calendar without ever leaving the app.
Essentially, our goal is to eliminate the 'collaboration tax' by merging the place of discussion with the place of action.
My questions for HN are:
Would you or your team use a tool like this?
What are your biggest frustrations with your current chat + task management workflow?
Does the "automatic task extraction" sound genuinely useful, or does it feel like a gimmick that might get annoying?
For this to be a "must-have" product for you, what feature would it absolutely need to get right?
We're building a chat app that automatically creates and manages your to-do list right from your conversations.
I started this for a simple reason: I was tired of the soul-crushing 'copy-paste' work of moving decisions from Slack over to Notion or Jira. So much context gets lost in that process, and it just creates more "work about work."
Our core idea is simple: a chat message and a to-do item shouldn't be two separate things you have to keep in sync. In Markhub, the conversation is the task. It's not a copy; the conversation itself becomes the to-do, and all the context is automatically preserved.
Our bigger vision is to do for collaboration what GitHub did for Git. We’re not reinventing chat or kanban boards; we’re building the seamless 'workflow layer' on top that finally makes them work together.
We're currently in a private beta and would love to hear from HN users who feel this same pain. We’ve been fortunate to get early traction with large enterprise clients (including a ~$200k on-premise deal), but now we're looking for feedback from smaller, agile teams.
That's an even more precise and insightful framing. You're absolutely right—the catalyst was licensing, and the technical problem of SCM was, in a sense, already "solved." Thank you for sharpening the point further.
You've actually given me the perfect "Part 2" of the analogy "the relationship between Git and GitHub."
Yeah, Git is the powerful, low-level engine. Technically brilliant, but with a notoriously steep learning curve. The real explosion in adoption came when GitHub wrapped it in a user-friendly product with a clear workflow (pull requests, issues, etc.). GitHub didn't reinvent SCM; it reinvented the collaboration workflow on top of it.
That's exactly how we see the problem we're tackling. The "protocols" of modern work already exist: real time chat, task lists, documents. But they exist as separate, low-level primitives, like Git commands. The "collaboration tax" comes from users having to manually act as the interface between them.
Our goal is to be the "GitHub for general collaboration." To take those existing primitives and build a seamless, opinionated workflow on top where the connections are automated. The user shouldn't have to think about the "protocol"; they should just be able to work.
So, your point is well taken and helps clarify our position. We're not trying to build the "Git" (the core primitive). We're trying to build the "GitHub" (the intuitive workflow layer that makes the primitives powerful for everyone).
And that philosophy is baked right into our name. The reason we're called Markhub is because we're building a central "Hub" where every "Mark" a team makes a message, a decision, a task, a document can live together in a single, seamless flow.