HoursKZ started as a very small problem

The first TechJinni Journal entry was about why I started keeping notes on what changes when I build products with AI. The first concrete story behind those notes is much less dramatic. I own a coffee shop, and employee time tracking was being handled manually. That was it.

There was no grand product idea behind HoursKZ. I wasn't looking around the business for somewhere to put AI. I had a recurring operational task that was annoying enough to fix. People worked their shifts, their hours had to be recorded, and I had to keep track of them. The process worked, but it required manual attention every time. After enough repetition, I wanted it gone.

The first idea was very small

Telegram was already part of how we communicated, so the first idea was straightforward: build a simple Telegram tool that makes employee time tracking easier. Not a workforce platform. Not an HR system. Not a plan for a SaaS product. Just a better way to handle one recurring task in a business I already understood.

That narrow boundary mattered more than I appreciated at the time. There are many things I could have imagined adding before the first version existed. Once you start thinking in product terms, it is easy to see adjacent possibilities everywhere. But none of those possibilities were the reason I started. The reason was still the same: I was tired of handling employee time manually. So that was the job of the first version.

There was very little distance between the problem and the product

One advantage in this case was that I didn't have to invent a hypothetical user or reconstruct a workflow from a meeting. I was inside the workflow. I knew why the manual process was irritating because I was doing it. I knew Telegram was a reasonable place to interact because it was already part of normal communication. And once the tool existed, I could put it into the real environment it was meant for.

That made the first questions unusually concrete: Does this remove enough manual work to be useful? Is it easier than the process it replaces? Can people actually use it in the middle of a normal workday?

Those were much more useful questions than trying to decide what the eventual product should contain. I didn't need a complete product vision to answer them. I needed something working.

Building the narrow version gave me information

I don't take from this that every product should always start as small as possible. Sometimes a narrow version would be artificial. Sometimes the important value only appears when several pieces exist together. Sometimes the cost of making a deliberately incomplete first version would be higher than just building the broader workflow properly.

HoursKZ happened to be a case where the smaller boundary was real. Employee time tracking was a problem on its own. I could improve it on its own. And I could tell whether the improvement was useful without pretending the rest of the business did not exist.

That gave me something speculation couldn't: a working tool inside the business where the problem actually existed. Before that point, I had assumptions. After that point, I had behaviour to look at.

AI made the experiment cheaper, not necessary

AI entered the story because it changed how I could build. Working with Codex reduced the implementation effort involved in turning the idea into software, trying something, changing it and trying again. That mattered.

A small operational irritation is easier to justify solving when the cost of experimenting with software drops. Work that might previously have sat in the category of "useful, but probably not worth building" becomes more plausible. I think that changes product decisions in ways I am still working through.

But AI was not the reason HoursKZ needed to exist. If the manual process had not been irritating, there would have been nothing worth building. The problem came first. The technology changed what I could reasonably do about it.

That difference matters to me because it is very easy to start from the opposite direction: we have this capability, so where can we apply it? HoursKZ began with a much more ordinary question: What am I doing repeatedly that I no longer want to do manually?

The bigger discussion about when AI actually belongs in a product is one I'll come back to separately. In this case, it was enough to notice that the operational need was already there before AI entered the picture.

The first version did not need to know the ending

Something else became clearer only after the tool existed. When a problem is still in your head, its boundaries can look cleaner than they really are. You can describe employee time tracking as one task. You can design a solution around that task. You can build it and make that part better.

Then you put the solution into normal use. That is when the surrounding reality starts becoming visible. Not because the first idea was necessarily wrong, but because working software removes one layer of guesswork. People stop reacting to an idea and start interacting with a thing. The questions change.

The first version of HoursKZ did what I originally needed it to do: it made a manual process less manual. That was already useful. But once it was being used, I could see the edges of the original problem more clearly. And those edges were not quite as neat as they had looked from the starting point.