Building BiBoTracking: what one product taught me

I started building time tracking software because of a conversation I kept having with myself at the end of every week. I lead a small tech team. We bill clients. And every Friday I was reconstructing where the week went from memory, Slack scrollback and git commits. Not because anyone was slacking off - because nobody, including me, had a reliable record of their own week.

So I built a thing. That thing became BiBoTracking, and it now has businesses paying for it. What follows is the actual arc, including the parts I'd rather skip.

The prototype that worked too well

The first version was embarrassingly small. A desktop app that noticed which window was in front, how long it stayed there, and whether the machine was idle. It wrote rows to a local database. There was no server, no account, no dashboard. I looked at the data in a SQL client.

I ran it on myself for a couple of weeks and it was genuinely useful. I found out I spend far more time in meetings-adjacent tools than in an editor, which stung. I showed it to two people on my team and they wanted it.

That was the first trap. A prototype being useful to me told me almost nothing about whether a product would be useful to a business. What I had built was a personal diary. What a business buys is something else: a thing a manager can look at, that an employee trusts, that survives someone's laptop dying, that works on Windows when I only own Macs.

I didn't understand the size of that gap for months.

The wrong turns I kept

I built the dashboard before I'd earned it

I spent a long stretch building an admin dashboard, with charts, before anyone outside my own team had ever used the tracker for a full week. I wanted it to look professional, so I did the design system work, the component library, the dark mode. It looked good.

Then the first real pilot started and almost none of those charts were the question people asked. The question was always much blunter: was this person working yesterday, and on what? One screen answered that, badly. The rest of the dashboard was decoration I had to keep maintaining while I fixed the screen that mattered.

What it cost: weeks, and worse, it anchored me. Once a screen exists you defend it. I kept the charts alive long past the point where I knew they were noise, because deleting them felt like admitting the time was wasted. It was wasted either way. Deleting it just made that visible.

I treated "it works on my machine" as cross-platform

The desktop app started on macOS because that's what I use. Supporting Windows wasn't a feature I added - it was a second product with a shared name. Different idea of what a "window" is. Different idea of idle. Different signing, different installer, different update mechanism, different failure modes when a laptop sleeps.

I now build Windows releases on a separate machine on my LAN, driven from my Mac, because the only reliable way to know a Windows build works is to build it on Windows. That setup took me far too long to admit I needed.

I under-built the boring part and over-built the interesting part

Syncing data from a laptop that is frequently offline, sometimes asleep, and occasionally on hotel wifi is the actual product. It isn't interesting. It's retries, clock skew, duplicate suppression, and deciding what to do when a device sends you three overlapping versions of the same hour.

I kept getting pulled toward the interesting problems instead - nicer activity classification, clever summaries. Meanwhile the thing that lost me trust in early pilots was never classification quality. It was a gap in someone's timeline, and a manager asking why.

The lesson I'd state plainly: in a tracking product, the data pipeline is the feature. Everything on top is presentation.

What AI did and did not do

I used AI heavily through the second half of this. Honestly: it changed my throughput on the mechanical parts more than I expected, and changed my judgment less than I hoped.

Where it genuinely paid: scaffolding, test batches, porting a pattern across seven locales, writing the fiftieth CRUD handler that looks like the forty-ninth. Deploy scripts. Translating release notes into every language the app ships in. That class of work used to eat my evenings and now it mostly doesn't.

Where it cost me: anything that required knowing what the product should be. I wrote about this at length in “Vision” or “Hallucination”? - Hard Lessons from Delegating Product Strategy to AI, and BiBoTracking is where I learned it. Ask a model what to build next and you get a confident, coherent, plausible roadmap that is a statistical average of every SaaS roadmap ever written. It is never obviously wrong. That's what makes it dangerous. Half the features I later deleted came from plans like that.

The other thing it did not do: tell me when a thing was already good enough. Models are agreeable. They'll help you add the seventh filter to a screen nobody uses. Knowing when to stop is still entirely mine.

Getting to the first paying business

The first money changed what I worked on more than any amount of thinking did.

Two things happened immediately. First, I stopped shipping on impulse. When someone's payroll conversation depends on your data, a bad deploy isn't a bug, it's an argument between a manager and an employee. I started snapshotting the live binary, the web build and the database before every production deploy. That one habit has saved me twice.

Second, I started hearing objections I could never have predicted from my own desk. Not "I want more charts." Things like: can my staff see exactly what's captured about them? Can I turn a part of it off for one person? What happens on a day someone works offline? Those questions reshaped the product more than my roadmap ever did.

The uncomfortable part is that most of this was available to me earlier. I could have asked three managers these questions before writing the dashboard. I didn't, because building felt like progress and asking felt like stalling.

What I'd do differently

• Ship the ugliest useful version to someone who isn't me, fast. Not a prototype I demo - something they run for a full week unattended. Everything I learned that mattered came from that, and I delayed it by months.
• Pick one question the product answers and build only that. Mine was "what happened yesterday." Anything that didn't serve it should have waited.
• Treat each platform as its own commitment. Not a checkbox. If I can't maintain it properly, I shouldn't claim it.
• Build the boring reliability layer first. Sync, retries, backups, restore. You can add polish to a trustworthy product; you can't add trust to a polished one.
• Use AI for the typing, not the deciding. It's a genuine multiplier on work I've already specified and a liability on work I haven't.

The thing nobody tells you

One product taught me that the hard part of a small SaaS isn't the building. I'm a developer; building is the comfortable part, which is exactly why I hid in it. The hard part is the discipline of only building what someone has told you they need, and then keeping it alive for years - the updates, the signing certificates, the migration that has to run on a machine you can't see, the support message at 10pm.

BiBoTracking is smaller than the version of it I had in my head three years ago, and it's better for that. Most of what I cut, I cut because it never answered anybody's actual question. The remaining work isn't glamorous. It's a product that quietly tells a handful of businesses what their week looked like, and doesn't lie to them about it.

That turned out to be enough, and getting there taught me more than any of the plans did.