When a small internal tool starts becoming a product

The first version of HoursKZ did what I needed it to do. Employee time tracking in my coffee shop had been too manual, and the tool made it less manual. People could record their time through Telegram, and I no longer had to track the process manually the way I had before. That was already useful. But once HoursKZ became part of normal operations, the original problem stopped looking as isolated as it had at the beginning.

A time record told me what someone had worked. But normal operations also had a plan. Schedules changed. Someone could be away. A shift might need coverage. Recorded time might need review. None of those things were surprising on their own. What changed was that I could now see more clearly how often they met.

Before HoursKZ, I could think about a work schedule and a time record as separate things because the manual process already forced me to reconcile them in my head. Once one part became software, that separation became more visible. The software had removed one piece of manual work, but in doing so it exposed the work around it.

The original problem was still real

I did not start HoursKZ with a plan to build a broader workforce product. The original goal was much narrower: replace a manual time-tracking process with something that fit naturally into how the coffee shop already operated. That first version was not wrong. Its narrowness was part of what made the next problems easier to see.

I had an actual workflow instead of a diagram of one. People were using it. Changes had consequences. I could compare what I thought would happen with what actually happened during normal work. The original assumption had been useful, just incomplete. The first version had worked well enough to expose more of the operation. That is quite different from deciding afterward that the original scope had been a mistake.

Some of the surrounding work kept meeting the original workflow

Scheduling was one of the clearest examples. Scheduling was not interesting because scheduling software exists as a category. It was interesting because planned work kept meeting recorded work.

If someone had been scheduled but did not work, there was a reason. If someone else covered the shift, the plan and the eventual record needed to make sense together. Time off could affect who was expected to work. Reviewing recorded hours was easier when there was some context for what had originally been planned. The same thing happened around approvals and history. I did not suddenly decide that HoursKZ should contain every operational process in the coffee shop. I started noticing that some of those processes repeatedly crossed the workflow I had already built.

That changed the product question. It was no longer only: Does time entry work? It became closer to: What needs to exist around time entry for this piece of the operation to work properly? Those are not the same question.

More possibilities did not automatically mean more product

Once I started looking at the surrounding operation, there was no shortage of things that could be added. Some of it was clearly connected to the original problem. Some of it was simply nearby. That distinction was not always obvious.

One of the more useful observations from this period was that scope growing is not evidence that scope should grow. A repeated problem affecting the same workflow felt different from a one-off inconvenience. Something that repeatedly forced people to move information between two places felt different from a feature that would merely be convenient. And a reasonable request could still belong somewhere else.

There was another temptation as well: sometimes something was simply easy to build. That is weak evidence. A product can accumulate a large number of individually sensible features and still become less coherent. So I found myself asking a fairly ordinary question more often: Why does this belong here?

Sometimes the answer was clear. Sometimes it was not. Some things belonged. Some probably did not. Some were still too early to judge. Eventually I realised I wasn't going to resolve that uncertainty once and move on.

Something else changed as people started relying on it

The current screen was no longer the whole story. History started to matter. Different people needed different views or actions. A change in one place could affect what someone expected to see somewhere else. It was becoming something people relied on rather than something they simply tried. That changed how I thought about even relatively small changes.

When a tool is only helping me with a private task, I can change it fairly casually. When it has become part of normal work, a change can affect someone else's routine. The software starts carrying some of the responsibility that previously lived in manual habits, conversations and memory.

There was no single moment when HoursKZ crossed a line and officially became a product. It was much more gradual than that. But this was the point where it started to feel different to me. Several decisions that had once looked independent now had to make sense together.

Codex shortened the loop

Codex changed the pace of this process. The distance between noticing an operational issue, deciding to try a change, implementing it and putting it back into use became much shorter. That was valuable because many of these questions were difficult to answer in the abstract. A working change gave me something concrete to inspect and something real people could actually use.

But it also made saying yes easier. When another workflow can be implemented and revised quickly, some of the natural resistance created by implementation cost disappears. That is useful for experimentation. It also means I have to pay more attention to whether a change actually belongs.

Being able to build something is weak evidence that it should become part of the product. Codex could shorten the loop. The product decision was still mine.

Looking back, I still do not think HoursKZ started too small. If I had tried to design the broader system from the beginning, I could have drawn a convincing picture of how scheduling, time records, time off, approvals and other operational work should fit together. Some of it might even have been right. But much of it would have been imagined.

Starting with one useful workflow gave me something better than a complete initial plan: it gave me reality to react to. Real use showed me connections I had not needed to think about before. It also showed me that seeing a connection and deciding to absorb it into the product were two different things.

The first version solved the problem I could see. What came afterward was not simply a longer feature list. It was a gradual discovery that the original workflow belonged to a larger operating pattern, and that I now had to decide how much of that pattern HoursKZ should actually carry.

The difficult part now is not seeing more possibilities. It is deciding which of them are actually part of the same problem.