8 Reasons Why You Should (Not) Use Fixed-Price Or The Hidden Rocks Of The Fixed Price Contracts

It is commonly believed that a fixed-price model is the best way of cooperation which gives the client absolute clarity of the project budget and timeline, insure them against the team’s fails and cheating, and saves the costs. But is it really so and are not there any hidden rocks in fixed-price contracts for you as a client who seeks mobile app development? And what are the situations you when you should 100% use fixed-pricecooperation?

Let us just cover a tiny piece of theory before diving into the deep waters of cost and project management. So, putting it in a nutshell a fixed-price agreement as a kind of agreement where the scope of work has been defined before signing the contract and starting the project and the contractor (in our case the software developers) takes on the obligations to deliver this full scope within the fixed budget. Certainly, as a client you would expect that you have eliminated all the project risks and all the responsibilities are now on your software developer, not on you. You are right but this is only a part of the complete picture.

Here we summed up all the situations when fixed-price contracts are just right up your alley. We do not pretend to possess a monopoly on the truth but these are the cases where we would recommend our clients to choose fixed-price.

1. You are ready to pay more than your project actually costs

No matter how experienced and top-level the developers and managers who estimate the project are,they will tell you that it is practically never possible to give a 100% accurate estimate. Anyway there will appear some unexpected details, technological peculiarities, integration difficulties, or other unpredicted moments which will influence the final project scope (most probably to the higher degree). Everyone wants to hedge their belts and software developers add a certain amount of cost to their final estimates in order to cover these expectable risks, so depending on the company policy the extra charge for the fixed-price project will range from 15% and up to infinity, in most cases it makes 50%-100% of the estimated budget. Of course if this budget is not worked out (and usually it is not completely) it means you in fact overpaid it. If you are ready to pay more than the actual cost turned out to be (with good teams the projects sometimes finish even a bit earlier than expected), then fixed price is an option for you.

2. Your time and energy are absolutely unlimited and you cannot live without negotiations

You will need to allow a great amount of time and energy to formalize and approve all the fixed-price project documentation together with your development team. You will probably need a round or two of negotiations on the general budget and timeline and even after that it will not be over. It is almost 100% guaranteed that at some point you will come to the very famous “bug or feature” dispute, where you and the developers will be kicking a ball for some piece of functionality which depending on the parties’ eloquence will be paid by you or implemented at the expense of the company. Not to speak of the negotiations on the additionals features, functionality looking not like you expected, budget increases etc. So consider the additional time you will have to spend in making everything work good and take into account that the development will most likely be pause while you are negotiating so the deadlines will have to be shifted too and you will get your app later.

3. You are absolutely sure your idea is perfect and will not need any improvements

Another great moment which is actually a cornerstone of the fixed-price principles is the absolute rigidity — no changes are allowed after the project scope and budget are approved. Truth be told the developers will be right if they refuse to do even the slightest changes (like background colour or fonts size adjusting) no matter how harmless they may look because slight changes, tweaks and enhancements may end up in bigger changes affecting the whole system. You should be prepared that with a professional team there will be zero flexibility with the requirements even if you suddenly understand you were wrong about that particular feature and you want to replace it with some other one. From our own experience the clients ALWAYS ask for some changes after they see the system partially implemented and get better ideas too late. So be careful with your ideas and requirements with the fixed-price projects.

4. You are not afraid of losing your marketing advantages and breaking the deadlines

And this follows the previous points. With fixed-price project, you may spend more time than expected in pre-negotiations and requirements finalizing, the development may sometimes be paused to settle the budget and feature issues and what is most important to your app’s success you cannot add or remove approved features. Also if there occur any unexpected delays while coming to the agreement or if the scope of work turns out to be larger than expected no tricks and special effects from the developers can put the project back and ensure it finishes on time. So if in the process of the development you suddenly learn about some competitors who are making an app with similar features or have already published it in the stores it may be hard to win your marketing advantages back and add twists to your initial plan with the fixed-price.

5. You are not afraid if your software lacks quality and are not focused on quality on the whole

The name of the fixed-price model itself puts the stress on the most crucial part of this model — the price. The budget is one of the constants your development team is trying to stick to. But if we try to look at the whole perspective we realise the success of the project depends not only on its price but also on such factors as quality, creativity, timeliness, technologies used, and a number of others. Under the conditions of the fixed budget the quality is sacrificed first when the budget is exhausted. Go ahead with fixed-price if you are ready for this.

6. You do not want to take part in the project at all

With the fixed-price it is the team who decides how the project should go and how to fit the budget so unfortunately you will not be able to have meetings with the developers (you will still have a project manager) or instruct the team on how everything or some particular parts should be implemented. The moment you sign the agreement you pass all the initiative to your team and your breaking into their processes will be really unwanted.

7. You do not care about good relationships with your team

Fixed price contracts always lead to zero sum game, either the development team loses after being obliged to complete the greater scope of work or the client is disappointed with the delays and failures to add features he came up with after the project start. Even the most effective communication cannot save you from more or less of finger-pointing and it is highly possible that one side will end up with a rather bitter taste.

8. You have a very small project and thorough complete requirements

Bingo! This is actually the best reason why you could use fixed price. When your project is up to about 100 hours and needs only few weeks to be implemented this is usually something with very clear-defined (and not numerous) features and this is undeniably the most appropriate reason to go with fixed-price contract. The team do not risk much so there will be minimum overestimation, requirements completion will not take much time and with all these circumstances the project is extremely likely to go smooth and end quickly and painlessly.

Summing it up

So here are some reasons for using the fixed-price model in cooperation with software developers and some situations and reasons to use (or not use) it. If however you are not sure about all or some of these points, it is up to you to weigh up the risks once again and decide what the priorities of your future app are and if they are in the quality or the cost primarily. In our next posts, we will share more of our thoughts on the cooperation models and making them fit both the clients and the developers. Stay tuned!

Anastasia Gnes Marketing Director