Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.
Eodly
Know what your team actually shipped today
119 followers
Know what your team actually shipped today
119 followers
Eodly reads Slack, Telegram, Discord, GitHub and Linear, and sends founders one sourced page each evening: who shipped, who's quiet, who's slipping, and any status that doesn't match reality. Your team never logs in. A chief of staff, not surveillance.
Eodly
different angle from the team-morale question above: what about false positives on the "status doesn't match reality" flag specifically. someone could be genuinely blocked on a design review that's happening in a call, or deep in research that doesn't produce commits or messages for two days, and that would look identical to actual slipping from the outside signals you're reading. does the founder get any confidence level on those flags, or is it presented as flat fact each evening? seems like the credibility of the whole digest hinges on that ratio being low
Eodly
@galdayan Exactly the failure mode we built against, so good question. The flag isn't "no signal = slipping." It only fires when someone's own check-in claims progress that the system of record contradicts. A day in a design review or heads-down in research doesn't trip it: if they check in and say so ("in review," "deep in the refactor, no PRs yet"), that's the context, there's no claim to contradict. No check-in and no activity just surfaces as silent, a neutral "hasn't checked in," never as "slipping." Anyone marked off on the calendar is suppressed entirely.
On confidence: it's never a verdict. Every flag shows the claim and the evidence side by side ("said almost done; Linear shows no movement since Tuesday") and is dismissible in a click. We show the receipts, and the founder judges. You're dead right that the whole thing lives or dies on that false-positive ratio, which is exactly why it surfaces its sources instead of asserting a conclusion.
@juwon55 the evidence-alongside-claim framing is what makes this different from what I was picturing, if the founder still has to look at the receipts and decide, that's a real check on the false-positive problem rather than the tool quietly deciding for them. the neutral "hasn't checked in" wording instead of "slipping" is a small thing but it matters for how this actually gets used day to day
Foyer
The "what actually shipped" framing is interesting because it implies you're pulling from somewhere more reliable than self-reported updates. So I'm curious where the data actually comes from. Are you connecting to Git commits, Jira tickets, pull request merges, or is this still fundamentally a standup tool where the accuracy depends on what people remember to log? That gap between "what got done" and "what someone typed at 5pm" is where every async status tool I've seen falls apart.
Eodly
@fberrez1 Great question, and it's the exact line we obsess over. The check-in is one short message, but it is not what the report trusts. We pull the real signals directly: GitHub commits, pull request merges, and issues, plus Linear ticket state, over signed webhooks. Then we weigh the check-in against that. "Almost done" only reads as progress if there is a merged PR or a moved ticket behind it, and when there isn't, we flag the gap instead of hiding it. That distance between "what got done" and "what someone typed at 5 pm" is not a bug we are papering over; it is the thing we surface. Honest caveat: for work that never touches a repo or tracker (a sales call, a Figma file), we verify what we can (live links, social posts, screenshots) and label the rest as self-reported rather than pretend it is proven. We would rather show you the seam than fake certainty.
The claim-versus-system-of-record check is the interesting engineering here, and the part I'd want to understand is attribution. When we cross-checked self-reported status against Git and ticket state, matching a vague claim like 'almost done with checkout' to the specific PR or ticket it refers to was where we lost accuracy. A merge that lands today can close work someone claimed three days back, so naive time-windowing reads that lag as a contradiction and fires a false flag. How does Eodly map a one-line check-in to the exact artifacts it's judging it against?
Eodly
@dipankar_sarkar You are pointing right at where naive versions break, so let me be concrete about what we do and do not do.
We do not keyword-match a claim to a single PR, and we do not use a same-day window, which are the two things that fail exactly as you describe. Attribution runs in two layers. Person-to-artefacts is deterministic: identity mapping links each teammate to their GitHub and Linear identity, so "this person's commits, PRs, and ticket moves" is a clean set, not a guess. Claim-to-specific-artefact we deliberately do not force into a 1:1 match. The model gets that person's check-ins over a multi-day window (we feed the prior few days, not just today) alongside their attributed activity, and judges whether the arc of the work supports what they have been saying, not whether the word "checkout" maps to PR #412.
That windowing is what handles your merge-lag case directly. A merge landing today that closes work claimed three days ago is read against those prior check-ins, so it resolves the claim instead of contradicting a same-day snapshot. What actually fires is sustained divergence: the same "almost done" three days running with nothing moving in that person's set. And when the link is genuinely ambiguous, it does not fire a confident "slipping" flag; it surfaces a soft, dismissible "worth a look," because a false slip is the most expensive error we can make. It is not perfect attribution, and I would not claim it is, but conservative-and-windowed beats naive-and-confident by a wide margin here. Sounds like you have been in this exact code; I would genuinely take your read on where it still gets thin.
I'd love something like this but from the reverse angle, to help teams upwardly demonstrate progress and what goes into making something a reality. Something that helps aggregate a whole teams efforts for the day, while showing some of the "how the sausage gets made". As HOP I find that collecting these signals daily to share forward momentum upwards can be more time consuming than it sound on paper.
As an example from your website, a positive signal as: "Closed the auth refactor. 3 PRs merged, staging green."
But then translating that into something csuite will understand how that's valuable for the business and what the outcomes are/what it unlocks - then do that for 7+ in flight epics, across 30+ engineers.
Eodly
@cadell_falconer This is a sharp angle and honestly where we want to go. Today, Eodly points at the founder or lead getting the unfiltered daily truth, sourced from the work. The upward version you are describing, rolling a team's day into a weekly narrative leadership actually understands ("3 PRs merged, staging green" becomes "checkout is unblocked, launch is on track"), is on our near-term roadmap, not shipped yet, so I will not pretend it is live. But the daily sourced signal is exactly the raw material for it, and as a HoP, you are precisely who we would want to shape it with. If you are open to it, I would love to compare notes on what that upward report has to say to land with your C-suite.
@juwon55 I'm open to chat. Sure!
The "your team never logs in" line is the smartest part. Every standup/status tool dies the same way — it asks people to do extra work to report the work they already did. Reading the signal from where the work already happens (Slack, GitHub, Linear) is the only version that survives contact with a busy team. Same pattern I see in voice: the products that win meet people where they already are instead of adding a new place to go. One honest worry — how do you avoid false "slipping" flags? Someone quiet in Slack might just be heads-down shipping. Get that wrong and it reads as surveillance, right as you promise it isn't. Congrats on the launch 🚀
Eodly
@david_marko You put your finger on the exact risk: get this wrong and the anti-surveillance promise dies, so we designed hard against it. Quiet in Slack is not "silent" to Eodly. Heads-down shipping shows up as real activity (commits, merged PRs, moved tickets), and purely off-system work is captured by the person's own one-line check-in, verified where we can and marked self-reported where we cannot. And "silent" and "slipping" are different on purpose: silent means no signal at all and surfaces as a soft "worth a look," never an accusation, while slipping is narrow, a claim the evidence directly contradicts, like "almost done" with nothing moved in days. Someone heads-down shipping is the opposite of that, and every flag is dismissible because sometimes the work is real and the tool just did not see it. The moment it polices quiet instead of surfacing real gaps, it becomes the thing we refuse to build. And the voice parallel is dead on: meet people where they already are, or the tool dies on adoption.
the "not surveillance" framing is doing a lot of work here. it's still a tool that quietly scores people's activity and hands the founder a page ranking who looks slow, the team just doesn't see their own report. once people find out that page exists, and they will, I'd expect them to start performing for the sourced signals (commits, messages) rather than just doing the work, which kind of defeats the point
Eodly
@omri_ben_shoham1 This is the fairest challenge in the thread, so let me not dodge it.
You are right that a manager-facing report is an asymmetry, and if it were a covert scorecard used to rank and punish, "not surveillance" would be a hollow phrase. Here is the line I would actually defend. Surveillance monitors the person: keystrokes, screens, hours at a desk, things you cannot see and did not choose to share. Eodly reads work products the team already puts in the open (commits, PRs, tickets, and their own check-in) and never touches screens, keystrokes, or private messages. That is the difference between "were you at your desk" and "what shipped," which is something any manager reasonably knows. And it is not secret by design: the report is manager-facing today because the founder is the one who has to do the synthesis, but nothing stops them from sharing it, and I would rather it trend openly than covertly. If a manager wields it as a gotcha, that is a management failure the tool cannot fix, but I take your point that the framing has to earn itself in how it is used, not just in what we refuse to log.
On gaming, the Goodhart point is the sharp one. The honest version: Eodly is deliberately not a leaderboard and does not score volume, so there is no commit count to top and little payoff in padding one. What it does is put a person's own claim next to the evidence, so the way to "perform for the signal" is to make your claims true, which is just doing the work. You can fake visible activity, but faking work convincingly is usually more effort than doing it, and the failure it actually targets is the opposite of gaming: people who report progress that never happened. It does not make honesty automatic. It makes the quiet slip harder to hide, and it does that without watching anyone
appreciate you actually engaging with it instead of the usual "we take this seriously" non-answer. the "nothing stops them from sharing it" line is where I'd push back a little more though, in practice defaults are the product. if visibility is opt-in for the manager, most won't bother even with good intentions, it just falls off the to-do list. if you ever want the trust story to be airtight rather than just defensible, making the report visible to the person it's about by default, not something they have to ask for, would close that gap. otherwise solid answer, wasn't expecting that much thought put into a comment reply