Build vs Buy Time Tracking: What We Learned Retiring Our Own Build

On 10 August 2026 we switched off a build server that had been running since January 2019. It was reliable. It was ours. Retiring it was obviously right by the end, and self-hosting it was obviously right when we started. Both of those things are true, and the gap between them is the whole build-vs-buy question.

We just retired one of our own internal tools

Most build-vs-buy articles are written by people selling the buy side who have never carried the build side. We have carried both, in opposite directions, and the contrast is the most useful thing we can offer.

That last number is the one worth sitting with. Roughly two million times, every two minutes for seven and a half years, the server asked the repository whether anything had changed. Almost always, nothing had.

The bill was never the problem

Self-hosting is usually argued about on infrastructure cost. That is not what ended this one.

What ended 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. The build kept running, but nobody could confidently change it. That is the line item missing from every build estimate ever written: not what it costs to run, but what it costs when the one person holding the context is unavailable.

Everything now lives in the repository. A teammate can read it. So can a coding agent, which turns out to matter more than we expected.

But AI can build this in a weekend now

This is the first objection every engineering team raises in 2026, and it is a fair one. It is also more true every month, and teams are acting on it rather than just talking about it.

Retool, build-vs-buy report published 2026, based on a survey of 817 builders conducted in late 2025. Just over a third of respondents identified as software engineers. Read the report. Checked August 2026.

So the trend is real. But look at how those same builders describe their own work, because the detail undercuts the headline:

• 72% use AI to write discrete pieces of code they integrate into a larger project.
• 31% prompt their way to a complete application.
• 8% ship AI-written code without changes.
• 44% test thoroughly before deploying anything.
• 26% name maintenance burden as an organizational blocker.

The generated draft is not the deliverable. Somebody still integrates it, tests it, reviews it for security, and owns it when a dependency breaks eighteen months from now. AI collapsed the cost of version one, and version one was never the expensive part. Our build server did not cost 7.6 years of attention because writing the first Jenkinsfile was hard.

What five years of owning it actually costs

Here is the part teams get wrong. The build gets estimated. The four years after it do not.

Commonly cited software engineering estimates put maintenance at 60% to 80% of a system’s total lifetime cost, and hold that maintenance over an application’s operational life totals two to four times the original development investment. The figures vary widely by system type, so treat them as a range rather than a forecast, but the direction is not controversial.

Team size sets the slope. Time sets the total, and this is the shape teams do not picture when they approve the first version:

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 cost. Adjust every assumption in the build-vs-buy calculator.

Why the payback period does not exist

A normal build-vs-buy comparison weighs a one-off build against a recurring licence. You divide, you get a break-even point in months, and you argue about the discount rate.

That arithmetic needs a subscription on the other side. Sandtime.io is free for unlimited users and projects, with no seat charge and no upgrade gate. Divide any build cost by $0 in avoided licence fees and there is no break-even point to find. The build is not slow to pay back. It does not pay back.

This is unusual, and it is the single strongest argument on this page. It is also the one that would evaporate if our pricing changed, which is worth saying out loud rather than hiding.

What you would actually be signing up to build

This is not a hypothetical list. It is the list we worked through over more than 15,000 engineering hours, and every item is here because a real user hit it.

Any one line is a weekend. The left column is what gets scoped. The right column is what gets shipped, eventually, after the third invoice dispute.

When building genuinely is the right call

Sometimes it is, and a page that pretended otherwise would not be worth reading. These are the cases where we would build too.

If one of these applies, build it. Then put a date in the calendar to check whether it still applies. Markets fill in. Ours did, in seven years, while nobody was watching. That review is the step almost everyone skips, and skipping it is what turns a good decision into a liability.

The option people forget: buy it and build the thin part

Most teams who want to build do not actually want a timer. They want one specific report, or their own billing logic, or a dashboard shaped like their business. You can have all of that without inheriting the daylight saving bugs.

The REST API and the MCP server are both currently badged developer preview. There is no published rate limit, versioning policy, or service level agreement yet, so plan for change and keep exports in the loop. That is a real limitation and you should weigh it before committing a critical workflow to either interface.

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, 14 May 2019) the Court of Justice of the European Union held that member states must require employers to set up an objective, reliable, and accessible system enabling the duration of daily working time to be measured for each worker.

Build your own and that obligation, plus every future change to it, becomes something your team maintains and re-verifies. This is context rather than legal advice, and Sandtime.io does not claim certified compliance in any jurisdiction. You can read the judgment directly.

How to decide in an afternoon

Ask three questions, in this order.

1. Is time tracking something we sell, or something we use? If you sell it, stop reading. If you use it, continue.
2. Does anything on the market solve this? For time tracking the honest answer is yes, and has been for over a decade. For your genuinely unusual problem, maybe not, and that is a real build case.
3. If we build it, who owns it in year three? Name the person. If you cannot, you have found the failure mode that retired our build server.

The takeaway

We are not going to tell you that building software is a mistake. We built a time tracker and it became our product. We built a CI setup and it became a liability. The effort was similar. The difference was whether anybody else had already solved the problem well.

For time tracking, somebody has. It costs $0 for unlimited users, and you can start using it today instead of scheduling the kickoff.