The short answer: Yes, you should track time on fixed-price projects. Not to bill the client by the hour — but to know whether the project is profitable, detect scope creep before it erodes your margin, and build accurate estimates for future bids.
Fixed-price contracts create a specific trap. You quote a fee, deliver the work, collect payment, and assume you made money. But without time data, you have no idea whether that project earned you a 40% margin or cost you 20 hours of unpaid labour. The profitability of a fixed-price engagement is invisible until you track it.
This guide covers why time tracking matters on fixed-fee work, what to track, how to use time data to detect scope creep, and how to turn historical data into more accurate future bids.
Why Track Time on Fixed Price Projects?
The instinct on fixed-price work is to stop tracking once the quote is signed. The client does not need an hourly breakdown. The invoice is already agreed. So why add the overhead?
Because you are running a business, not doing favours for a fixed fee.
You are tracking for profitability, not billing. The question is not “how do I charge the client?” It is “did this project make money, and would we take it again?” You cannot answer that without knowing how many hours went into it.
Underestimation compounds silently. A project that runs 20% over your estimated hours looks fine on the invoice. But over ten similar projects, that 20% consistently erodes your margins without a single visible billing dispute. Time data makes the pattern visible.
Scope creep is invisible without evidence. When a client adds requests mid-project, the hours go somewhere. Without tracking, you absorb those costs as goodwill and carry the resentment quietly. With tracking, you have a documented case for a change order conversation: “We estimated 40 hours for this phase. We are currently at 62 hours. Here is a breakdown of the additional requests we absorbed.”
Historical data drives competitive pricing. Agencies and dev shops that win consistent work at good margins are not guessing on estimates. They are applying real cost data from past projects. That data only exists if you tracked time on those projects.
A 2024 survey by the Project Management Institute found that 37% of projects experience significant scope creep. On fixed-price work, every one of those hours is a margin loss with no recovery mechanism unless you can document and escalate it.
What to Track on a Fixed-Price Project
The goal is not comprehensive employee monitoring. It is understanding where effort goes relative to your estimate. That requires categories, not minute-by-minute logging.
Track by project phase:
- Discovery and scoping
- Design and architecture
- Development
- Testing and QA
- Deployment and handoff
- Client communication and meetings
Track by deliverable when possible. If you estimated 12 hours for the checkout flow and it took 24, that is specific, actionable information. If you know only that the project took 180 hours instead of 150, you cannot improve your next estimate.
Capture non-billable overhead explicitly. Internal meetings, rework from your own errors, and process overhead are real costs. Separating them from direct project work gives you an accurate picture of what it actually costs to deliver.
Tag scope-creep work separately. Create a time category for out-of-scope requests. When a client asks for an addition outside the agreed deliverables, log it specifically. This does three things: it builds the evidentiary record for a change order conversation, it isolates the cost impact from your original estimate, and it gives you data on how much informal scope creep you typically absorb per client.
Keep the category structure lightweight. Five to seven time categories per project is enough. Anything more complex becomes a barrier to consistent logging and you end up with incomplete data.
| Time Category | What to Capture |
|---|---|
| Discovery | Requirements gathering, stakeholder interviews, scoping calls |
| Design | Wireframes, architecture decisions, design reviews |
| Development | Feature building, bug fixing, code review |
| QA / Testing | Test writing, manual testing, regression checks |
| Deployment | Release prep, infrastructure, handoff documentation |
| Client comms | Emails, calls, Slack — anything client-facing |
| Out-of-scope | Anything added after the SOW was signed |
Detecting Scope Creep with Time Data
Scope creep rarely arrives as a single dramatic request. It accumulates in small increments: a tweak here, an extra feature there, a “quick addition” that takes four hours. By the time it is visible as a problem, you have already absorbed the cost.
Time tracking makes scope creep detectable in real time rather than retrospectively.
Set a phase budget alongside your project estimate. If your total estimate is 120 hours, break it down: 10 hours discovery, 20 hours design, 70 hours development, 15 hours QA, 5 hours deployment. Log actuals against each phase budget weekly.
Trigger a review when any phase exceeds estimate by 20%. A 20% overrun in development does not always indicate scope creep — sometimes the original estimate was wrong. But it is a reliable trigger for investigation: what caused the overrun? Is it internal inefficiency, underestimation, or additional client requests?
Use weekly time reviews to catch drift early. A project that is 8 hours over estimate at week two is recoverable. A project that is 40 hours over estimate at week six is a margin crisis. Weekly reviews with a ten-minute examination of actuals vs estimates give you the window to act.
Turn scope-creep time logs into change order evidence. When the out-of-scope category accumulates 10+ hours, schedule a scope conversation with the client. Present the data: “Here are the additions we have absorbed. Here is the time cost. We need to agree on how to handle the remaining scope requests.” This conversation is harder to have without evidence; it is straightforward with it.
Leading indicators to watch:
- Any phase running 15%+ over budget
- Out-of-scope category exceeding 5% of total estimated hours
- Client communication hours exceeding estimate (often signals unclear requirements)
- QA hours disproportionate to development hours (often signals rework)
Calculating True Project Profitability
Most agencies calculate project profitability as: revenue - direct costs (software, contractors, materials). This understates the cost of the work because it ignores internal labour.
The complete profitability formula:
True margin = Fixed fee − (actual hours × blended hourly cost) − direct costsTo use this, you need two numbers: actual hours (from your time tracking data) and blended hourly cost (the weighted average cost of your team’s time including salary, benefits, and overhead).
Calculating blended hourly cost:
Take your total annual people cost for the team — salaries, benefits, payroll taxes, equipment, and an allocated share of overhead — and divide by billable capacity.
For example: a three-person team with a total annual people cost of £180,000, working 220 days per year at 7 billable hours per day = 4,620 billable hours per year.
Blended hourly cost = £180,000 ÷ 4,620 = £38.96/hour
Applying it to a project:
A £15,000 fixed-price project that consumed 320 hours of team time:
- Labour cost: 320 × £38.96 = £12,467
- Direct costs: £850 (tools, hosting, contractor)
- Total cost: £13,317
- True margin: £15,000 − £13,317 = £1,683 (11.2%)
A project that appeared profitable at a £15,000 fee actually ran at just over 11% margin — well below a typical target of 30–40% for professional services. Without time tracking, you would never know.
Benchmarks for software agencies:
| Margin Band | What It Indicates |
|---|---|
| > 40% | Healthy; well-estimated and tightly scoped |
| 25–40% | Solid; sustainable with good team utilisation |
| 10–25% | Marginal; worth examining estimation accuracy |
| < 10% | Loss-making in real terms once overhead is factored in |
Tracking actuals across five or more projects reveals the true distribution of your margins — and usually surfaces one or two project types that are consistently loss-making despite appearing profitable.
Using Time Data to Improve Future Estimates
The long-term value of time tracking on fixed-price work is compound. Every project adds data points that make your next estimate more accurate, which makes your bids more competitive without reducing margin.
Build a project type database. Group past projects by type and size: “10-page marketing website”, “SaaS MVP, 3 months”, “API integration, single vendor”. For each category, record actual hours by phase across multiple projects. The average of five similar projects is far more reliable than a single estimate made from memory.
Identify your systematic underestimation patterns. Most teams have them. QA is underestimated because developers are optimistic about bug counts. Client communication is underestimated because it feels like “not real work”. Discovery is underestimated because clients often do not know what they want until they see it. Time data reveals which phases you consistently underprice.
Apply a correction multiplier to future estimates. If your development estimates are consistently 25% under actual across six projects, apply a 1.25 multiplier to development estimates going forward. This is not pessimism — it is calibration.
Use phase data to structure staged pricing. If you have data showing that discovery regularly takes twice the estimated time, consider pricing discovery as a separate phase billed on a day-rate. This protects your margin on the most uncertain phase while still offering a fixed price for delivery.
Automate the data collection so you actually have it. The failure mode for all of the above is not tracking consistently. Manual timesheets have a well-documented completion rate problem — studies suggest that manually-entered time logs capture 20–30% less time than actually worked. Developer-specific tools like Keito capture activity automatically from git commits, calendar events, and issue tracker interactions, giving you accurate data without depending on team discipline.
Key Takeaways
- Fixed-price projects need time tracking more than T&M projects, not less — the lack of visible billing creates invisible margin erosion
- Track by phase and deliverable, not just total project hours; granularity is what makes the data actionable
- Set phase budgets and review actuals weekly to catch scope creep at the 20% threshold, not at 100%
- Calculate true margin using actual hours × blended hourly cost; revenue minus direct costs overstates profitability
- Build a historical project database by type; across five or more similar projects, estimation accuracy improves significantly
- Automate time capture where possible — manual logging compliance is the single biggest failure point in this workflow
FAQ
Should you track time on fixed price projects? Yes. Fixed-price projects need time tracking to measure actual profitability, detect scope creep before it erodes margin, and build accurate estimates for future bids. The goal is not to bill the client by the hour — it is to understand your own costs.
How do you measure profitability on a fixed price project? Subtract actual labour cost (tracked hours × blended hourly rate) and direct costs from the fixed fee. Labour cost is the variable most teams miss because it requires time tracking data to calculate accurately.
What should you track on a fixed bid project? Track by project phase (discovery, design, development, QA, deployment, client comms) and tag out-of-scope work separately. Five to seven categories is enough — more complexity reduces compliance.
How does time tracking help detect scope creep? By comparing actuals to phase estimates weekly, you can identify when specific phases are running over budget and investigate whether the cause is underestimation or additional client requests. Out-of-scope tags create a documented record for change order conversations.
Can time tracking be automatic for fixed price projects? Yes. Tools like Keito capture developer activity automatically from git, calendar, and issue trackers, eliminating the manual logging problem. This matters especially for fixed-price work where tracking compliance is often lower because the data is not immediately needed for billing.
What is a healthy margin for fixed-price software projects? For software agencies and dev shops, a margin of 30–40% is typically the sustainable target. Below 25% and the project is marginal once overhead is factored in; below 10% it is likely loss-making in real terms.