When you add a person to SRP now, you make one choice: does this person sign in, or not? Both are real members of your team. Both can own work, carry a capacity, and be on leave. The only difference is that one of them opens SRP and the other never does. Members without sign-in, which the app calls managed members, are free, on every plan, in unlimited numbers, and they never receive an email from us.
Monday, 8:55am. You type one line into Claude:
Where are we, and what needs me today?
A few seconds later you have it. Two initiatives at risk and the reason for each. Three tasks of yours due this week. Ana is off Thursday, which is why the design review has no room in it. You reply, in the same window: move the review to Wednesday, add a blocker to the billing rewrite for the legal sign-off, and add a task to the website project to redo the pricing copy. Done, all of it, in your workspace, with your name on it.
No board. No tabs. No status meeting. That is live today: SRP now runs an MCP server, and any assistant that speaks MCP can plug straight into your work.
Two changes went live on the pricing page this week. SRP now has a Free plan that never expires. And there is no per-seat plan on the page anymore, on purpose. Here is what changed and the reasoning behind it, because pricing is a product decision and you deserve to see the working.
A good client status update does one job: it tells the client where their project stands clearly enough that they do not have to ask. Do that well and you get fewer where-are-we emails, calmer clients, and a lot less firefighting. Do it badly, or late, and you get the opposite. Here is how to write one, what to avoid, and a sample you can copy.
We have argued before that the half of governance built on habit gives way under load. The report that requires busy people to feed it honestly every day fails on precisely the weeks it was bought for. That is a claim about a category. This is the practical follow-on: how to test any single feature in your stack for it, before you find out the expensive way.
It takes about a minute per feature and needs no trial period. Four questions.
A tool that derives risk from your work instead of asking someone to type it solves a real problem. It also introduces a new one, and it is worth naming plainly rather than discovering it the hard way.
A derived signal is a claim about the world, produced from data. If the data is thin, stale, or simply absent, the claim is wrong. But it does not look wrong. It looks exactly like a correct one, because it was computed a moment ago from whatever was available, and freshness of computation is not the same thing as completeness of input. That is the trap. A green project can mean the work is healthy, or it can mean the system cannot see the work at all, and by default those two render identically.
Any tool that warns you about slipping work has a number in it somewhere. How many days of silence before a task counts as stale. How far behind an iteration has to fall before it goes amber. How close a due date has to be before anyone hears about it. That number is a judgement call, and it is the least discussed part of the entire category, because it is where a warning system either earns its place or quietly becomes furniture.
Get it wrong in one direction and the tool shouts at everything. People stop reading, build a filter to mute it, and start tracking the real risks in a side channel. Get it wrong in the other and the tool sits there approving of everything, and you are back to relying on someone noticing in time. Both are failures. Only one of them ever generates a complaint, and that asymmetry is what actually kills alerting systems.
If you run client projects, you send status reports, and if you are like most agencies you have rebuilt the same one from scratch more times than you can count. This is a clean client project status report template you can copy, along with what belongs in each section and how often to send it. It works for a weekly email, a shared doc, or a slide, and it is deliberately short, because a client report nobody reads is worse than no report at all.
The most important number for any project tool is not how much it can do. It is how often people actually open it without being told to. Every tool works in the demo and works in week one, when the team is trying. The real test comes in week six, on a busy afternoon, when opening the tool is one more thing to do and nothing forces the issue. Do people still reach for it, or do they quietly stop?
That question sounds soft. It is the whole game, because a tool the team has quietly abandoned is worse than no tool at all.
Every tool you have ever planned in knows two things about your work: when it is due, and roughly how big it is. And every one of them keeps those two facts in separate drawers. The due date sits on the item. The size sits next to it. Nobody does the one thing that would actually answer the question you care about: can this be finished by its target date, by the people who are actually doing it, with the time they actually have?
That is the question Team Capacity answers. Continuously, and without asking anyone to do anything new.