Status in Slack and standups vs one "where are we" page
By Soumen Sarkar · October 2026
Comparison. If your problem is talking things through, keep Slack and your standup. If your problem is that product and leadership can't see where the work stands without asking, give them one "where are we" page that the work writes itself. Most teams need both.
The short answer
If your problem is talking things through, keep Slack and your standup. They are where a team argues, asks and agrees. If your problem is that product and leadership can't see where the work stands without asking someone, add one "where are we" page that the work writes itself. Most teams have both problems, and the two don't compete.
What are you trying to fix?
- "We need to decide this together, now." Slack, a call, or the standup. Conversation is what they're for.
- "Engineers need to unblock each other each morning." The standup. The Scrum Guide describes the Daily Scrum as "a 15-minute event for the Developers" to inspect progress toward the goal (Scrum Guide). It is built for the people doing the work.
- "I'm the PM or the CTO, and I can't tell what shipped or what got decided this week." A single page everyone opens. Neither a channel nor a meeting gives you that, because each one shows only what someone remembered to say.
The same day, with each
This is a scene, not a customer. Three developers each run a few Claude Code sessions on a billing change. A product manager owns the feature. The CTO wants to know on Friday whether it goes out next week.
With Slack and a standup. At the 9:30 standup each developer gives a quick summary. One says "invoices are mostly done." Nobody mentions that an agent decided on Tuesday to round tax per line instead of per invoice; it was a sensible call, made in a session, and it never reached a human sentence. The team's standup bot posts the same summaries into a channel, a pattern Slack itself recommends for remote teams (Slack blog). By Thursday that channel holds dozens of messages, many of them threads. The PM scrolls, finds "mostly done" three days running, and books a half-hour to ask. The CTO asks the lead directly. The lead spends an hour in pull requests to answer both. The rounding call surfaces the next week, when finance asks why totals moved.
With a "where are we" page. The developers still talk in Slack and still meet at 9:30. Their sessions also record each finished change in a plain sentence, and each decision with its reason, as they work. The rounding call is on the record on Tuesday, with why. The PM opens the project's "where are we" page: what's being worked on, what's waiting on whom, what landed in the last two weeks, and the latest published plans and results. The decision posts to the team's Slack channel as a milestone the moment it's made. She disagrees and says so in the thread, the way she always does. The CTO reads the same page on Friday. Nobody wrote a status report. See what a session gets.
At the end of the week, one team learns about a decision from finance. The other argued about it in Slack on Tuesday, because the page put it in front of them.
We work this way on Campfyrr. The instructions in our own repository tell every session: "After each change you finish, call `logwork` ... what changed and why, in plain words a non-engineer follows (outcome first, no file names or jargon)."_ The daily updates and the page are written from those lines.
When Slack and standups are the better choice
Mean it: for many teams, they are enough.
- Two or three people, one product. Everyone hears everything at standup. A page adds little.
- The hard part is agreeing, not seeing. A page shows what was decided. It doesn't help a team argue its way to the decision. Slack and a call do.
- Most of your work doesn't go through coding agents. Campfyrr only reports what is recorded in it. Design reviews, sales calls and support threads stay in Slack.
- You want one tool, not two. Campfyrr posts milestones into Slack but doesn't read Slack. The talk stays where it is.
What it costs
Take 5 developers and 3 business teammates.
- Slack: Pro at $7.25 per user a month billed yearly, so eight seats come to $58 a month (Slack pricing, read through search results). Most teams pay this already.
- Campfyrr: five developers at $7 billed yearly is $35 a month ($45 billed monthly). The PM, the CTO if they don't code, and other business teammates read and answer free. Everything is free during early access (pricing).
The cost that matters more is attention. A standup costs every attendee a slot each day, and a status channel costs someone the job of writing in it and everyone else the job of scrolling it. The page costs nobody a daily task: the work records itself as it happens. What it asks is that sessions log their work; anything nobody logged doesn't appear, and "landed" means finished and recorded, not deployed.
For the wider problems, see silos at agent speed and telling your CEO and PM what shipped. If you also want to watch agent tasks inside Slack, read Campfyrr vs Slack Code and Linear. Every product we looked at is in our research.
Verdict
Keep Slack and your standup for talking, deciding together, and unblocking each other each morning. Nothing here replaces them.
Choose Campfyrr if product and leadership keep asking where things stand, and the answer costs your lead an hour in pull requests each time.
Use both if several people run agents on one product. Talk happens in Slack; the "where are we" page is the one place everyone sees, and its milestones land in the same channel.
The problem this answers: Silos at agent speed: "Engineering moves at agent speed, but product, design, QA and the business still work in separate silos."
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).