A better way for software developers to charge for their efforts

Sep 6, 2016

The thing that software developers do is convert time spent working on software features into software features they can then deliver. Software developers’ clients generally care only about the latter, but they often end up paying for the other. This post begins with a discussion of two extreme ways developers often charge for their services – the Time and Materials contract and the Fixed Cost contract – and offers a compromise that we believe is a better alternative to both.

First, let’s look at those two contracts.

The Time and Materials contract

The fundamental problem with the Time and Materials contract is obvious to anyone who considers becoming a client to a software developer – paying the developer by the hours gives the developer a direct financial incentive to work slowly. The longer it takes the developer to deliver the features their clients want, the greater the profit. While it’s more complicated than that – and there are other incentives in play – that basic perverse incentive is an inherent part of this contract structure. This contract structure also concentrates nearly all project risk with the client; if something unforeseen happens the client is going to bear the cost of any extra time.

The Fixed Cost contract

The Fixed Cost contract sounds like an ideal solution to this problem – the client defines what they want, the developer tells them how much it’s going to cost, and when the software does what it’s supposed to they pay what they agreed… except, it’s not actually that simple, for quite a few reasons.

Describing what you want is hard, and takes a lot of time - the more detail you go into, the more detail you start to see and the longer you spend trying to define the job the larger the job starts to look. This isn’t the most efficient way of discovering that extra detail!

Even if you take the time to describe what you want, seeing the result often convinces you that you want something different - we’re just not very good at seeing exactly what we want before it’s in front of us. In addition, there are lots of things the client can do to help during the project… and they should have an incentive to do so.

And here lies the conundrum

The client is concerned that our incentives are counter-productive in a Time and Materials contract. We need the client for clarification of requirements, conversation about options, acceptance of our work when we ship it, and feedback on how to better it. All of this requires their time and attention, which may compete with other demands.

So, the client starts with a Fixed Cost contract and a fixed view of what they want, and they either stick with that (and ignore all of the good ideas the developer comes up with during the project), or start discussing the variations. Here the incentives are pretty awful too – the developer offers a price for each variant, and the client pretty much has to accept it (because they’re already deep in the project).

Fixed Cost contracts thus often end up either delivering what was asked for at the beginning – without any potential for incorporating ideas and learnings that arise during the process – or wasting time and effort in contract renegotiations.

We’ve found a compromise

If we cut the two classic contract forms exactly in half and add in a splash of the lean and agile software development practices, what do we get? A contract in which we estimate each software feature, multiply our estimate by our hourly rate, then call half of that number the feature completion bonus (paid only once the client is happy that the feature actually fulfils their requirements), and charge half our hourly rate for the hours we actually work.

Here’s an example

Assume for the sake of easy numbers that we charge $100 per hour (we don’t).

We estimate a feature will take 10 hours to complete, and therefore estimate it at $1000 but quote it at $500 + $50/hr. The client accepts the quote because they believe that the feature delivers them much more than $1000 of value.

If we ship the feature to the client’s satisfaction in 8 hours:

  • The client pays $500 + 8 x $50 = $900.
  • The client is happy because they paid $100 less than they expected to.
  • We’re happy because we earned $900 / 8 = $112.50 per hour – more than our nominal rate.

If we ship the feature to their satisfaction in 12 hours:

  • They pay $500 + 12 x $50 = $1100.
  • They’re not too unhappy – they pay $100 more than they expected to, which isn’t much
  • We’re not too unhappy – we earned $1100 / 12 = $92.67 per hour, which is less than our nominal rate, but not low enough that we’ll go out of business (unless we make a habit of it).

What does this do to the incentives and risks listed above?

We can’t make sufficient money on half of our hourly rate, so our incentive to bring the features in quickly is very strong. The client pays more if the feature takes longer than our estimate, so they have an incentive to help where they can.

How do bugs fit into all of this?

Within these different contracts the client has paid the developer for different things, and their responsibility to the client for any bugs in the software is different.

In a Fixed Cost contract, the client has paid for a feature, and should be completely insulated from the amount of time the developer needs to take to ship it. If the client discovers a bug after the feature has shipped, that doesn’t change – they’ve paid for the feature so it’s the developer’s job to make the feature work and the client shouldn’t be billed for that.

Cost to fix the bug: $0

In a Time and Materials contract the client has paid for some of the developer’s time. If more time is required to make the feature work then it’s reasonable that they pay for that.

Cost to fix the bug: hours worked × full hourly rate (so the contractor is earning as much for fixing the bug as they did for the original work).

If a client discovers a bug in a feature they paid for on a Shared Cost basis… well, fixing the bug is part of the time required to get the feature to “finished”, right? And they’re paying for that time… so it’s reasonable that they pay for fixing the bug, but only at the reduced hourly rate.

Cost to fix the bug: hours worked × half the contractor’s nominal hourly rate (so the contractor suffers).

This example demonstrates the logic of the different contract forms precisely, and importantly how the incentives are all in the right place – the contractor has a strong incentive to avoid bugs, and the client has a strong incentive to help where they can (with clear bug reports and fast responses to questions).

Time-tracking to support the model

In order to support this consulting model we’ve built our own time-tracking tool called Morty, that gives our developers feedback on how we’re tracking against story budgets right now and over time. We use the data from this tool to run experiments and see how they affect our performance from sprint to sprint, then pivot based on that information.

Have you done something similar in your organisation, or had success with a wildly different approach? We’d love to hear what you came up with.

<< Back to blog post listing