Skip to content

Writing

Why We Stopped Billing by the Hour for Software Development

We've had a lot of calls recently that all boil down to the same question: how many hours is that? Here's why we threw out hourly pricing, and what we do instead.

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 in delivery months. One fixed fee, one agreed result, one monthly review. The number doesn't change based on how many hours we logged on Tuesday, and the client isn't buying a bank of capacity. They're buying the result we agreed to and our accountability for it. We talk more about how that's structured, but the short version is: you know what you're paying, and we know what we owe.

If we're efficient and finish something faster than expected, we don't sit on our hands. We pull the next agreed target forward or record the decision about what should change. You get useful progress inside the same monthly fee, and we 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. And if we materially miss the agreed result, the next delivery month doesn't start. We finish what we owe under the prior fee.

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 monthly delivery 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, reviewing it honestly, and deciding together whether the next month should continue. And that's the whole reason House of Giants exists.