What Happens When Time Tracked Isn't Time Billed?

Broken enough to rebuild, not patch.

The existing time tracking, approval, and billing flow was broken enough to earn a near-complete rebuild instead of a UI refresh. People had built real workarounds just to get their time entered and billed correctly, and at any given step, roughly half the information on screen had nothing to do with the task at hand.

The rebuild itself wasn't a hard sell. Engineering wanted it just as badly, the system was intensely broken on their end too, and that shared frustration made it easy to get buy-in for a full rebuild instead of another patch. Mobile responsiveness was a clear gap from the start as well: enough people were asking for a mobile-friendly experience that I could point to real, specific demand, which got me buy-in and more resources allotted to build it in from day one.

Time tracking, approval, and billing aren't three separate features. They're one continuous journey, touched by four different roles: the person logging time, the approver, the biller, and whoever's client-facing on the invoice. I treated it as a systems problem from the start, because a redesign that only looked better at each individual step would have fallen apart the moment those steps had to hold together.

Mapping the whole journey before touching a single screen.

Competitive research against Harvest, QuickBooks, and others showed which patterns were standard and where our product was diverging without a good reason. Then I talked to the people actually living in the current system: what they relied on, what was missing, and what they'd fight me to keep if I tried to redesign it away.

From there I mapped the full journey end to end, time entry → approval → billing → invoicing, and traced every role that touched the data at each stage. That journey map became the backbone of every decision that followed. A single-screen redesign would have missed how a change at one stage rippled into the next.

Time tracked is not the same thing as time billed.

The most important thing I learned didn't come from a support ticket. It came from watching how billers actually worked: time tracked is not the same thing as time billed. People logged their hours as a reference point, then billers routinely adjusted those numbers, sometimes significantly, to reflect what they actually wanted to invoice. Any design that piped tracked time straight into billing as a 1:1 input would have been quietly wrong for a large share of real use.

That meant the data model needed to treat tracked time and billed time as related but separate entities, not one flowing automatically into the other. I worked closely with developers and information architects to make sure that distinction held up structurally, not just on screen. It's the kind of decision that's invisible in a screenshot and fatal if you skip it.

A B2B product with real engineering constraints.

• Features shipped at different rates. Approval got pulled from an early release and re-added later. Because the flow was built modularly instead of as one rigid sequence, it slotted back in clean, no rework.
• No mobile app existed yet. Real, vocal demand for a mobile-friendly experience is what got me buy-in and more resources to build for mobile and desktop together from the start.
• The design system grew with it. Supporting mobile meant new mobile components, built carefully enough to extend the system rather than become a one-off exception to it.