A chef who doesn't know what a plate of risotto costs won't survive three months. In the restaurant business, this isn't a metaphor—it's economics at plate level. Restaurants calculate their food cost percentage per dish, down to the cent. Every ingredient is tracked, every gap between planned and actual costs triggers a correction. Skip that discipline, and you end up with a packed dining room and an empty bank account.

IT agencies are essentially in the same business—selling labor in portions. The difference is that most of them have no idea what their portions actually cost. "Roughly 70 percent utilization" is the agency equivalent of "the risotto will probably work out fine."

60 Hours Per Year That Nobody Notices

The numbers are remarkably consistent across studies: agencies and IT service firms capture only about 72 percent of their actual billable hours. Companies with robust tracking systems reach 95 percent. The gap—23 percentage points—sounds abstract.

Less abstract: 15 minutes per day that never get logged. A phone call here, a quick code review there, a Slack thread that technically belongs to a client project. Fifteen minutes a day adds up to 60 hours a year. Per person.

For a team of 10 at an average rate of $150/hour, that's $90,000 in revenue that never hits an invoice.

Here's the thing: most companies don't feel this as acute pain. There's no single moment where someone says "we're missing $90,000." It's a slow drip—like a faucet that leaks. You hear it at night, but during the day you keep forgetting to call the plumber.

One more number that stuck with me: according to an analysis cited by Accelo and Harvard Business Review, US businesses lose a combined $7.4 billion per day to inaccurate time tracking. Not per year. Per day. Those are aggregated figures across all industries, sure, but they illustrate the scale. Time tracking isn't a hygiene issue. It's a profitability issue.

Why Spreadsheets and "I'll Log It Later" Don't Work

I know the argument. We did it that way at my previous company for years: Friday noon email to everyone, "please log your hours." The outcome was predictable and still somehow surprising every single time.

The Memory Problem

Daniel Kahneman's work on cognitive bias describes something anyone who's ever reconstructed their work week on a Friday afternoon knows well: we remember peaks and endings, not the middle. The two-hour debugging session on Tuesday? That sticks. The 40 minutes of concept work on Wednesday morning? Gone. And those 25 minutes of context-switching between three projects? They simply don't exist in memory.

The PMI recommends weekly collection cycles in 15- to 30-minute increments. Not because that's particularly elegant, but because anything less frequent becomes statistically unreliable. Monthly retroactive logging is barely distinguishable from guessing.

Flying Blind on Budget vs. Actual

The real problem with retroactive time tracking isn't just inaccuracy. It's that you lose the budget-versus-actual comparison. Back to restaurants: a restaurant that only checks ingredient costs at the end of the month has spent 30 days selling dishes with wrong margins. The chef who checks food cost every evening corrects the next day.

Project time tracking should work the same way. When the budget for a feature is 40 hours and 28 are burned after one week, you want to know that now—not in four weeks when the invoice goes out.

What Good Project Time Tracking Actually Requires

Most comparison sites list features. Timer here, reporting there, integration somewhere else. That's like rating a restaurant by how many burners it has in the kitchen.

What actually matters comes down to five things—and none of them appear on a typical feature comparison page:

Project context, not hour counting. Hours that aren't tied to a project are data noise. The question isn't whether someone worked 8 hours. It's whether the 3.5 hours on Project X are within budget.

Real-time, not retrospective. Time tracking that requires Friday catch-up sessions is archaeology. The value is in the moment—in the question you can answer on a Tuesday afternoon, not just in the monthly report.

Budget vs. actual at project level. Like food cost percentage per dish in a restaurant: what was planned, what was actually spent? Without this comparison, time tracking is data collection without insight.

Built into the workflow. Every context switch between "working" and "logging time" has a cost. Not a big one—but enough that people skip it when it's inconvenient. Anyone who has managed multiple projects simultaneously knows: every bit of friction compounds.

Analytics that drive decisions. Not dashboards with colorful bars. But the answer to: Is this project still profitable? Can we hold scope? Where exactly is time leaking?

The Uncomfortable Truth About Time Tracking

I spent years thinking the problem was the tool. We tried three different solutions at my previous company before I understood: the tool was never the issue.

Why Teams Hate Time Tracking

Time tracking has a reputation problem that goes deeper than UX design. For many developers and consultants, tracking time feels like surveillance—like a punch clock and distrust. And honestly, that feeling isn't always wrong.

When time tracking is introduced primarily as a control mechanism—"we want to see who's putting in their 8 hours"—it produces exactly the behavior it's supposed to measure: people log 8 hours, distributed across projects, roughly fitting. The data looks clean. It isn't.

The Culture Shift Nobody Ordered

The companies I've seen succeed with time tracking all had something in common: they didn't ask "how do we get people to log their hours?" They asked: "what do we need to show people so they want to log their hours?"

That sounds like consultant-speak. It probably is, a little. But the point is real: when a developer sees that their project is at 85 percent budget consumption and the feature isn't done yet—that's not a control tool. That's information that helps them have a conversation with the project lead before it's too late.

A good chef wants to know their food cost percentage. Not because the boss demands it, but because it tells them whether they're doing good work. Project time tracking that functions like this—as a tool for the people who use it, not for those who evaluate it—has a real chance of becoming part of the culture.

What restaurants figured out long ago, and what IT companies are slowly learning: granular tracking doesn't just reduce costs. It changes how a team thinks about its work. Research from the National Restaurant Association shows that restaurants with consistent ingredient tracking reduce their food cost by 10 to 15 percent—not primarily because they save, but because they make more conscious decisions. The same principle applies to project hours. When you notice that the concept phase regularly consumes 40 percent of the budget despite being planned at 20, that's not a time tracking problem. That's an insight about your own work process.

1 in 5 billable hours is never recorded. The question isn't whether you're losing money. The question is whether you want to know how much.

We built Leadtime partly because we ignored this planned-versus-actual gap ourselves for years. Not because we're smarter than anyone else—but because our accountant eventually asked a question nobody had an answer to.