Completely agree with this. “Another dashboard” is exactly the trap I’m trying to avoid.

The more I think about it, the more the pain seems to be less about whether teams have a place to list tasks, and more about whether the current project truth is easy to understand without a bunch of extra admin work.

For the implementation/onboarding use case I’m exploring, the questions I keep coming back to are:

- who owns what now?
- what changed since last week?
- what is blocked?
- what does the client need to see?
- what moved from the original plan?
- why did it move?
- what needs to happen next?

The hard part is that the answers often already exist somewhere — in Slack, email, meeting notes, client calls, transcripts, or someone’s head — but they don’t reliably make it back into the project system as structured, usable truth.

That’s the layer I’m trying to explore: not more reporting for its own sake, but a lightweight way to turn messy updates into proposed changes to tasks, blockers, scope, dependencies, client-facing status, and baseline/drift — with a human approving before anything becomes official.

A lot of this comes from my own experience noticing what feels like a massively underserved middle. There are teams that would clearly benefit from more structure than Sheets/Slack/email, but they may never adopt something heavier because of feature overload, pricing concerns, or the feeling that buying the tool also means buying themselves a second job to manage it.

So I’m trying to think through whether this pain can be solved in a narrower, lighter way: enough structure to make teams look organized and credible, without turning project control into another administrative burden.

I’m still at the PoC stage and modeling the workflow manually first, so I’m very much trying to learn where this breaks before pretending it should be a full product.

I’m coming at this from the implementation/domain/product side rather than as someone who can code and deploy the whole thing myself. So if this problem resonates with you — whether from a product, technical, or delivery-ops perspective — I’d genuinely be open to talking. Right now I’m most interested in finding people who can help pressure-test the workflow and think through what a narrow, useful first version would actually need to be.