Why Fixed Bids Are Bad For Clients, Too

Mason Fischer

Most software developers know that fixed bid contracts are bad for them. But what most clients don’t know is that fixed bids are bad for them as well.

Traditionally, when a client needed a piece of software built they would draft a Request for Proposal (RFP). This document would describe exactly how the software should work. They would then submit this to consulting firms or freelancers to bid on the project. The developers would bid on the project, the client would choose which shop they liked best for the price and development would begin.

Organizations of all shapes and sizes have been moving away from this process for years. The United States Government elegantly articulates in their playbook that they advocate structuring contracts to support:

  • frequent deliverables, not multi-month milestones
  • the flexibility to adjust feature prioritization as the project evolves

The RFP and bidding process was meant to serve a few purposes: comparison of price, estimation of time, and reduction of risk. This has worked well in other industries for many years which might make it seem like it would work well in the software industry as well. Unfortunately, the software industry is unique in many ways which make this process suboptimal in most cases.

Comparison of Price

Clients need a way to compare prices before choosing which developer or firm they want to work with. Agreeing on what work will be completed is important in the bidding process.

When building a house, for example, the builder will usually have a plan from an architect which outlines exactly what needs to be built. This works well because homes have been built for thousands of years. The needs of a home owner and the time and cost needed to deliver those needs are all well understood. The cost to change the house once built is also very high, justifying up-front planning.

When developing software, however, the needs of the users are often not well understood. The product being designed and developed may be filling a new need. The technology being used may have only existed for a few years, or months. Once built, it can be changed at a relatively small cost.

In software, if the user and client try to agree beforehand on what should be built, they can’t take into account user feedback without renegotiating what was in the RFP. Once work begins, the goal of the developer is to build what was in the RFP instead of building the best possible product.

Instead of comparing bids, clients should look at the previous work of a developer or a firm to evaluate who they want to work with. They should ask people they know and search online for reviews from previous clients. They can compare price based on units of time instead of units of work.


Another thing that is significantly different in the software industry is estimation. Developers have often automated away the tasks that they have completed enough times to estimate accurately. This brings those estimates close to zero. Any task which is new to a developer is hard to estimate because of unknown unknowns. Unknown complexity won’t be uncovered until the system is built. Estimates are inaccurate on a small scale and become increasingly less accurate with size.

In software, clients can get better estimates from developers by focusing on the next incremental outcome the need to achieve for their business, not features. By presenting a developer with their desired outcome, the developer can use their knowledge and skills to try to design the simplest solution. The client can also hire the developer for a scoping exercise such as sketching, prototyping, and the product design sprint, which can be a much smaller investment.


Whenever a business transaction occurs, both parties are susceptible to some amount of risk. One of the reasons clients and consultants agree upon what is going to be done beforehand is to minimize risk. If they don’t agree on what is going to be done up front, the client risks that the work could end up being more expensive than they originally planned. Fixed bids were meant to prevent this from happening.

It may seem that a fixed price reduces risk for the client. Clients are usually much more comfortable with a fixed price. They feel that once an RFP and a price is agreed upon, they no longer need to worry. At that point it should be the developer’s problem. This is a false sense of security. Software needs to be maintained and updated. If the development was rushed, it is going to be more expensive to maintain and update in the future. The client will end up paying more in the long run which was what we were trying to avoid in the first place.

A client can never be sure a project won’t go over budget. They should choose a firm or developer who they trust enough to know that that firm or developer will be working as fast and cheaply as possible without rushing or cutting corners. They should choose a firm that aims to simplify their product, which may reduce cost of maintenance.


Clients like fixed bids based on RFPs because they think it reduces risk. Most developers know that fixed bids are bad for them. Sometimes they give in and make a wild guess about how much something will cost to please the client, hoping to make the sale. In a consulting relationship, the consultant should do what’s best for the client, which is not always what the client wants.

When choosing which developer or shop will build a piece of software, clients should be wary of developers that are willing to make harmful decisions to make a sale. Instead, clients should work with developers they trust. Clients can develop trust by reviewing previous work, focusing on outcomes instead of features, building incrementally, using prototyping tools and techniques, talking to users, and keeping scope small. Once a trusting relationship has been established the client and developer can work together to make the best product possible.