Client Project Profit Calculator
Check after the fact whether a project actually made money at the hours it took.
A project that felt profitable often was not. This calculator compares what you actually received against the hours it actually took — including the meetings, the extra round you did not charge for, and the two months you waited to be paid — and reports your real effective rate.
What you quoted and what it took
Result
Fill in the fields above and your result will appear here.
What the Client Project Profit Calculator does
Freelancers rarely run this analysis, which is why the same underpriced client keeps coming back. The effective hourly rate is the honest measure: net revenue divided by every hour the project consumed.
Three things usually separate the quote from the outcome. Hours overrun the estimate. Extra work gets done without being billed. And payment arrives long after the work, which has a real financing cost when you are the one carrying it.
How to use this tool
- Enter what you invoiced and what you actually received. The difference is a write-off, whether it was called a discount or not.
- Enter the hours you estimated and the hours the project actually took, including meetings and emails.
- Add any extra work you did without charging. Being honest here is the point of the exercise.
- Add direct project costs and the days it took to get paid.
- Compare the effective rate against your target — if it is below 70%, that client is being subsidised by your other work.
Formula and method
Worked example
Example: ₹1,50,000 project, estimated 90 hours
| Actual hours | 128 |
| Unbilled extras | 12 |
| Total hours | 140 |
| Net revenue after ₹8,000 costs | ₹1,42,000 |
| Effective rate | ₹1,014 an hour |
| Against a ₹1,400 target | 72% of target |
The project looked like ₹1,50,000 of good work. At 140 hours it paid ₹1,014 an hour — and after a 60-day wait for payment, closer to ₹997. To hit target it should have been quoted at ₹2,04,000.
What your result means
Above 110% of target — this client and this type of work are worth pursuing more of.
90–110% — on target. The pricing model is working.
70–90% — below target. Raise the price on the next project or tighten the scope.
Below 70% — the project lost money in real terms. Either the estimate was wrong, the scope grew unchecked, or the price was too low to begin with. Identify which before quoting the same client again.
Important considerations
- Track hours from the start of every project, including email and calls. Reconstructing them afterwards always understates the total.
- Run this on every project for six months. The pattern across clients is more useful than any single result.
- Repeat clients with low effective rates are the most expensive problem in a freelance business, because they crowd out better work.
- Some low-rate projects are still worth taking for portfolio value or a referral pipeline. Make that a deliberate choice, not an accident.
- If overruns are consistent, the fix is a bigger buffer at the proposal stage rather than working faster.
Limitations of this tool
- It measures one project. Client relationships that produce repeat work at improving margins may justify a weak first project.
- Opportunity cost — what you could have earned with those hours instead — is not modelled.
- Non-financial value such as skills gained, a portfolio piece or a referral source is real but not quantified here.
Frequently asked questions
What effective rate should I be aiming for?
Should I count meetings and emails as project hours?
Yes. They are time you cannot sell to anyone else. Excluding them is the single most common reason effective rates come out far lower than expected.
What if a client is always below target but pays reliably?
Reliability has real value, and a dependable low-rate client can be worth keeping while you build better ones. Just make it a conscious decision and try a price increase — reliable clients often accept one.
How do I stop projects overrunning?
Define deliverables precisely, cap revision rounds in writing, charge for scope changes from the first one, and add a buffer at the proposal stage. Working faster is rarely the answer.