Usually, everything is set up "for the manager"—the way they prefer to view the project. As a result, a tool that is supposed to help the team becomes a burden. When you work across multiple teams, the constant filtering and scrolling turn into a nightmare. You waste your energy fighting the interface before you even start working. I believe that one glance at the board should be enough to instantly see where we are, who is overloaded, and what is stuck. That’s why I’m building ooko. To finally make the board a tool for the entire team.

I always giggle when I look at the promo screenshot of fancy new to-do app that is supposed to solve the project management once and for all, and there are like 6 items on it instead of 200.

If this will solve the problem with boards, you need to be able to answer 2 questions:

1. What does this do that Trello doesn't?

2. What does Trello do that this doesn't?

Can you show the capacity and flow management parts?

I looked at some off the shelf task tracking and kanban packages and they didn't do quite what I wanted so I just vibe coded one up. We use it at home now.

My wife even made a special hidden mode for her game https://www.kanbanchaos.com so it can act as a frontend for our actual task tracker. Full taskception

In a team I worked, we had full control over how we wanted to use the board. But the senior people just refused to engage with it, as anything they did on the board would make them accountable.

My lesson: Boards can be awful and useless even without managers running them! :)

I've been using a simple, standalone kanban to manage my own tasks, though.

If you really did spend 6 years building this, then it's an excellent example of why you should be vibe coding instead; I don't see anything here that could not be made in 6 minutes instead of 6 years.

“I spent 6 years building my Kanban as I hated how managers run the boards”… only to discover that problem was the managers and workflows designed for their legibility (not engineers), not the technology or software itself, and that the tech itself could be rebuilt in a weekend nowadays?

That is a really limiting license.

Per the LICENSE file:

  Modification Ban: The User has no right to change, modify, decompile, disassemble or create derivative works based on the Program.

  Distribution Ban: The User has no right to distribute the Program without the prior written permission of the Licensor.

What does this do? Do i need it? What was it about the managers running the boards that was hated? Why does this solve that issue? So many questions

Made me think of a non-tech manager I had once who when we presented the newly installed bug tracker (of which we had none prior) that said . "This is great. You don't expect ME to use it right?")

I like the guy’s stubbornness. We all have been there.

I understand his account as releasing daily frustration in a constructive way. We all hate/love Jira, Excel whatever but the alternatives are worse and instead of one bad solution 20 different perfect apps to use as a substitute won’t cut it.

We all are or have been there.

I like the guy. It is funny.

I keep stating proudly to any team mate and any manager that I've never ever needed a board to know what I had to work on.

Six years of sticking with one product is the hardest part of solo building. Most of us (myself included) struggle with the opposite problem — shipping too many things and not going deep enough on any of them.

The convergence-to-Jira pattern mentioned in another comment is real, but I think the answer isn't "don't add features" — it's "add features for a narrower audience." A Kanban for 3-person dev teams will always beat a Kanban for everyone.

Curious about your distribution strategy. After 6 years, what's actually working for getting users — SEO, word of mouth, communities?