Why fixed-price projects go unprofitable without breaking
I’ve seen this happen multiple times in software agencies running fixed-price projects.
A project finishes.
The client is happy.
The invoice is paid.
Only after delivery does the founder sit down and calculate what the project actually cost.
The project didn’t break at the end.
It drifted for weeks.
Small scope changes.
Senior people stepping in “just to help”.
Extra calls, reviews, fixes.
Each decision made sense in isolation.
Together, they erased the margin.
What failed wasn’t execution.
It wasn’t discipline.
It wasn’t effort.
It was ownership having the wrong information at the wrong time.
Fixed-price work gives feedback late.
By the time profitability is clear, the decisions that could have changed it are already gone.
That’s why I’m working on MarginPulse, a SaaS app for software agencies.
The idea is simple: surface early signals that a project is becoming unprofitable while the owner can still intervene.
It’s in product validation right now.
Even without the tool, one thing is already obvious to me:
if you only understand margin at the end of a project, you’re forced to react instead of decide.
Landing page if you’re curious:
https://beamer-marginpulse.aicofounder.co/
This resonates hard. Fixed-price doesn’t “break” — it drifts through tiny decisions that feel reasonable in isolation. The part about feedback arriving too late is spot on. How are you planning to capture the early signals (scope creep / extra reviews / senior “just to help”) without adding heavy overhead for the team?
I'm looking into it right now. There are issues that can't be solved with apps. For instance, logging extra work (eg: quick senior help) is essential.
I'm thinking while I'm writing, let's say some senior engineer provides this typical quick help that made sense in the moment. How come that represents a loss for the project margin if that time wasn't logged? I guess that's because the senior logs the whole day but doesn't associate specific hours with specific projects? Otherwise, if the senior engineer didn't log the hours, he loses, not the project profitability. Does that make sense?
So, if those extras are logged somewhere, it's just a matter of time. MarginPulse will add an integration to understand budget burning and warn you on time if the trend doesn't look good.
The "senior people stepping in just to help" one hits hard. That's often where the biggest margin leakage happens and it's the hardest to push back on because everyone's intentions are good.
I've found the information asymmetry you're describing is worst when the project manager doesn't have real-time visibility into who's actually touching the project. The dev lead pulls in a senior for "just a quick review" but that review turns into a half-day rabbit hole. Nobody tracks it because it wasn't planned work.
One pattern that helped when I ran fixed-price work: weekly margin check-ins where we'd ask "if we shipped today, would we make money?" Forces the uncomfortable conversations earlier when you can still cut scope or renegotiate.
Thanks for sharing! I'm glad to hear how people cope with this issue that's so common. May I ask? What do you check to make sure your projects are kept profitable? Does it take considerable time to do so?
Honestly it's pretty manual - I kept a simple spreadsheet tracking hours logged against budget for each milestone. The key numbers were: actual hours vs estimated, and which seniority levels were touching the work.
Time-wise, maybe 15-20 mins per week per active project. The weekly rhythm forced the discipline though. Without a set check-in, it's too easy to let it slide until you're already underwater.
The biggest signal I learned to watch for: when developers start saying "I'll just quickly fix this" without logging it. That's usually where the bleed starts.