Fixed Price or Bust
It’s worth acknowledging that anyone who hires a professional to build a web application (me, for example) is taking a sizable risk: for a sizable amount of time and money, they will get an end product that doesn’t yet exist, the description of which itself is subject to ambiguities, misunderstandings, and mistranslations, and the implementation of which is often fraught with surprises and complications.
To mitigate this risk, a professional can (and in my opinion should) take a risk themselves: to deliver the system as specified for exactly the agreed upon price.
How could that be considered a risk?
Most web applications are inherently complex, and a large portion new applications consist of one or more novel problems to solve. Both complexity and novel problems contribute to the likelihood of unforeseen gotchas, surprises, and challenges, and guesswork is accordingly injected into estimating the time and money involved.
Therefore when a professional gives a price, it’s an assessment of how much work a project will take that is made without the luxury of hindsight. Saying something like “you know that thing I said would cost $800? Yeah, turns out it’s harder than I thought and so it’s going to be $400 more.” to a client is an admission of a failure in making this assessment.
“Fixed Price or Bust” is the model I subscribe to handle this risk: I learn what I need to about the project, estimate the complexity of each segment, assign appropriate prices for each, and then for each segment, one of three outcomes will result:
- Nailed it. All went according to plan: I complete the segment within the time that I’d estimated, and all is well.
- Stumbled. It was harder than I thought: I got it done and on time, but not without sacrificing extra hours dealing with curve balls I failed to foresee. I lost some time but gained some learning, and it looks just like the first case to my client.
- Bust. It was much harder than I thought: so much so that I need to let my client in on the problem(s) that have arisen and given them options. This step constitutes reorienting to reality in light of new information and experience, because the estimate in this case has proved be wildly inaccurate/optimistic, and I take as much responsibility as I reasonably can: either we renegotiate the time line and/or cost, revise the approach somehow, or we drop the segment outright and I eat my time already spent.
Bust represents an occasion where a client is saddled with the uncertain complexities of software development, something we web professionals are hired to abstract away as much as possible. Accordingly it should happen as rarely as possible. In my 4 years of freelance web development there was only one time that I busted.
Fixed Price or Bust creates a responsibility on the side of the professional that I think goes a long way to support clients and foster trust in the process. It puts the onus on a professional to accurately assess the complexity of a project. They have strong incentive to get it right, and a strong disincentive to get it wrong. If a segment of work turns out to be harder than anticipated, Fixed Price or Bust nearly ensures that the situation remains their problem, and not the problem of the client. Working faster for a fixed price both increases the profitability of a professional as well as gets a client a completed project sooner. It’s a great alignment of priorities.
Next: Pretty Software for All
This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.
in case of Bust, what if the customer sues you to deliver what was promised at the original price?
Great question! It’s never happened to me so I’ll have to do my best to answer hypothetically.
If that drastic of an action was taken by my client I reckon I would buckle instantly and just do the work. It’s just the rational thing to do, because you should never bust so hard that the expense of just doing the work comes close to the time and energy you would expend being involved in a lawsuit (I’m guessing).
There’s a check and balance against this being initiated willy-nilly, though, which is key: if it comes to that then the relationship going forward is toast and a client will almost certainly recognize that.
That means no more working together, and if you’ve done a good job cultivating the relationship and being a trusted, reliable and valuable asset for getting programming work done, that loss is in most cases entails big negative impact for your client (because holy crap is it hard to find good, trusted talent to do your job right). If you are so disposable to your client that they would sue you over such a situation, in my book you’ve already failed to play the game powerfully up to that point. (In other words: there’s great room for you to be a more awesome programmer for hire in the future, and such a scenario offers you a great lesson in what you might’ve done differently.)