Fixed Price vs Time and Material

Albert Pałka
codequest
Published in
3 min readMay 23, 2017

--

Author: Tomasz Korzeniowski

I have been helping people to turn their ideas into software products for almost 12 years. Often clients ask me to give project quotes on a fixed price basis, but I always try to encourage them to go time and material. Why? I am glad you asked :)

At first you may think that the fixed price model will protect you against extra costs. Your worries are completely understandable because it is hard to entrust your project and money to someone you don’t know. You may be skeptical about the cost estimates or simply afraid that the service provider cheats on you.

But if there is no trust in the first place, would the fixed price basis help you to save money? Won’t it just limit the project’s potential instead?

Software loves when it’s handled with care and it always pays you back.

Software loves when it’s handled with care and it always pays you back. I think that with time and material both of us get the most out of it. We avoid misunderstandings, build up trust, and team up to turn a great idea into an amazing product. Let me explain to you how it works.

Quite often the way the client and developer understand the same concept is completely different. This may include differences in deadline estimations, amount of effort to be spent on this or that task, or any emergencies.

What does it mean? There will definitely be numerous omissions or ambiguities in the technical specifications. Good specs only set the project up during the initial stage of development.

Change is constant in software development and the secret lies in prioritizing and doing things that need to be done here and now. The more we work on the project to make it better, the more new things and terrific ideas will be storming our heads; old ideas will fade into the background or simply die away. Everything changes and it is perfectly natural.

In that case, how should one estimate the price? Where do the improvements and additional changes go and how do we know how much is left of the fixed budget?

Such questions are awkward and bring a lot of risk that neither side needs. This way at some point both parties may become adversaries. The developer will try to fit everything in the planned budget under strict control of the customer, which will make for a product that is just good. And we don’t want that.

To deliver a product that makes a huge difference the customer and service provider need dive into work and do what it takes to make it look spectacular. The time and material basis fosters creativity, team spirit, commitment, and mutual trust. And I believe these things are the foundation of a great start-up and a recipe for success.

--

--