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.