How Should I Charge For Software Development?

The theme of this episode is centered around the lessons learned in charging for software development. Starting with a question from the Infinite Red Community, Todd, Ken, and Jamon touch on hourly vs. project pricing, the tension between time and value, how software estimating is a lot like weather forecasting, and the many experiments conducted over the years to find the right pricing model for Infinite Red.

Episode Transcript

JAMON HOLMGREN: We received a question from the community, community.infinite.red, it's a Slack community that we have. Trent asks, "Hey Jamon, I'm enjoying the podcast. Will you guys be covering hourly pricing versus project pricing? It's a question we're dealing with right now. Which do you guys prefer, and what are some lessons learned to bring you to that choice?"

I think this is a really great question. Todd, do you wanna talk about what we're doing right now? And then we can go into maybe what we've done in the past, and what brought us to that choice?

TODD WERTH: Sounds good. Yeah that's a great question, and it's actually a really tough one to deal with. So, what we do now, is we do weekly pricing. We charge per person-week, and we call it "person-week" as opposed to "a week of work" because it could actually be two people working maybe half a week each and that would be one "person-week." Because we're doing person-weeks, we have a point system. So, 100 points equals a person-week. We don't track time. We used to, and we can talk about that—we used to bill hourly. We don't track time, we don't actually know how long things take, it's just, we estimate our tasks in points, and if we've reached a hundred or more per person-week and we charge per person-week, then we're accomplishing our goal.

JAMON: There's a bit of a tension between time and value, and this has been something that we've dealt with, I mean, I've dealt with, since I started my first consultancy. Of course, value-based pricing is kind of a holy grail of pricing for consultancies, and we've heard this for a long time, that you should charge for the value, not just the time that it takes. So an example, this would be fixed-bid pricing, where you're essentially betting on delivering the software in a reasonable amount of time, but you're getting paid on the value to the client.

The problem is that our costs are not based on value. So, we're not necessarily paying our people based on the fixed-bid, a percentage of the fixed-bid, or something like that. There are industries that do that, but ours is not one of them. So we're paying people salaries, and our costs are over time, and so if something takes a very long time, then our profitability and the ability of the company to remain financially solvent is threatened.

Conversely, you have, of course, hourly. We've done that in the past, and the nice thing about hourly is that it corresponds, obviously, very tightly with the amount of time that it takes to do. But the problem is that every hour is not equal. You have hours that are maybe really valuable, you've automated something and in a lot of cases you're actually delivering more value than the client is paying for, quite a bit more. And then there are others where the person's getting spun up, or they're hung up on a particular problem, whether it's their fault or not, and that turns into a bit of an issue, because then you're billing hundreds of dollars an hour for something where the client isn't really getting a lot of value. So I think that's why we ended up where we are, in a way.

TODD: Yeah, both have issues. When you're doing hourly, it might seem to a client that's more fair, but it's not. It means every time there's a bug, or any time there's an issue, we basically are nickel-and-dimeing them, and they don't necessarily like that. We have to spin up someone, like Jamon said, where in our value system that we use now, they don't see any of that. We fix the bugs because it's part of the value of that particular feature. It does mean, though, sometimes, that we can produce a feature faster than the hourly would've been, and so they get charged, I guess, more for that.

KEN MILLER: There's a couple of different ways that hourly works out sometimes, though. There's certainly the very literal, like, you sit there and you run a clock, like the way a lawyer would, you actually have a little timer that shows exactly what you're doing. When I worked for a large sort of corporate consulting company, Big Five-style, back in the '90s, I remember my first week I was filling out my time card, and I filled in the insane hours that I worked, because that's the kind of work that you do. And my project manager comes over to me and he's like, "No no no no no no no no, this is not what you do." And he took my time card and he ...