I reorganised my project tool by client, not by repository

I run my projects through a tool I built. It is called Shipyard, it runs on my machine, and I am its only user. Right now it holds 2,863 tasks, 2,596 of them already closed, across twelve projects.

For a year it had one tab per repository. That felt right. A repository is a unit of work, with its own git, its own deploy, its own folder. The problem turned up in conversation with clients, not in the code.

The question the tool could not answer

One of my clients runs seven systems, each in a separate repository, with its own branch and deployment. When he asked what was left, I opened seven tabs, added things up in my head and answered roughly. Another client has two systems and a website, same story on a smaller scale.

The work happens per repository. The conversation happens per client. My tool sat on the wrong side of that line.

What I changed

I moved to one tab per client, pointing at their root folder. Today that is seven client tabs and five for my own projects. The 113 tasks scattered across subprojects moved into the client tabs, with the subproject name in brackets in the title.

It sounds like a small thing. In practice I open one tab and see everything I owe that client, with nothing to add up. What is stalled sits next to what is moving. Work that belongs to no client, study or internal tooling, stays in the project tabs and out of the count.

What stayed with me

Internal tools have users too, and those users think in a particular shape. My mistake was copying the shape of the disk when what I needed was the shape of the conversation. Git organises code. A client organises commitment. Two cuts of the same work, and the tool I open every morning needs the second one.

It holds for the software I deliver as well. When a dashboard mirrors the org chart of whoever built it, rather than the work of whoever uses it, the outcome is always the same. Somebody adds things up in their head, every day, to reach the number that matters.