Eodly
One evening report on what your team got done
116 followers
One evening report on what your team got done
116 followers
Eodly sends founders and team leads one report every evening on what their remote team got done. Everyone checks in once a day from Slack, Telegram or Discord, and each update is checked against the actual work in GitHub and Linear. People who worked but forgot to check in still count, and an update that keeps saying almost done while nothing moves is flagged. No time tracking or screen capture. Free for up to 5 people.
Congrats on launching!
Curious, how does the "chief of staff, not surveillance" framing land with team members? How have folks reacted to being flagged as "quiet" or "slipping"?
@grace_knowhow Thanks! The key thing: team members never see the flags. Their whole experience is one friendly DM in Slack or Telegram for a one-line update, no dashboard, no login, no scoreboard. The "quiet" and "slipping" synthesis is the founder's private read, never broadcast back to the team, and there's no per-person leaderboard anywhere (and never will be; that's a hard line for us). Anyone marked off isn't flagged at all.
Honestly, it's early post-launch, so I won't pretend I have a large sample of reactions yet. But the bet is simple: if the team's only touchpoint is a 20-second DM and nobody gets graded in a UI, it stays a tool that helps the founder rather than one that watches the team. Happy to report back as more teams run it.
This looks like something I'd like to use. How do we trigger the Eodly check from, lets say, WhatsApp? Do I have to tag it in a message and it checks whats happening, or is it only a daily overview kinda report?
@alohiya95 Thanks, Arnav. On the trigger: it is not you tagging it to check. Your team sends one short daily check-in to the bot, Eodly reads GitHub and Linear continuously in the background, and you get one sourced report at the time you set, plus a live dashboard you can open any time to watch the day form. So it is a daily digest by default, with a live view when you want to peek mid-day. Your team can check in from wherever they already talk: Slack, Telegram, Microsoft Teams, or Discord. WhatsApp is coming in v2.
That's neat. How does it distinguish actually shipped work from updates that just sound like progress?
@dhiraj_patel5 It comes down to the evidence behind the claim. "Shipped" means there is something real under it: a merged pull request, a moved Linear ticket, a live link, a verified post. "Sounds like progress" is a claim with nothing behind it yet. Eodly puts the two side by side, so "almost done on checkout" reads as shipped only if a PR actually merged, and when the words say progress but the systems have not moved, we flag the gap instead of passing it along. The check-in is the input; the systems of record are the judge.
Congrats on the launch, Juwon. The 'who's quiet' flag would make me nervous to build — a designer deep in Figma or someone on client calls all day looks silent in Slack and GitHub while doing their best work of the week. How does Eodly tell that apart from actual slipping?
@vollos This is the exact failure mode we built against, so it is a fair thing to be nervous about. Quiet in Slack and GitHub is not silent to Eodly: your designer checks in with one line ("reworked the onboarding flow in Figma"), your client-calls person checks in ("3 calls, closed 2"), and that work counts, verified where we can (a link, a doc, a screenshot) and clearly marked self-reported where we cannot. We never read "no commits" as "not working." And silent and slipping are deliberately different states. Silent means no signal at all, no check-in and no activity, and it shows up as a gentle "worth a look," not an accusation. Slipping is narrow: a claim the evidence contradicts, like "almost done" with nothing moved in days. A designer who honestly says what they did is never in that bucket; anyone marked away is suppressed, and every flag is dismissible. We surface the few things worth your attention; we do not police keystrokes, which is exactly why we refuse to do keystroke or screen monitoring at all.
@juwon55 That answers it — check-ins counting as signal, with honest labels on what's verified versus self-reported, is the right amount of trust for a team tool. And refusing keystroke monitoring outright is worth stating as loudly as you did. Good luck with the rest of the launch.
how does it actually figure out when someone's "slipping" vs just heads down on something that hasn't shipped yet? feels like that boundary could get noisy fast
@naime170609 Good question, and the key is that "slipping" is not "hasn't shipped yet." Eodly only cares about a gap between what someone claimed and what the evidence shows, not the absence of a finished artefact. Someone heads-down on a big feature who checks in honestly ("still deep in the payments refactor, not done, no PR yet") matches reality perfectly, so nothing gets flagged. That is just "in progress," and the report says exactly that. What does get surfaced is the mismatch: someone saying "almost done, PR up tomorrow" three days running while nothing moves. And even then, it reads as "has said the same for three days, worth a look," never "this person is failing," because sometimes the honest answer is that the task really is a week long. Eodly shows you the pattern; you make the call. The boundary stays narrow because the trigger is claim-versus-evidence over time, not "did they ship," and that is exactly what keeps it from getting noisy.
The "what actually shipped" framing lands, since standups usually drift into what people meant to do. Does Eodly pull signal from commits and PRs on its own, or does the team still log it manually? The moment something needs daily manual input my small team quietly stops doing it.
@chielephant Both, but the split is exactly why it survives a small team. The work signal is automatic: Eodly pulls commits, PRs, and ticket moves from GitHub and Linear on its own, with no logging. The only manual piece is the daily check-in, and it is deliberately one short message in a tool your team already has open (Slack, Telegram, Microsoft Teams, or Discord), not a form and not a new app. If someone forgets, the bot nudges them, so you are never the one chasing. And here is the part that matters for the failure mode you named: even if a check-in gets skipped, the report is not empty. The auto-pulled work still shows who shipped what. The check-in adds the person's intent and context and powers the "said X, evidence says Y" catch, but the system-of-record signal stands on its own. So "everyone quietly stops logging, and the tool dies" does not zero it out here. It just gets a little less rich.
Congrats on the launch. The sourced evening page idea feels useful because it meets the team where work already happens instead of adding another standup tool. The line between helpful context and surveillance is delicate though. Do you let teams see or contest the evidence before a founder digest goes out, or is the first review always from the founder side?
@wesc Straight answer: today the first review is founder-side. The digest goes to the founder, and the team does not preview or contest it before it is sent. You have named the exact tension, and I am not going to pretend it is fully solved. What softens it now: flags are framed as "worth a look," not verdicts; they are dismissible, and Eodly reads work products the team already puts in the open, not their screens or private messages. But you are pushing on the real thing, and you are not alone in this thread. Letting the team see their own entry, or contest the evidence before it goes out, is on our list, and candidly, you and another sharp commenter just moved it up, because a founder-only view is an asymmetry we would rather make transparent than lean on. If we get it right, it turns that delicate line into the differentiator. I would genuinely want your take on what "contest" should look like: a heads-up before send, an inline correction, or a right of reply in the report itself.
I think the safest version is an inline correction attached to the evidence, not a full pre-send approval flow. A heads-up before send can create meeting overhead, and a right of reply after the fact may arrive too late. If the person can quickly mark missing context or this maps to ticket X, the founder still gets the digest, but with the uncertainty visible instead of hidden.