Give every project a budget (and let it end)

The projects that hurt are rarely the ones that blow up. They're the ones that drift. A retainer that's been "nearly done" for four months. A fixed-price build where the last 10% of scope ate 40% of the hours, and nobody priced those hours until the invoice didn't cover them. The overrun wasn't hidden, exactly. It just lived in a spreadsheet nobody opened until it was too late to matter.

Clocktopus always knew where the hours went. What it didn't know was money. This release adds it: rates on job roles, budgets on projects, and margin somewhere everyone actually looks.

What we shipped

Job roles now carry two hourly rates: what you charge for that role, and what it costs you. Members inherit the rates of their role, so pricing a person is just a matter of giving them a role.

Rates are effective-dated. Raise a rate from the 1st of next month and every hour logged before that keeps billing at the old rate. History never gets quietly rewritten. If you genuinely need to fix the past, that's a separate, explicit correction, and it's recorded in an audit trail.

Projects can override a role's rates. Agreed a discount for one client, or a premium for an urgent engagement? Set the override on that project and leave your org-wide rates alone. Overrides are per role and effective-dated too, and if you only override the sell rate, the cost rate still comes from the role.

And projects can now have a budget: a single amount in your organisation's currency, with an optional margin goal beside it. A budgets report under Reports shows consumption, cost, profit and margin per project, and the dashboard got a widget the whole team can see.

The full mechanics, including a worked example, are in the rates and budgets docs.

One budget, one project

We made a decision here that will annoy some people: a project gets exactly one budget, for its whole life. No monthly budgets, no periods, no top-ups.

That's deliberate. The moment a budget can be extended, it stops being a boundary and becomes a record of whatever you happened to spend. Everyone has seen the project whose budget was revised upward three times, and each revision felt reasonable on the day. The number at the end described the past. It never constrained anything.

So when the money runs out and the work hasn't, the honest move is to close the project and open a new one, with a new number that someone actually agreed to pay. "Phase 2" is a new project. A second budget means a second project.

This pushes you toward projects that are short-lived, and I think that's the point. A six-week project with a fixed budget can only go so wrong before the numbers force a conversation. A two-year project with a rolling budget can be underwater for eighteen months while everyone stays busy. Small, bounded projects also give you something long ones never do: a stack of finished examples to check your next estimate against.

Margin is the earlier alarm

A budget on its own only tells you when you're out of money, and by then the conversation is unpleasant. The margin goal is the earlier signal.

Set a target margin and Clocktopus compares it against the actual margin, computed from your cost rates, as the hours come in. A project's health isn't just "how much of the budget is gone". You can be 60% consumed and still in trouble, because the mix of people doing the work turned out more senior and more expensive than the estimate assumed. Health tracks margin against the goal, so that project shows as below goal while there's still time to change who does what.

One detail I care about: if some hours can't be priced, because a member has no job role yet, the project's health becomes "unknown" rather than a confident green. A number built on unpriced work is worse than no number, so we won't show one.

Patterns for software houses and sole traders

A pattern I use myself: one organisation per client. Each org has its own currency, its own roles, and its own rate history, so the Australian client bills in AUD at their rates and the US client in USD at theirs, and neither ever sees a number that belongs to the other. Switching org switches the whole commercial context.

If separate orgs are more than you need, project rate overrides get you most of the way inside one org. Keep your standard rates on the roles, then override per project for the discounted retainer or the premium rescue job. Because overrides are effective-dated, a mid-project rate change starts on the day you pick, and everything billed before it stays exactly as it was.

The whole team sees where the project sits

Budgets fail when they're a report one person reads monthly. So the dashboard widget shows the five projects with the thinnest margins first. Its job is to surface the problem you weren't looking for.

Who sees what is decided on the server, per project. Owners and admins see the figures: consumed against budget, cost, profit. Regular members see the percent used and the health label, and no money at all. That split matters. A developer who can see the project is at 90% of budget makes different choices about that nice-to-have refactor, and they don't need to know anyone's rate to do it.

Try it

Open a project's settings, turn on the budget, and set a margin goal if you have one. Give your members job roles under your organisation's settings so their hours get priced. The docs walk through the details, including how effective-dated rates and overrides resolve.

Then let the widget do its job. The first time it surfaces a project you thought was fine, you'll wish you'd had it a year ago. I did.