We've had a lot of calls recently that all ended up boiling down to the same question. "How many hours is that?", or "How long will it take at your hourly rate?". This is the pricing model like...80% of agencies work off of. We want to work differently. And I think it's worth explaining why, because it's not a gimmick. It's not us trying to be clever about packaging. It's that we genuinely think the standard models create problems that nobody benefits from.
Hourly billing sets up a weird dynamic from day one. Your shop is now incentivized to take longer. Not because they're bad people, not because they're padding invoices, but because the model itself rewards inefficiency. If a senior engineer solves your problem in two hours instead of ten, they just lost eight hours of billable time. Nobody's doing that math consciously, but the incentive is sitting right there under every decision.
On the client side, hourly turns every conversation into a negotiation. You start asking "is this really going to take that long?" and your dev team starts defending their estimates instead of focusing on building the right thing. And after a few rounds of that, the relationship starts to feel different. Less like a team, more like a vendor you're auditing.
Fixed-bid sounds like it solves this. You know exactly what you're paying, the scope is defined, everyone agrees up front. Except it doesn't work either, because software doesn't work that way. The scope always changes. It should change, because you learn things once you start building that you couldn't have known during the proposal phase. Under a fixed-bid contract, every scope change becomes a change order, which means another negotiation, which means you're right back to that adversarial dynamic where the shop is protecting their margin and you're wondering if you're getting squeezed.
And here's the thing nobody talks about. If we come in under budget on a fixed-bid, we're incentivized to charge you the full amount anyway. We scoped it, you agreed to it, and we'd lose money for being efficient. If we go long because the problem turned out to be harder than we thought, we eat that cost, which means we start cutting corners to stay profitable. Neither outcome is good for you, and honestly, neither one is good for us either. We see this constantly when teams underestimate what software projects actually cost.
So what do we do instead?
We work on a fixed monthly engagement. A predictable number that doesn't change based on how many hours we logged on Tuesday. We define the outcomes we're working toward each month, we ship against those outcomes, and we move forward together. We talk more about how that's structured, but the short version is: you know what you're paying, and we know what we're building toward.
If we're efficient and knock out a feature in half the time we expected, we don't sit on our hands for the rest of the sprint. We pull the next thing forward. You get more value for the same monthly investment, and we get to keep building without watching the clock.
If something takes longer because it should, because we found a better approach, because your users are telling us something we didn't expect, we have room to do it right instead of shipping something half-baked to stay under budget.
I'm not going to pretend this model is perfect. It requires trust on both sides, and that trust has to be earned. We've had engagements that started fixed-fee, shipped something real, and then moved into a more flexible arrangement because both sides had proven themselves. That evolution is kind of the point. The pricing model should grow with the relationship, not constrain it. At its best it starts to feel less like a vendor arrangement and more like we're just part of your team.
What I can tell you is that the monthly model is where I actually like working with my clients. We're not tracking hours against each other, we're not fighting over change orders, we're just...building the thing. And that's the whole reason House of Giants exists.