Stories about Software


The Billing Maturity Model

Editorial Note: I just want to mention that I realize I’ve done a disproportionate amount of cross-posting lately.  Perhaps no one notices or cares; these posts generally seem to be pretty popular.  But in case you were wondering why I’m doing that, instead of DaedTech-specific posts or answering reader questions, it’s because I’m trying to focus most of my non-paid writing on Developer Hegemony.  I’m getting into the homestretch with it. Once I finish the draft, you’ll probably see a higher ratio of DaedTech-specific posts.

Last week, I wrote a post about my experience with software consulting.  It generated some buzz and discussion, and I received a good bit of feedback from regular readers that they’d like to see more of these posts about the consulting game.  Today I’m going to oblige.

In that post, I talked obliquely about wanting to get away from hourly billing models.  The main thrust of the post was about two realizations that have been more central to my happiness (writing code at an hourly rate is a career-limiting activity and engagements of indefinite length create pseudo-employment).  As a result, the general theme of alternatives to hourly billing took a backseat.

The Challenge of Doing Something Other Than Hourly Billing

I have strong feelings about this topic, but I also view it as a larger topic and a larger hill to climb.  After all, I can keep myself happy by simply avoiding hourly coding (in favor of strategy consulting, training, and the like) and only agreeing to engagements once success criteria have been established.  Client don’t push back against these considerations.

But things tend to get more interesting when you propose arrangements other than hourly billing.  For many clients, this is befuddling and unheard of.  You might as well propose that they also start working from 8 PM to 4 AM.  Thus moving away from hourly billing requires more strategy and finagling.

In this post, I’m not going to delve into that strategy.  I mention the difficulty of moving away from hourly billing only as an explanation for why I haven’t yet eliminated it from my life altogether, the way that I have with hourly coding and open-ended engagements.

Instead, I will talk today about alternatives to hourly billing.  Some of these I’ve explored, and some of these I’m seeking to explore.  But I believe all of these billing models fall along a continuum of what I think of as a maturity model of billing arrangements.

It might surprise you to learn what I believe the differentiator is along this axis.  It’s not profitability nor advantage for the consultant.  It has nothing to do with status or business/management fads.  Rather, I evaluate these models in terms of the amount of partnership that takes place between consultant and client.


The Conception of Billing Maturity

Since my earliest days of consulting, I have viewed fixed bid arrangements as the province of the desperate.  Clients, particularly if they don’t know better, tend to love fixed bid arrangements.  In an industry where cost represents the great uncertainty, app dev shops hungry for business offer comforting certainty to win the business.

More recently, however, I’ve started to be attracted to fixed bid offerings with some of my clients.  Given how many spectacular app dev blowups I’ve seen happen between podunk firms and penny-pinching clients, this initially drove me to cognitive dissonance.  I’d long counseled anyone interested against the dangers of fixed bids.  So, what gives (gave)?

Amateur Hour: Custom Work, Fixed Bid (0)

I figured out the difference, and that difference is what led me to the idea of partnership driving the maturity evaluation.  Fixed bid as I discuss it with my clients involves them needing a solution and trusting me, with a budget, to solve their problems.  I’ll get to this billing model later in the post.

Fixed bid done badly is a different thing altogether, and what I’m referring to with the section title, “custom work, fixed bid.”  This style of fixed bid occurs when a client spends weeks or months generating an incredibly detailed “spec” document, hands it to the app dev “consultancy” and says, “build exactly this, and tell me how much it will cost up-front.”  Not only is that a sucker’s bargain, but it’s a terrible cooperation model.

One of the parties, the client, has all of the knowledge.  The other party, the “consultancy,” will do all of the execution.  In a sense, this is the same collaboration model that farmers and oxen use to plow fields – one does all of the problem solving and the other does all of the mindless labor.

But, to make matters worse, this model will inevitably lead to discord and contention.  The client has very specific ideas about an exact implementation within its domain, but little knowledge of software development.  The consulting firm has a great deal of software development knowledge, but little knowledge of the client’s domain.  The only fusion of that knowledge that happens, in advance, is the spec and the contract, upon which both parties rely for an incredibly specific prediction of the future.  Is it any wonder this will inevitably go terribly?


With this sort of model, the only question is whether the discrepancy from the initial bid will be settled amicably or acrimoniously.  Expecations will change with reality, and the inevitable, “that’s a scope change-no it isn’t” arguments will ensue. The two parties are ipso facto adversaries and unlikely to forge a relationship with any mutual trust at all.

Default: Custom Work, Hourly (1)

Next up is the arrangement that defines the overwhelming majority of software development efforts.  After all, clients feel skeptical toward fixed bids of any significance for custom work, and the firms themselves understand how such an arrangement can murder their effective bill rates.  They absorb the risk accompanying any deviation from the (quixotic) plan.

Well, the world needs software, and so if the preponderance of established app dev shops refuses to quote fixed bids for major projects, the rest of the world has little choice.  The kind of shops that do offer these fixed bid arrangements tend to be fly by night places, and it requires only one instance of getting burned with poor quality or failed projects for a client to learn.

So the client takes on the risk instead, going into the project with an estimate but a “time and materials” arrangement.  The app dev shop says, “we think it will cost about $400,000, but we can’t really KNOW that up front, so we’ll just bill hourly.  If it looks like we’re going to exceed the estimate, we’ll let you know as early as possible.”  (As an aside, I might argue that the entire business case for agile methodologies rests on mitigating this risk).

Our industry has settled into this as a standard, where the client and provider share the risk.  The shared risk brings them nominally closer together as partners, but not a whole lot.  The arguments become less “all or nothing” and more distributed over the life of the project.  Instead, they tend to take the form of “why did it take 8 hours instead of 6 to do the data migration” and “what are these 3 hours of ‘research’ for?”

Improvement: Custom, Daily/Weekly/Monthly World (2)

The nickel and dime dynamic of the default, hourly arrangement gives rise to our next level of partnership.  It’s the same basic billing paradigm, but with less granularity.  In order for this to be effective, you’re pretty much forced to fall into some kind of thin-sliced, agile delivery cadence.

Bickering over hours (or worse, quarterly hours) is a sign of distrust.  On the flip side, being willing to think about payment in increments of days, or even weeks or months, is a sign of trust.  And, for that trust to emerge between client and provider, the provider needs to have established a track record of delivering value.

Once this happens, and both parties have prospered, the need for purely adversarial arrangements and contentiousness over details melts away.  When you’re at this level of billable maturity, you’ve lapped most of the competition.

Revisited: Fixed Bid, Productized Offering (3)

As you get into the world of coarse-grained time delivery, you start to see that trading time for money is a problem in and of itself.  That necessarily creates an adversarial relationship, even if trust underpins it.  After all, buyer-seller transactions represent a zero sum game.  The more hours you bill for the same task, the more money you have and the less money the client has, regardless of the amount of value the client realizes.

I’ve started to have luck, then, with revisiting the fixed bid model for certain kinds of offerings.  Blog posts are a nice, easy-to-reason-about example.  I will write a blog post for you in exchange for $X.

In this situation, the client’s interests align with mine.  We both have interest in the delivery of a high quality blog post in as short a timeframe as possible.  Of course, we might differ on quality, and that may lead to fluctuations in the effective hourly rate, but this matters a lot more before you get away from worrying so much about money per hour (not that efficiency ceases to matter, but thinking, “this is below my normal hourly rate” is predicated upon having a normal, hourly rate).

The allure of this model, in particular, arises from the discussion of worth.  It can be somewhat arbitrary, but we’re talking about the worth of a blog post, rather than the worth of my time.  If you broaden this and apply it to software development efforts, which tend to be much larger in magnitude, the difference between this model and the custom app dev, fixed bid model becomes obvious.

In the custom model, the client lays out exactly what must be delivered.  In this model, you offer a quasi-product to the client.  The client doesn’t say, “here’s 100 pages of specs on exactly how a website should be built.”  Rather, the client approaches you and says, “I see some websites that you’ve built that are in line with what we need – what’s the price to do that for us?”  They’re relying on you not as labor, but as the provider of an established product/service, and, more importantly, an expert.

Nirvana: Value-Based Pricing (4)

Once you get used to this, the next step becomes clear.  This step is nirvana – the holy grail outlined in Million Dollar Consulting.  This is where you price your labor on the basis of the value that you provide.

I won’t go into extensive detail here (in part because I’m just starting to figure this out myself and am no expert).  But I will say this is certainly possible.

For instance, imagine that a pizza place calls you up and tells you that it wants a website through which customers can place orders.  “Why,” you ask.  They explain that they think it will increase their revenue because they’ve found data to suggest that people under 30 value asynchronous ordering more, even, than specifics of the food being offered.

Convinced, you agree to do the work.  But you don’t tell them you’ll do it for $100 per hour and you don’t tell them that you’ll do it for $10,000 because you’ve built similar sites for that amount.  Instead, you tell them that you’ll do it for nothing.

Well, let’s clarify that a bit.  You’ll do it for no standard concept of “fee” or “rate.”  Rather, you’ll do it for a cut of the profit realized from the new business model.

The client and you have now totally aligned.  You are partners.  You both have an interest in the venture succeeding, as quickly and efficiently as possible, and you both have an interest in the software making money for the business.  There is no scenario in which you say, “gosh, well, I hate that the $10,000 you owe me will put you out of business and that this was a stupid idea, but, hey, I did what the contract said.”  And, on the flip side, the client will never nickel and dime you, nor will it demand to know why you spent 3 hours doing research.

You’re both in for a penny and a pound.

Notice in this scenario that you must exercise judgment about whether writing the software makes sense (and money).  Notice that you only profit when you client profits.  The risk is extremely high for you.  But the reward is also unbounded.  If you and the client partner up to make a killing in the local pizza market, your earnings can far surpass what a software developer on the open market can ever make.

It’s No Easy Task

I’m 2000+ words in, so I’ll call it a wrap here.  But I do want to conclude by stating that I realize none of this is easy.  Hourly is easy because it’s what everyone does.

Working your way further up this ladder requires persuasion, creativity, persistence, and probably a bit of luck.  I’m also finding that bolstering your reputation helps.

But keep with it and keep at it.  I think that the more of us that start doing this and start figuring these things out, the better our lives will get as software developers, entrepreneurs, influencers, and business partners.

newest oldest most voted
Notify of
Jakub Zienkiewicz
Hi Erik, Great post, I agree with pretty much all the points. But I do have doubts about the “nirvana” model. It all sounds great in isolation, but I’m not sure it would work for many clients if they could still choose a fixed bid. If they accept the “nirvana” billing, they agree to share all the profits that come from their investment with the partner. They might instead prefer to go with someone else and a fixed bid, so after the investment pays for itself, they get to milk the cow themselves. It reminded me of an anecdote I… Read more »
Erik Dietrich

Hey Jakub. I think you raise an excellent point. It may indeed not fit with every company’s business model or preferences to offer an equity stake in a venture; they may simply not want that, and have valid reasons for not wanting it. I do think, however, that it does create the best relationship with the consultant if they’re willing to do it.

David Lormor
Nice article! While I’m not doing full-time consulting, I spent some time at an agency, where most of our work was billed at an hourly rate (at least for internal purposes – many times that’s how an estimate was gathered on fixed bids). It always seemed to end with upset customers (“this isn’t what I wanted” or “you mean I have to pay for these extra things I’ve asked for???”), anxious account management (trying to keep clients happy and developers from arguing), and frustrated developers. So, I ended up giving this a lot of thought during my time there. I… Read more »
Erik Dietrich
It sounds like we have a good bit in common 🙂 The partnership model of value billing is something that I’m still trying to arrange and test drive, though I’m getting better and better at conceiving of how I might present it on a given project. The book, Million Dollar Consulting really does offer some fairly tangible thoughts on how to chase that (compared with a lot of people I hear that just kind of hand-wave at it) There is definitely the “will the client really want to keep cutting checks a year from now” concern, but I think between… Read more »
David Lormor

Cool – looking forward to hearing more about your experiences with these experiments. I grabbed the Million Dollar Consulting audiobook right after reading this 🙂 looking forward to listening on my commutes next week.

Gaëtan Voyer-Perrault
So I have been at companies that successfully bill for “value”, in fact, the whole “as a Service” model is all about billing for value. In many ways, your pizza example is really just the “as a Service” model. They pay a share and you take a cut and everyone keeps doing their jobs. The challenge with this model is that it doesn’t grow very well. Take the classic example of Shopify. They make it easy to start up a small online shop, but they take a cut of every sale. When the small online shop becomes a big one… Read more »
Erik Dietrich
That’s an interesting point (about the “we take a cut” service model). I feel like, with a “consulting” arrangement that goes along these lines, there’d have to be a cap or end date of some kind. In other words, “I’ll build you this thing that saves you hiring 2 full time employees and you pay me the salary of 1 of those forever” might seem great to both parties initially, but the one paying “forever” would eventually view this as onerous, long after the deed was forgotten. So, perhaps it’s a matter of agreeing for X years or offering a… Read more »
Gaëtan Voyer-Perrault

“I’ll build you this thing that saves you hiring 2 full time employees and you pay me the salary of 1 of those forever”

It becomes a problem when the competition does the same thing but makes a better deal. Now both companies have saved 2 employees, but one of them is paying for 1 employee and the other is paying for 0.5 employees.

The marginal added value is always going down as competition heats up, so at some point the cost of the contract needs to match step.

Peter Verco

Nice thinking Eric, but your model creates additional problems beyond the high lifetime cost.

Either the equity or profit percentage models can be easily manipulated by the purchaser to guarantee you are paid nil, nada, zilch. The best way to avoid the most blatant methods is to use a percentage of sales instead, but negotiating that could be contentious.

The best model I have found is to package the work as a product / commodity as on your website example, and use frequent hourly billing preferably linked to agreed milestones for the rest.