Why we built our own time tracker instead of paying for one

We built our own time tracker rather than paying for a SaaS one, and the reason is the useful part of the story. The data we needed to bill from already lived in our session files, so a bought tool would have meant re-entering by hand what we already had. Our tracker calculates billable hours from that session data and feeds month-end, which turns month-end from a long job into a short one. This was a build-versus-buy decision, not a comparison of time-tracking features.

So this is a case study about when building beats buying, told through one real call we made. It is one of the internal tools we built by directing Claude, and it sits with the rest in the Business Case Studies collection, alongside how we rebuilt a Shopify store into a custom theme with Claude Code. Here is the decision, why it went the way it did, and the boundary it points to for your own tools.

The trigger: the data was already ours

The decision started with a specific, unglamorous problem. To bill clients, we needed billable hours, and the record of where the hours went already existed in our Cowork session files. The work we do leaves a structured trail of what was done and on what, and the billable time is sitting in that trail. A bought time tracker would have ignored that trail entirely and asked us to enter the hours again, by hand, into its own system.

Think about what that means. We would be paying a monthly subscription for the privilege of re-typing data we already had, from one place into another, every billing cycle. The tool would not be saving the work, it would be duplicating it. That is the moment the build-versus-buy question stops being abstract. When the bought option creates new manual work to bridge the gap between its world and yours, it is not actually buying you a saving, it is selling you a second copy of your own data and the labour to maintain it.

That is the real trigger, and it is worth naming precisely. We did not build because building is fun or because we wanted a custom toy. We built because the fit mattered and the data was already ours, and the bought option failed on exactly those two points. The need was specific to how we work, and the data lived in our systems. Those two conditions are the whole basis of the decision.

What we built, and what it shortened

The tracker calculates billable hours directly from the session data and feeds month-end. Because it reads the trail the work already leaves, there is no re-entry. The hours are computed from the record, not typed in from memory or from a second tool. Month-end, which is the moment all of this has to come together, turns from a long reconstruction job into a short one, because the data it needs is already assembled in the right shape.

The build itself was a matter of directing Claude to read the session data, calculate the billable hours from it, and produce what month-end needs. It did not require hiring a developer or running a software project. It required knowing exactly what we needed, billable hours out of session files, and directing the build until it produced them correctly. The engineering was real, but it was direction and judgement rather than a team and a timeline, which is the shift that made building the sensible option rather than the expensive one.

To be clear about scope, this case study is about the decision to build the tracker, not about the broader invoicing automation we run, which we have written about separately. The point here is narrow and deliberate: why we built this tool rather than bought it. The features it has matter less than the reasoning that led us to build at all, because that reasoning is the part that transfers to your own tools.

The boundary: when to build, when to buy

The decision turns on a boundary worth stating plainly. Build when the need is specific to how you work and the data already lives in your systems. Buy when the need is generic and well served by a mature product. Our tracker fell on the build side because it failed both buy conditions: the need was specific to our session-data workflow, and the data was already ours, so a generic tool would have forced duplicate work rather than removing it.

The reason this boundary is worth revisiting now is that the cost of building has dropped sharply. The old default, buy unless you are a software company, made sense when building meant developers, budgets, and maintenance you could not staff. When the build is directed through Claude rather than handed to a team, the maths changes. A fitted internal tool that reads the data you already produce can now beat a generic subscription that does not, in cases where it could not have justified the build cost before.

That does not mean build everything. It means the line between build and buy has moved, and tools that were clearly buy-only a few years ago are now worth a second look if they fail the fit-and-data test. The honest caution is that building is not free even when it is cheap: a self-built tool needs oversight and carries some fragility, so the fit has to genuinely pay. Where the need is generic and a vendor maintains the product better than you could, buying is still right. The skill is knowing which side of the line a given need sits on.

What a business owner can take from it

If you pay monthly for tools that do roughly what you need but not exactly, and you have assumed building a fitted version means hiring developers, the lesson here is that the assumption is dated. The build-versus-buy call now turns on two questions: is the need specific to how you work, and does the data already live in your systems. When both are yes, as they were for our tracker, a bought tool often just creates duplicate work, and a directed build can fit the workflow instead.

Making that call well for your own stack, knowing which tools genuinely fit you and which force you to bridge a gap by hand, is the work, and it is where building either pays off or becomes a distraction. We built our tracker because the fit mattered and the data was already ours, and those are the two conditions to test against everything else you are paying for.

What we would have lost by buying

It is worth spelling out what buying would actually have cost, because the price of the subscription was never the real number. A bought tracker has a monthly fee, and that fee is the part everyone compares. The cost that does not show up on the invoice is the duplicate work: every billing cycle, someone re-entering hours from our session files into the tracker's own format, by hand, because the tracker had no way to read where our data already lived. That re-entry is a recurring tax in time and in errors, and it would have run for as long as we used the tool.

There is also a quieter cost, which is the drift between two records. The moment you keep the same information in two places, your session files and the tracker, they start to disagree. Someone forgets to copy an entry, or copies it wrong, and now month-end involves reconciling two versions of the truth instead of reading one. A bought tool that cannot read your existing data does not just add re-entry, it adds a second source of truth, and second sources of truth are where billing disputes and quiet revenue leaks come from.

Building removed both costs at once, because the tracker reads the single existing record rather than maintaining a copy of it. There is no re-entry, because the data is read where it lives, and there is no second source of truth, because there is only one record and the tracker computes from it. That is the part the subscription-versus-build-cost comparison misses entirely. The real comparison is not the monthly fee against the build cost. It is the fee plus the recurring duplicate work plus the reconciliation risk, against a fitted tool that reads what you already have. Once you count all of it, the fitted build wins more often than the sticker prices suggest.

None of this argues for building everything. It argues for noticing when a subscription is quietly charging you twice, once in the fee and again in the work to feed it. That double charge is invisible on the invoice and obvious the moment you look for it, and it is the clearest signal that a need has crossed to the build side of the line. Where you find it, the fitted build usually pays for itself in the re-entry it removes alone.

The same instinct, read what already exists rather than rebuild it by hand, sits behind Ortopylot, which captures a brand once so every document a business produces comes out finished and on brand from one short instruction. It is the system we build for clients like Pulse Technology Hub, so the work that used to be re-done every time is done once and held. If you want this kind of automation built into your business, start a conversation at ortopylot.com.