Fixed Price Projects - Are They Really Better For The Customer?

The scenario here is a common one - a customer requests a fixed price quotation from a provider. In theory, this sounds like a great approach from the customers perspective. They know exactly how much they will need to spend in advance and can compare this information with quotes from other providers to get the best deal.

Simple and relatively risk-free for the customer, right?

Well, not necessarily.

Whilst it’s true that very simple projects could be well suited to a fixed price billing model, in the world of custom web development, fixed prices (hand in hand with fixed scope) for larger or more complex projects can often be surprisingly detrimental to the customer, in more ways than one.

Let us explain further...

Problem #1 - Most customers don't know exactly what they want or what they should do.

Few and far between are customers that create a well-planned, watertight specification up-front, leaving no stone unturned, no ambiguity and including provision for all technical & design considerations, system integrations and the like. Web development projects can be incredibly complicated beasts and require a lot of specialist technical knowledge so it’s certainly not a reflection on the customer when a full spec isn’t forthcoming.

Unfortunately though, without such a spec to work with and, therefore, not enough information to actually price up, it’s quite a leap to assume that the provider will be able to provide an accurate fixed price.

Sure, there’s the option to commission the provider to conduct a separate research, discovery and planning phase and, where the customer is happy to do so, this is a great idea and can iron out a lot of the creases. Some customers, however, might draw the line at spending more money on these activities alone.


Without a full specification to work from, the only way for the provider to produce a fixed price is to take a best guess based on previous experience. This clearly places most of the risk with the provider which, in itself, isn't necessarily a problem. To mitigate this risk, however, the provider may have to err on the side of caution when determining the price and, by the end of the project, the customer may have been much better off, financially-speaking, on an hourly-rate billing model.

In some cases it may be possible for the provider to work backwards instead and provide a quotation on the basis of 'this is the solution that we could implement within your budget of £xxx'. However, many customers are unwilling to discuss their budget up-front for fear of being taken advantage of. As an honest provider, we only ask the budget question to help plan the most feasible and most suitable options for the customer, not to work out how much money we can squeeze from them. We know that's not the case with every provider though, which is a great shame.

Of course, some customers do provide amazingly well-constructed specifications but this, in itself, can lead onto:

Problem #2 - Requirements ALWAYS change

Customers always know what they want (and what they don't) once they see it. Comprehensive specification or not, it’s almost a given that once a tangible feature is released to the customer, the customer will require changes. In almost all cases, this isn’t because the original requirements were incorrect, but because there is no substitute for using the real thing to determine how to improve it. At the extreme, we’ve seen several instances where the customer has been given access to an early implementation of some key features and radically altered the remainder of the project scope based on this valuable insight.

Certainly, the customer may agree for the provider to include a ‘contingency' budget to allow for some minor changes but this will only go so far. In itself, the contingency budget has a finite limit so it’s possible that the same issue may still occur, just slightly later. The customer may also agree to incur additional costs for all changes. When put in place, this solution works very well for both parties but, for the purposes of an article on fixed price projects, it somewhat defeats the object.


When changes are required, someone (or something) must pay for them. By ‘someone’ we mean that either the customer pays the extra or the provider swallows the cost. By ‘something’ we mean that a change can also be ‘paid for’ by a reduction in overall product quality (read: spending less time in other areas) or by sacrificing other features that require a similar amount of effort to implement. Reducing quality is never a good idea and if the customer isn’t willing to part with ‘feature x’ in order to include ‘feature y’ then we’re back to the likely outcome of the customer having to stump up the extra cash.

Problem #3 - Some customers won’t understand the impact of a change

This is very common and, again, is no reflection on the customer. They have commissioned the specialist provider to do the work so the customer isn’t expected to understand the work involved.

Take, for example, a customer request to add a ‘language selector’ to a web page. The request is summed up in 8 words and sounds like the simplest of updates. The customer would be forgiven for assuming a few hours at the most.

From a development point of view this ‘simple’ update may require:

  • A complete rewrite of the web page in question to replace any ‘static’ text with a placeholder that can dynamically pull in the selected language(s)
  • A restructuring of the database to include the translations for each bit of text of the page
  • An update to to the Content Management System to change how content is applied to the page
  • And finally we get round to creating the language selector that the customer asked for in the first place


It’s clear to see that this seemingly simple update could actually take a day or more to implement. No one would expect the customer to know what goes into implementing this feature but when this becomes just one of many ‘simple’ changes as part of a fixed price project, you can see how these can really affect the project roadmap as a whole.

Problem #4 - Drive down price = drive down quality = drive down the whole point

In custom web development circles, you really do ‘get what you pay for’. Again, we’re not talking simple websites here although the same is likely true. We’re talking about complex websites and software applications. ‘Company A’ may provide a lower fixed price than ‘Company B’ and ‘Freelancer C’ says that they will do the work for a pound and a mars bar. So the choice is obvious right? Well maybe, when price is the only or overriding factor. But, 9 times out of 10, driving down prices means that something will suffer and given that time=money and money=time, what will likely suffer is the quality of the end product and, subsequently, the customers pocket when paying for later changes, patches and upgrades.


Price is important, of course that’s true but, sadly, many customers overlook the organisational criticality of the proposed product and indeed the potential RoI, opt for a low fixed price and ultimately find the decision proved a false economy. If quality matters to the customer (and it should if the product is important to them), price really needs to be balanced with other key factors. Those factors are numerous and may be more suited to a future post but the main one has got to be quality. If the end product is untested, unstable, insecure, un-future-proof (we know that’s not a word but you get the idea), maintainance-heavy or unappealing to end-users then you’d have to say that the whole point of the product is lost, along with the original investment and any potential benefits.

Example Scenario #1

  • Specification produced by customer
  • Fixed price of £20,000 agreed (lets say this is based on 40 days labour)
  • Development commences
  • Customer changes the scope of a feature
  • It is determined that the change would require an additional 4 days labour (or £2000)

There are 3 possible options here:
1. The customer accepts that they will incur the additional £2000 for the change.
2. Some other feature(s) requiring similar labour will have to be sacrificed to allow for the change.
3. The change gets included at no additional cost but overall quality must reduce to keep within 40 labour days.

It could be argued that there is a fourth option, which involves the provider taking a significant and unexpected hit:
4. The provider agrees to include the change at no cost and at no detriment to the product quality.

Option 1 is the most sensible yet somewhat defeats the object of the fixed price model.
Option 2 is a fair compromise but results in a loss of potentially useful features from the final product.
Option 3 is not recommended as it results in lower end-product quality and will likely result in the customer paying for patches/fixes at a later date.
Option 4 is fine so long as the provider isn’t too keen on operating a viable business model.

Example Scenario #2

  • No specification produced by customer (or just a rough outline supplied)
  • Provider produces a Work Statement that includes many assumptions through lack of information
  • Fixed price of £60,000 agreed (based on a best guess of 120 days labour)
  • Development commences
  • As the project begins to take shape, the customer realises that what they actually had in mind is somewhat different to the assumptions made in the Work Statement
  • It is determined that a further 40 days of labour would be required to achieve what the customer actually wanted and some of the functionality already developed will need to be removed

There are 2 options here:
1. As the provider was working to the agreed Work Statement, the customer accepts to pay for the changes.
2. The provider agrees to include the changes at no cost to the customer.

Option 1 is the right approach from a legal standpoint yet the customer may not feel too happy.
Option 2 was almost omitted entirely as adding 40 days of labour to a 120 day project at no cost could be catastrophic for product quality and/or the providers profit margin.

What is the Alternative?

To ensure a true, fit-for-purpose end-product of the highest quality, the best solution, in our opinion, is to adopt a time-based hourly or daily rate billing model. But before deciding that this article is now simply promoting the message - ‘just do everything at hourly rate’, please read on as it’s not quite that simple and can actually be a good thing for both parties.

The hourly rate model is certainly one that often invokes a sceptical reaction from customers and with good reason. After all, mindlessly ploughing through an open-ended project, hour after hour, day after day, can certainly result in projects exceeding their estimates and leave customers footing a hefty bill. That would be the wrong way to go about things.

There is, however, a right way - one that benefits the customer, the provider and most importantly, the end product. That way is to use an Agile approach to the project.


Agile is actually a Project Management approach, all about delivering the most valuable features of the project as quickly and as frequently as possible during the project lifecycle rather than delivering large chunks of functionality infrequently or all in one go at the end. If you've never heard of Agile, you may have heard of SCRUM, which is one example of a framework that can be used to apply Agile to a project.

In a nutshell (and in our agile way of doing things), the customer works closely with the supplier to define the broad requirements of the project at the outset.
The highest priority / most valuable / highest RoI requirements are put at the top of the list, defined in more detail and are estimated in terms of required labour by the supplier.
The supplier includes the top priority requirements in an agreed single package of work, commences on the development and rapidly delivers the features, enabling the customer to confirm satisfactory completion, provide feedback and consider any subsequent changes to the remainder of the project scope based on the current feature set and budget.
The remaining (and potential new) requirements are re-prioritised and the process starts over, again and again and again until the project is completed.

More and more organisations are starting to realise the benefits of Agile development, including the UK Government, who have published their guidelines on how their web-based products and services should be approached as part of their Digital by Default Service Standard.

So, what about pricing?

Investment in an Agile approach to a project is as much about a new mindset and mutual trust as it is about pricing. In our case, as the supplier, what we want is a really great ‘portfolio-worthy’ end product and a happy (and hopefully repeat) customer.

What the customer wants is a really great end product and a good working relationship with the supplier. With this in mind, there is little benefit for either party to take advantage of the other. The relationship would suffer, so would the end product and nobody really wins. Agile relies upon, and conveniently facilitates, good communication so a strong working relationship is a must.

Taking the time to properly discuss the Agile approach most often results in peace of mind, a mutual drive for a great product and an understanding between supplier and customer that neither is out to deceive the other and what everyone actually wants is for the project to be done, done well and done as soon as possible. We touched on the idea earlier, but it’s true to say that in many cases, projects conducted under an hourly rate, Agile model can result in a lower financial outlay for the customer than through the fixed price alternative.

Through the use of Agile:

  • The supplier can still provide the customer with a project estimate up-front to reduce uncertainty
  • The customer is empowered to help ensure that their own budget isn't exceeded by continuously prioritising the most valuable features, leaving those 'nice-to-have' features until later - if budget allows
  • Change is handled well through the ongoing cycle of planning, refinement and feedback
  • Detailed planning activities can be limited to the ‘next set’ of high priority features rather than planning everything (even requirements that might change by the time they come up) at the beginning.

On the other hand, Agile doesn’t completely eliminate the idea of fixed prices.

For those customers who still prefer the security of fixed price and are accepting of slightly less flexibility, fixed prices are indeed possible here through the use of a 'fixed price - variable scope' model. By defining and prioritising the broad project requirements in advance and adopting an Agile approach to project delivery, we have been able to produce fixed prices with scope-flexibility built-in.

One option is to spend more time to define and price up the whole project early on (sure, a separate discovery phase would still help here) but a better, more flexible option is to plan out and provide a fixed price for a single smaller package of work, deliver it, plan & price up the next package of work, deliver it, and so on.

In either case, it may be the true that, due to these fixed price constraints, every single feature that was thought up at first doesn’t make it into the final product but surely that’s a good thing. It’s all about priorities and ultimately, the features that did make the cut were actually more valuable, or, due to the ability to change/replace/remove features in the scope, a significantly better alternative.

In Conclusion

We’ve established that fixed price, fixed scope projects do have their place, most commonly with short, simple projects with well defined requirements that are unlikely to change.

When applying the same principle to large or complex projects, the likelihood of issues with quality, scope, cost, time and even the customer-supplier relationship increases significantly.

In our experience, taking an Agile approach to project delivery and spending the time to build trust and understanding with the customer really helps to ensure that an ‘hourly rate’ or even ‘fixed-price variable-scope’ billing model can be much more beneficial to both parties and, most importantly, the end product.

Ultimately though, any successful project relies on great communication, regardless of billing model. If both parties are open, honest and forthcoming up-front then there’s a lot less room for ambiguity, argument and issues later on. The customer who holds back on specifics to try and slip in those extra ‘free’ features after a price has been agreed or the provider who secures a new bespoke CRM project by providing a quote of 1 day and a cost of £10 + VAT, knowing full well that they’ll argue with the customer about EVERYTHING once development begins - these are the scenarios that can cause issue upon issue and finish up with questionable end products and broken relationships.

Custom development isn’t easy but it certainly doesn’t need to be a pricing minefield.

We would be really interested to hear your feedback and experiences with fixed price or other alternative pricing models so please feel free to join the discussion.

The salesy bit

At Hallnet, we've been working on custom web development projects for our clients since 1998. If you are interested in exploring your project options (including approach and pricing) then please feel free to get in touch.