When I first started running my own agency, being young and inexperienced, I couldn’t understand why anyone would start a project without getting a fixed price quote.
Have you ever started filling a bucket with water, only to find there was a crack in the bottom? What’s your first response – to turn…
When a fixed price project ends up taking much longer than anticipated, the surface level thinking is the client is benefiting and you’re losing.
Why fixed price quotes are bad for the client
When a fixed price project goes south the client suffers just as much. Here are some reasons why.
Sub-par quality of development
Developers feeling the crunch start to sacrifice scalability, performance and well-structured code, in order to ship fast and get the app ‘finished’.
Instead of taking time to address problems properly (as they would do at the beginning of the project when they’re not under pressure), they’ll be forced to come up with the quickest, fastest solution.
Less oversight at the tailend
Project managers and other overseers in the agency no longer have the capacity to give your project. It’s not out of spite, nor because they’ve lost interest, it’s simply a reality that to keep the agency afloat they now need to focus on bringing in new (hopefully profitable) work to compensate for the losses their copping from your project.
This one’s a Catch-22. There’s no question it’ll be detrimental to your project’s success, but at the same time it’d be much worse for you as the client if the agency goes out of business and your app never gets finished, or you’re left without any support when it’s live.
Less craftsmanship
We can all think of examples of beautiful software that’s intuitive to use, where special care was taken to create a perfectly designed user interface.
On the flipside, we can also think of ugly, hard to use software that makes you want to punch your monitor. I’ve written more about this in a previous blog post explaining why good software requires craftsmanship:
“…software design and development is a craft, and it can’t easily be turned into a factory or assembly line style of production.”
In short, if the estimated project hours are used up, a fixed price project won’t result in beautifully designed software.
“Can’t development agencies just get better at estimating projects?”
An obvious argument to this is that development shops just need to spend more time scoping and estimating a project. If they did a better job scoping, they could provide a fixed price while ensuring the project was profitable.
Of course, if you’ve done the exact work before, then yes, you can provide a fixed price quote. But the whole reason a client is starting a bespoke development project is because that exact software hasn’t been built before.
This is where the home design and construction industry provides a great analogy — a company that specialises in lower end family homes can provide fixed prices because they’ve done the project many times and can safely factor in a buffer and profit margin.
However, if you try and ask one of those home building companies for changes to an off-the-catalogue home design, they’ll charge what seems like crazy estimates for tiny changes, or more likely even refuse your change requests. That’s when you realise you’re really after an architecturally designed home, something built to fit your exact needs and complement your building site.
Custom software development is like building an architecturally designed home, you’ll be charged hourly without a fixed price, and it only takes watching one or two episodes of Grand Designs to realise how notorious the construction industry is for overblown budgets (sometimes over triple the original estimate)!
Bespoke software development projects have hidden complexities and you just can’t foresee all of these complexities from the start. It’s the cost of building something unique and innovative.
On a recent episode of the Rework podcast, David Heinemeier Hansson, does a great job of explaining why estimating software costs up front is never going to work:
“I remember trying really hard to get better at estimating, [thinking] the problem with estimates was just that we weren’t trying hard enough [or] that we didn’t have the right scheme of doing it. If we just broke tasks down better and were more specific in our estimation, or maybe if we applied a more generous margin, we timed 1.2x, 1.5x or 2x our estimates, it would come out just right.
You might be able to accurately estimate one part of the piece you’re trying to solve, but then you forget about the five you hadn’t thought of yet that you run into. You realise, “Ooh, we’re gonna need that, aren’t we?” Because it’s novel, because it’s new, because you’re solving a fresh problem that hasn’t been solved before. You just can’t get it all there. You can’t design it all up front.
…this eventually led to our breakthrough: “Why are we trying to solve this problem that we have shown absolutely no capacity in human history of being able to solve?”
Are we really gonna be the first ones that solve the problem of estimation? Especially in software where there is a 50 year history of establishing that the industry was full of a long series of large projects that got canceled because they ran overtime or over-budget.”
— DHH, Co-Founder of Basecamp
“So if I want to create bespoke software I need to handover a blank cheque?”
As a custom software design agency we obviously want to build your custom app or software project, but nor do we think you should you be expected to write a blank cheque.
In order to make wise business decisions you need to figure out the cost, so it’s nonsensical to say, “Your app is estimated to cost between X and Z, but be prepared to pay double or triple that.”
A solution to this is taking some inspiration from Agile methodology and working out a fixed budget instead of a fixed price.
Fixed Budget vs Fixed Price Quotes
With fixed budgets, pre-project scoping is still important. Developers will need to spend some time working out estimated timelines and costs, and figuring out where the project sits in terms of overall complexity. From there, you as the client need to work out a budget that fits within your business resources based on how valuable it is to solve the problem, and how much you can invest in solving the problem right now.
Custom development on a fixed budget then requires you to go back to the original concept for your app or software product prioritise the features.
What are the big fundamental problems your app needs to solve? Those user stories become your must-have, non-negotiable functionality that need to be designed and built within your budget.
If at any point it’s discovered there are hidden complexities in software development that are putting the budget at risk for (even for the non-negotiable functionality alone), this should prompt an additional discovery session to work out how to navigate the complexity and work out an alternative way to solve it.
Once everyone is happy the core functionality is in place, the lesser important or nice-to-have functionality can be worked on and, once the budget is used up, the remaining tasks will be left off until Version 2 or beyond.
We call this feature driven development, where the critical features are released first (with the appropriate care and attention spent by designers and developers).
Featured driven development, dictated by a fixed budget, is going to give you the best odds for finishing with a successful project for you as the client. Although it may not exactly match the original scope, you get a scalable, beautifully designed software product that’s intuitive for users to use, and most importantly solves the original problem.
