Project profitability for studios: the complete guide

The studio is busy, the team is working, projects ship on time — yet profit stays unclear. The reason is almost always the same: nobody knows exactly how much each project brings in. This guide covers every part of the equation — revenue, cost, utilization, pricing, and overtime — and shows how they connect. Each section links to a deeper guide on that topic; here you get the whole picture.

Why profitability is invisible

Revenue is easy — it's on the invoice. Cost is harder: it hides in salaries, taxes, overtime, and hours nobody logged. When it's inconvenient to calculate, people don't — and they look at the bank balance instead.

The problem is that a bank balance is an aggregate. It doesn't break down by project. Profitable projects cover up losing ones, and the studio looks healthy — until there aren't enough profitable projects. Lose one strong client or take on another project like B, and the picture shifts fast.

Notice: the combined 25% margin looks acceptable. But it hides a loss on the support contract. Renew it for another year, or take on a similar one — and the loss doubles while the aggregate barely moves. Studios that watch only the total find out too late.

Two numbers that determine everything

It looks simple — but both numbers are easy to get wrong. Revenue is what's owed under the contract, not what's already hit the account. Cost is the real expense: team time at the full cost per hour, not the rate on your price list. That's where most studios slip — confusing cost with price.

Margin as a percentage matters more than the absolute figure: it lets you compare projects of different sizes. A $10,000 project at 40% margin beats a $50,000 project at 8% — the return on resources is higher. How to calculate it, what goes into cost, a worked example — in how to calculate project margin.

How to find the true cost of an hour

Take salary + employer taxes + overhead, and divide not by calendar hours but by actually billable hours. The gap between that figure and the naive "salary ÷ hours" is usually 30–50% — and it's quietly eating your margin.

A worked example. A developer on a $5,000/month salary: at first glance, $5,000 ÷ 160 hours = $31/hour. Add employer taxes (~20%): +$1,000. Overhead per employee (office, tools, HR, management): another $800. Total cost: $6,800/month. And that's not the end.

Of 160 working hours a month, only about 130 are billed to clients — the rest goes to stand-ups, onboarding, admin, and internal work. Divide $6,800 by 130 billable hours: $52/hour. That's 1.7× more than the salary suggests. $21 of every billable hour simply falls out of your estimates — when you cost from salary instead of real expense.

How to work this out precisely for your team — in the true cost of a developer hour.

Utilization: the multiplier

If only 120 of 160 working hours a month are billable, your cost per hour just went up by a third — at the same salary. That's why utilization has to be measured, not guessed.

Utilization = billable hours ÷ available hours. A healthy range for most studios is 70–80%. Below that, you're paying for idle capacity. Above it, the team has no time to sell, learn, or recover.

The 100% trap is especially dangerous: a studio with no buffer can't absorb any deviation from plan — someone gets sick, a client adds scope, a project runs long. Any event becomes a crisis, because there's no spare capacity.

The fewer team hours that earn revenue, the more each one costs. That's why the billable-to-non-billable ratio quietly sets the real cost per hour — and shapes margin on every project.

Pricing: hourly or fixed

The rule: fixed price is only safe when you know your cost per hour and have budgeted for overruns. Otherwise every overshoot comes straight out of your margin.

The difference between the models is who carries the risk. With hourly billing, the client sees every hour and can stop the work. With fixed price, you absorb all the uncertainty: if scope grows 30%, you pay — not the client.

Neither model is better in the abstract. Hourly works badly when the client wants a predictable budget. Fixed price is destructive when requirements are fuzzy or the client tends to expand scope mid-flight. A simple rule: fixed price fits when the scope can be defined exhaustively up front. If it can't, hourly is fairer for both sides.

More on when each model protects margin — in hourly vs fixed price.

Overtime: the silent leak

Go back to the table above: the same three projects, but the team logged 360 hours instead of 264 — the invoice is unchanged, the cost went up. Project A loses half its profit; B sinks deeper into the red.

Overtime for a salaried employee feels free. It's an illusion with a concrete price. If someone on a fixed project works 360 hours instead of 264, you paid $52 × 96 extra hours = $4,992 that isn't in the estimate. Plus a hidden cost: a burned-out employee works slower next month, is harder to keep, and gets sick more often.

Another trap: overtime often isn't visible until the project closes. By then it's too late to reprice. That's why you need real-time hour tracking — to catch the overrun in week two, not after handover.

Extra hours consume team capacity, and on fixed projects they come straight out of margin. If overtime isn't in the cost, your margin is a number that doesn't exist.

Seeing it in real time — without surveillance

None of this requires screen monitoring. You need just two inputs per project: hours by person and the cost of those hours.

The team logs time themselves with a one-line note — what they did, on which project. It takes under a minute and gives context no click-counter has: a developer knows that of two hours, one went to a feature and one to a client bug. An automatic tracker can't tell them apart.

The result: data that reflects real work more closely, a team that doesn't feel watched, and everything you need to calculate margin. More in time tracking without screenshots. How it works in the product — on the features page.

A simple working rhythm

• Set a price and expected hours for each project up front.
• Have everyone log time against projects as they work.
• Translate salaries and overtime into the full cost per hour.
• Track project margin continuously — act in week two, not at quarter-end.

When this works, the conversation changes: instead of "how much did we make this quarter?" you ask "which project is slipping right now?" That's a different reaction speed and a different quality of decision. Do this, and "are we profitable?" stops being a quarterly puzzle. It becomes a number you can see today. That's what AltOrbit is built for.