Why I Prefer Fixed-Price Contracts

There are two popular approaches to contracting with a "dev shop" or software consultancy. The most common option is an hourly rate, also known as “time and materials.” The other, less common offering is "fixed price" or "fixed bid." For more background on each of these, head over to my explanation of the key differences in another article titled Contracting with Dev Shops.

For a long time, I only signed "time and materials"-based contracts, but have since switched to exclusively doing fixed-price work. Let me highlight the key reasons why I only offer fixed-price contracts, and why you should insist on them from your dev shop, too.

1. They shift the risk away from you and onto the developer. By agreeing to a fixed price up front, the developer takes the risk that costs may be higher than originally estimated. This puts the burden on the developer to be very clear about promised outcomes, which is a benefit for everyone. Plus, no developer wants to spend extra time fixing bugs at their own expense, which means that high quality will be given a higher priority.

2. They encourage healthy communication among all parties involved. Constructing software isn't the same as building something on an assembly line. Although a feeling of certainty can pervade at the start, building a real app is a continual learning process for all involved. Things change and adaptation will be the norm. The greater the collaboration between you and the dev shop, the greater the chances that the project will be a success. Fixed-price contracts ensure that you'll never feel that the meter's running whenever either party wants to pick up the phone.

3. They are grant-friendly (or any project that is subject to a fixed budget). Agreeing to a final price up front is powerful: not only do you know up front that you can afford it, it provides more confidence with the rest of your budget since you know that the software costs won't suddenly balloon out of control. And if the price you've been quoted isn't affordable, it's much better to know up front than when you're three-quarters of the way through the project. When you know the cost at the beginning, you can explore other options and perhaps work with the dev shop on another solution that would achieve your desired outcomes in a less expensive manner.

4. Incentives are aligned for all parties involved. If you're paying me by the hour, do you think I'll be motivated to finish early? In fact, paying for a developer's time provides exactly the wrong incentives (unless you're the developer, of course!) You want to be paying for project outcomes rather than how many hours they sit at their desk working on your app. This is why I prefer to work with clients who agree to up-front pricing: I know from experience that it provides the best deal for the client. The great part is, it's also the best deal for me as a developer. With a fixed price, I know how much I will be paid, which means I can determine if this project is really worth my time and energy. If you agree to a fixed price, that means that you believe the price to be a good investment on the expected return. And if I also agree to that price, that means it's also a good project for me to take. The incentives are aligned: you get unlimited collaboration that will help the project become a success, you know that it will be in your budget and worth every penny; and I become incented to finish on time, with high quality, so that I'm not spending more time than I need to on your project.