Agile vs Fixed-Price Contracts

Photo by Austin Distel on Unsplash .

Many businesses start mobile apps today. They may augment an existing offer or spark a new business opportunity. To get started, you typically ask software dev shops or freelancers. Once you pick your contractor, there are two different types of contracts: an agile contract with an hourly rate, or a fixed price, with a maximum number of iterations. Either type has merits and risks. Which should you pick?

From the Contractor’s Point of View

How do the different payment models look like from the contractor’s point of view?

  • If the contractor is very experienced with the project scope, she can work fast and effectively. The first version gets done quickly, and any subsequent iterations will neither take long nor use lots of resources. For an hourly rate, this is more of a disadvantage since she will deliver faster and get the same money even though she delivers more. Or conversely, earn less for the same project.
  • The hourly rate model reaches a point where there’s simply not enough time in the day. One can not work more than 24 hours per day. Even if the contractor is highly efficient, the money she can make is limited.
  • With a fixed-price project beyond 5k the payment model is typically a third upfront payment, a third after a milestone and the final third after completing the project. This guarantees a better cash flow. Contracts based on hourly rates are paid monthly, so payment is typically weeks later.

The most prominent disadvantage is risk:

  • In case of unforeseen difficulties, the contractor doing a project at a fixed price will perform worse. She carries the all of the implementation risk.
  • Sometimes, the client is the source of the problem (changing requirements and disguising them as clarifications).
  • The client may be unwilling to compromise, especially if it wasn’t her fault.
  • With an hourly rate, it is easy to end the contract early, and there is no dispute over remaining fees. At a fixed price, any upfront payment makes this much more complicated.

From the Client’s Point of View

How does it look from the client’s perspective?

  • With the fixed-price project, the client controls the cash flow. She knows how much and when to spend money. This de-risks projects running over budget. At least to some extent.
  • The fixed-rate project may be delivered and tested sooner. The client needs to pick the essential functionality, and that is done first. The app is already published once the minimal functionality is there!
  • Once the app is published it can be tested, and the business model can be verified. No need to wait for any artificial definition of “done.”

The last point essentially highlights the major short-coming of the fixed-price model from the client’s point of view:

  • Business risk. While the implementation risk lies with the contractor, the business risk lies with the client. Are we building the right app? A false sense of certainty about user needs is the No. 1 reason why apps fail!

The No. 1 failure of most apps is that they don’t help users!

Having said that, with a fixed price you are forced to settle on the project scope and direction way too early. The client most likely does not have ample user feedback and the wrong vision.


So what’s the best model? For a project with limited scope and little business risk, it is typically advantageous for both the client and the contractor to pick a fixed price.

For a project with uncertain scope, the best approach is an agile model with an hourly rate. In my experience, any business risk far outweighs the benefit of a reduced implementation risk on the client’s side!