What building your own time tracking tool really costs
We have been on both sides of this decision. We built a time tracker and kept it. We self-hosted a build server for 7.6 years and switched it off in 2026. Here is how to tell which one you are looking at.
Building a time tracker made sense when the market had no answer. It has one now, and it costs $0 for unlimited users, so there is no subscription for your build to earn back.
- AI collapsed the cost of version one. Version one was never the expensive part.
- Published estimates put maintenance between 60% and 90% of a tool’s total lifetime cost.
- Building is still the right call in a few specific cases, and they are listed further down.
Free for unlimited users. No seat limits, no upgrade gates, and a custom offer for registered nonprofits.
But AI can build this in a weekend
This objection is fair, and it is more true every month. Teams are acting on it: in Retool’s 2026 build-vs-buy survey of 817 builders, more than a third had already replaced a SaaS tool with something they wrote themselves.
Then look at how those same builders actually work. 72% use AI to write discrete pieces of code they integrate into a larger project, and only 31% prompt their way to a complete application. Just 8% ship AI-written code without changes, and 26% named maintenance burden as an organizational blocker.
So the generated draft is not the deliverable. Someone still owns the tests, the security review, the dependency upgrades, and every edge case listed further down this page. AI collapsed the cost of version one. Version one was never the expensive part.
Retool, build-vs-buy report, published 2026, based on a survey of 817 builders conducted in late 2025. Checked August 2026.
We retired our own build after seven years
Our Jenkins server ran from 3 January 2019 until we switched it off on 10 August 2026. It was reliable, it was ours, and replacing it with a hosted service was clearly the right decision by the end.
The polling ran every two minutes for seven and a half years, mostly to discover that nothing had changed.
What finally ended it was not the hosting bill. It was that the person who knew the system took leave, and nobody else knew the access, the network routes, or where anything actually lived. That is the cost nobody puts in the build estimate. Everything now lives in the repository, where a teammate or a coding agent can simply read it.
And yet self-hosting was the right call in 2019. GitHub Actions did not exist. Hosted CI was in its infancy. The decision was correct when we made it and wrong by the time we ended it, because the market filled in underneath it while we were not looking.
That is the part worth taking away. A build decision is not permanent. It has an expiry date, and almost nobody schedules the review. Time tracking’s market filled in more than a decade ago.
Figures from our own build server, published August 2026. See the original post
The numbers tell the real story
Internal tools are a bigger and longer commitment than most teams price in.
The maintenance range aggregates long-standing software engineering estimates that vary widely by system type, so read it as a range rather than a forecast for your codebase. Checked August 2026.
Five years of owning it, against $0
The build is the part teams estimate. The four years after it are the part they do not.
Illustrative five-year totals at 500 engineering hours each for the initial build, a blended rate of $100 per hour, and annual maintenance at 25% of the build. Adjust the assumptions below.
What would it cost your team?
Adjust the inputs to estimate what building and then keeping a time tracking tool would actually cost.
Assumes 500 engineering hours each for an initial build, then annual upkeep priced as a share of that build. Excludes product design, QA, DevOps, security review, and the cost of the work those engineers did not do instead.
What you would actually be signing up to build
This is not a hypothetical list. It is the list we worked through, and every item is here because a real user hit it.
Timezones and daylight saving
A timer started before a daylight saving change and stopped after it still has to report the right duration, in whatever zone each person works.
Rates that change over time
When a cost or billable rate changes, last quarter’s reports must keep using the rate that was active then, not the new one.
Overlap detection
Two entries covering the same minutes will silently inflate an invoice unless something catches the conflict as it is created.
The approval workflow
Submission, approval, rejection, reminders, locking past periods, temporary unlocks, and a record of who requested and resolved each one.
Roles and visibility
Who may see whose hours, which projects appear to whom, and what a manager can approve. Every answer is a permission check somewhere.
Multiple currencies
Rates in different currencies for different clients, reported side by side against costs, without turning every report into a conversion argument.
Getting the data back out
Excel and CSV exports that finance will actually accept, in the shape payroll and invoicing already expect.
Everywhere people track time
Desktop apps, mobile apps, a browser extension, a Slack integration, a REST API, and an MCP server. Each one is a release process of its own.
Any one of these is a weekend. Together they are 15,000 hours.
We know because we did it too
Sandtime.io started as an internal tool. The team needed to track time across projects and clients, refused to put people on surveillance software, and thought the same thing everyone thinks: how hard can it be?
Hard enough that it became a product. Months of development, then the feature requests, the bug fixes, the mobile apps, the currency conversions, the Slack integration, the browser extension. More than 15,000 engineering hours later, we are proud of it.
That is exactly why it is free. Our two internal tools went in opposite directions: the time tracker became the product, and the build server became a liability. The difference was never effort. It was whether anyone else had already solved it well.
The hidden costs of building in-house
The initial build is only the beginning. Here is what teams consistently overlook.
Development
Design, architecture, coding, testing, and deployment. What starts as a simple tracker quickly grows into a project with edge cases nobody scoped.
Maintenance
Bug fixes, security patches, dependency upgrades, browser compatibility, and mobile releases. The work never stops once you ship the first version.
Opportunity cost
Every engineering hour spent on internal tools is an hour not spent on your core product. Your competitors are not building their own time trackers.
Bus factor
Training new hires, writing documentation, and keeping continuity when the people who built it move on. Internal tools quietly become institutional debt.
Build vs buy, the short version
Time tracking is a solved problem. Your engineering time is worth more elsewhere.
Building in-house
- Months before it is genuinely usable
- Constant feature requests from your own team
- Bug fixes arrive as urgent internal support tickets
- The people who built it leave and take the context with them
- No mobile apps, browser extensions, or integrations
- Security review and data protection fall entirely on you
Sandtime.io
- Start tracking time in minutes, not months
- New features arrive without a release of your own
- Engineers stay on the work that earns money
- Documentation and human support already exist
- Desktop, mobile, browser extension, and Slack included
- Security and data protection are someone else’s full-time job
Decision factor by decision factor
There is a third option people forget: buy the tracker and build only the layer that is genuinely yours.
| Decision factor | Build in-house | Use Sandtime.io | Use it and extend it |
|---|---|---|---|
| Time to a usable version | Months | Minutes | Minutes, plus your own build on top |
| Cost in year one | Engineering salary | $0 | Only the part you chose to build |
| Cost in year five | Engineering salary, again | $0 | Only the part you chose to build |
| Who fixes the daylight saving bug | Your team, at whatever it is doing instead | Us | Us, for everything under the API |
| Who owns the security review | Your team | Us | Shared, split at the API boundary |
| When the person who built it leaves | The tool becomes nobody’s job | Nothing changes | Only your own layer needs an owner |
| Fits a workflow nobody else has | Exactly what you specified | What the product supports | Your workflow on our records |
When building actually is the right call
Sometimes it is. These are the cases where we would build too.
Time tracking is what you sell
If you sell time tracking, this is not an internal tool. It is your product, and everything on this page is your roadmap instead of your overhead.
The workflow is your actual moat
If the way you record work is genuinely the thing clients pay you for, a generic tool will file the edges off your advantage.
A hard data residency requirement
Air-gapped networks and strict data residency rules are real constraints. If no vendor can meet yours, the decision is already made.
It ships inside your product
If time tracking has to live inside software you ship to your own customers, you are building a feature, not adopting a tool.
The market has no answer yet
Self-hosting our CI in 2019 was correct because GitHub Actions did not exist. When the market has no answer, building is the only answer.
If one of these applies, build it. Then put a date in the calendar to check whether it still applies, because that review is the step almost everyone skips.
One more thing, if you operate in the EU
Working time records are not only an internal convenience there. In CCOO v Deutsche Bank (C-55/18) the Court of Justice of the European Union held that member states must require employers to set up an objective, reliable, and accessible system measuring the daily working time of each worker.
Build your own and that obligation, plus every future change to it, becomes something your team maintains. This is context rather than legal advice, and Sandtime.io does not claim certified compliance in any jurisdiction.
Build vs buy questions
Is it cheaper to build or buy a time tracking tool?
Buying is cheaper here for an unusual reason: Sandtime.io is free for unlimited users, so there is no subscription for a build to earn back. In a normal build-vs-buy comparison you weigh a one-off build against a recurring license. Against $0, the build never breaks even.
Can AI just build a time tracker for us now?
It can write a working timer quickly, and that is genuinely new. It does not change who owns the tests, the security review, the dependency upgrades, and the edge cases that arrive later. In Retool’s 2026 survey only 8% of builders shipped AI-written code unchanged, and 72% used it for discrete pieces they integrated themselves.
How long does it take to build a time tracking tool?
A basic timer takes days. A tool your finance team will bill from takes far longer, because the hard parts are daylight saving, historical rates, overlapping entries, approvals, and exports rather than the timer itself. Sandtime.io has taken more than 15,000 engineering hours so far.
What is the hardest part of building time tracking?
Correctness over time. A timer that spans a daylight saving change, a rate that changed in March but must not rewrite February’s reports, and two entries covering the same minutes are all cheap to get wrong and expensive to discover on an invoice.
When does building your own actually make sense?
When time tracking is the product you sell, when the workflow itself is your competitive advantage, when data residency rules leave no vendor option, when it has to ship inside your own product, or when the market genuinely has no answer yet. Outside those cases the market filled in a long time ago.
Is Sandtime.io really free for unlimited users?
Yes. The live product is free for unlimited users and projects, with no seat charge, no credit card requirement, and no upgrade gate. Registered nonprofits are eligible for a custom offer.
Can we use Sandtime.io and still build our own layer on top?
Yes, and it is often the right answer. Track time in Sandtime.io, read the records through the REST API or the MCP server, and build only the layer that is specific to you. Neither interface has a published versioning policy yet, so plan for change and keep exports available.
Keep reading
Where to go next, whether you are buying, building, or doing both.
Build vs buy time tracking software
The sourced version of this argument, including the numbers behind our own retired build.
Open pageSandtime.io REST API
Read time entries, projects, rates, and timesheets programmatically.
Open pageSandtime.io MCP server
Connect Claude, ChatGPT, and other MCP clients to your time records.
Open pageTemporal cost and revenue rates
Rates change, and past reports keep using the rate that was active at the time.
Open pageBillable leakage calculator
Estimate what untracked work is quietly costing your team each month.
Open pageAll Sandtime.io alternatives
Compare Sandtime.io with Toggl, Clockify, Harvest, and TimeCamp.
Open pageStart tracking time today, not next year
Join the 4,000+ freelancers and teams who kept their engineers on the product they sell.