6 Fixed-Price Contract Risks and Challenges You Need to Know

6 Fixed-Price Contract Risks and Challenges You Need to Know

Fixed-price contracts may seem secure and easy, but do not let them tempt you before you understand the risks and challenges that come with.

In this article, I will focus on the cons of a fixed-price contract. If you want to learn more about the pros, you can find them in the article about pricing models (and their comparison) to establish which model is the best for you.

What is a fixed-price contract?

Software development companies usually offer fixed-price contracts or Time & Materials contracts. The main difference is that in fixed-price contracts, you know the development costs, while on T&Ms, you pay for developers’ hours and can never be sure how much the final product will cost.

You can say a fixed-price contract is a well-specified product for a well-specified price that a dedicated team is to build in a specified time. There should be no surprises, and you should get exactly what you ordered for the price you agreed to spend.

In more flexible fixed-price contracts, you might have a target price and ceiling price specified, so even if you’re not sure how much exactly the app will cost, you still have a firm price limit.

Sounds tempting? Sure, but let me show you the dark side of fixed-price contracts.

Fixed-price contract risk

No. 1. One gains, one loses

Fixed-price contracts always benefit one side – it’s either you or your contractor. Usually, the outsourcing company is the one who takes the burden of higher costs, while you have your app less expensive than it would be in the case of choosing the Time & Materials model. You should be satisfied, shouldn’t you?

It’s the first trap you can fall into with this pricing model.

Assurance comes with a price

First of all, let’s say you run a software house. What would you do if you signed a few unprofitable fixed-price contracts? Next time you’ll probably increase the estimation amount to ensure it won’t happen again. So does the developer.

By choosing a fixed-price contract, you agree to pay a higher price. There are about 30% – 50% additional costs that you probably wouldn’t pay for the same contract’s scope choosing Time & Materials model. Fixed ceiling price contracts, when there’s a higher acceptable price specified, also increase the estimated contract price to mitigate the developer risk.

you might pay less, but then what?

Now, put your contractor’s shoes and think about whether you would like to do another project knowing you will lose money? I bet you won’t take that risk. Your contractor neither.

So, you paid less for your app, but you lost the developer or may need to spend more next time. You can search for another contractor, but would it be cost-effective?

Think about all the tasks the developer already did to build your app. No one knows it better than they do. Changing a contractor means losing money which is needed to onboard a new company. They will need time to understand your solution, no matter how clear it was coded.

They also need to understand your company. So, you have to explain everything all over again to the new person. You both lose time, you and the new contractor.

Paying for management

Another factor that increases operational costs is project management.

The fixed-price contracts are usually more demanding in the field of project management because of the need for constant supervision and evaluation of the actual cost of the project to ensure the company won’t lose.

Managing fixed-price projects is time-consuming, and its main goal is to control costs and scope. A project manager needs to verify every comment and demand for changes, whether they are within the contract, are necessary corrections, or exceed the agreement statements.

There’re always changes in a project’s scope, and everyone has to acknowledge that before the beginning of the investment. The case is about managing them, the manager is a guard of the scope and a client needs to make some tough decisions (see below).

No. 2. Fixed-price contract means fixed scope

Imagine you’re redecorating a house and want to order a wooden table. You select the wood, define the desired shape, and table measurements – that’s the scope definition. The carpenter gives you a price for such a table, and if you accept it, they do the work. After the work is done, you make an agreed payment and enjoy your new table. Easy? Sure.

Unfortunately, software development isn’t as easy as making furniture. Even when creating a simple landing page, the requirements might change during the development, and the more complex app you want to create, the greater the possibility of project scope changes.

Unfortunately, fixed-price contracts don’t give you much room for that. Could you change the wood type when the carpenter has already done half of the table? Of course not, but in app development, you often have to.

Project adjustments

The development process lasts some time. You don’t lay your back during this period but work hard to launch the app successfully (at least I hope so 🙂 ). Every day you think about your end-users, their needs, and goals. You’re doing additional research and monitoring market conditions. You may realize your app idea needs to be adjusted.

But mostly, you can’t. At least you can’t without changing the agreement, which requires time and effort for parties to sign.

Some of the fixed-price contracts indicate how many changes you can make during the project and what kind of adjustments those can be. This specified level of possible modifications will increase your contract price initially but decrease the risk as you know what to expect and have a little flexibility.

In many cases, a software developer of your choice will accept some adjustments or even add some features to the scope without changing the contract and the price, but it has its cost. As the contract price is rigid, so are the billing hours. You need to remember that in fixed price contracts adding something means resigning from something else.

Rigid scope, flexible development

The most common misunderstanding in fixed-price-contract-based cooperation that generates conflicts is that the project’s scope was not been realized completely. In such cases, all the additional features and improvements that have been made instead of the previously defined scope are not considered. To avoid such misunderstandings, it’s better to sign an attachment to the agreement with updated contract terms.

Conceptualization is the process of imagination. You have to visualize how the app will work and indicate its features. During that time, you might realize that some features are unnecessary or can be replaced by some already existing software integrations, but since you’ve contracted to develop them, you have to pay them the firm price (unless you can change the contract before the feature is developed or you developer allows you to reallocate the resources).

Sometimes changes come too late, and a large part of the job is already done. That might mean throwing a huge part of code into the rubbish bin and the necessity to write it from scratch again. That may increase the overall cost as your contractor won’t take more risk, and you still have to pay for the pointless but done job. In such cases, changing the scope means changing the predetermined value of the contract.

There is jeopardize that the contract will never be signed in the new form, and all jobs done will be pointless and wasted.

How can you avoid pitfalls with the scope in fixed price contracts?

To avoid changing the scope or renegotiating the fixed price when the project begins, you should conceptualize your app perfectly. You should start by defining at least some parts of a go-to-market strategy and build a software requirements specification document (check my other article to read how to build an SRS document).

The more detailed the app description you provide to a software developer, the more precise and reliable the estimation you receive.

In many cases, not only fixed-price contracts, what a potential developer receives to make an estimation is designs and discussions on the calls. The lack of the goal, features description, animations required, and all custom elements significantly increase the risk of mispricing. The higher the risk, the higher the estimation (and ceiling price).

Detailed documentation leaves no room for interpretation for developers. It’s way easier to estimate and – that’s your direct benefit – allows you to compare all the offers you’ll gather because of the common specification for every potential contractor.

No. 3. Poor relationship

You should also remember that when the fixed price redetermination is concerned, the relationship between you and your contractor will change for the worse. You might hope that it won’t happen in your case, but it’s almost always the matter.

When the developer realizes that additional resources are necessary to make the project reasonably, they will consider whether they should ask you for more funds. They know it will worsen the connection, so they will take the risk and do some jobs with no profit. They want your project to succeed and maintain a good relationship with your company.

A developer will ask you for more money only when it is strictly necessary.

If so, you probably will be disappointed because you’ve already agreed upon the fixed price by signing the firm-fixed-price contract. The developer, however, knows that they won’t be able to build the app good enough without increasing the price, and if they do that anyway, they’ll significantly lose.

Even if you redefine the contract and increase the target price, it probably won’t compensate for all your developer’s costs in building your app.

When the contract fixed price is negotiated, you’re dissatisfied that you’re exceeding the budget and target cost, and the developer loses because you’re not charged for all the additional hours the developers spent on your project.

In the case of price redetermination, you’re both dissatisfied, and that’s not a good start to long-term cooperation.

A software developer’s goals

The ultimate goal for a developer (at least of us) is to build a great app. We’ve done some unprofitable projects, and we’ve invested our time for the best result. Sometimes, the cooperation was transferred from the fixed-price contract to the Time & Materials model.

The most important in such a case is to remember that a developer is project-oriented and aimed at creating the best app that succeeds. It’s your goal, too.

Remember that your developer wants to maintain a good relationship with you. Sometimes you might spend twice as planned but receive triple as much in features.

When you have a fixed-price contract and some contract-related problems arise, I would suggest talking with the contractor honestly and discussing your objectives. A reliable partner will help you reach them, even if that means higher risk and lower profit. Or they will talk through the contract terms with you and perhaps offer a different contract type.

No. 4. Profitability first

If a contractor needs to meet the statements of the agreement, he needs to do the app within the budget and on time. Less important are code quality and optimization.

In fixed-price contracts, more important for developers is to tick off the tasks than to invent something spectacular that end-users will be delighted with. In this case, you and your developer are not on the same page – you both have different goals. You need a great app, and your contractor needs to do the fixed-price project within the budget.

If you’re about to work with a company that operates mostly on Time & Materials model (and most software houses do), the developers are accustomed to building the best app possible. A firm-fixed-price contract means, however, “building the best app within the budget”, so it probably won’t be “the best app possible”.

Fixed price – The best solution within the budget

In some cases, especially when the scope of work changes (and it always does in case of unforeseen circumstances), some unpredicted problems might appear.

The developers are oriented toward searching for the best solution for the project, which might not be applicable in the fixed-price contract case. The best solution might be too complicated and time-consuming and therefore unprofitable. In these cases, developers need to choose less complicated but not perfect and potentially flawed solutions to meet the set price.

Changing the approach might be difficult not only from the solution perspective but also from the developers themselves. It’s hard to change how they work and think about the project to provide a cost-effective solution instead of the top-notch one.

No. 5. Extremely detailed specification

Despite how easy or complicated your app is, to sign a fixed-price contract, you need to specify all the requirements before starting the development. Gathering those is time-consuming and hard at an early stage as many aspects of the project are unpredictable in the initial period.

You need to have much experience with software products to be able to predict all edge cases and user flows, or you need to hire a specialist to do it for you, which is an additional cost.

Why is the documentation so important? If you don’t specify some parameters of the project, the developers will decide on it, and as I mentioned in point 3., their best interest is to make it fast and on budget, not to make it the best.

This brings us to another important issue with firm-fixed-price contracts.

No. 6. Not what you’ve expected

All those aspects mentioned above lead us to the final problem – the app is not what you expected. First of all, if you won’t agree to increase the budget, the developer has to search for a compromise between quality and cost. Therefore, especially if they agreed to incorporate into the project changes that were not contracted, some parts of the project might be omitted.

If you’re paying a fixed price, you’re paying for a specific number of man hours. There’s a limited working hours amount that can be assigned to the project according to the set price, so if one thing is done, something must be left behind.

If you are in such a situation, think about how many not mentioned in the contract features or solutions were developed for your app. You might be surprised at how many elements might be considered additional.

Your app will never be good enough

Another problem with a fixed-price contract is that you will never consider your app good enough. You’re paying for your app, and you want it to be the best. That’s fully understandable but problematic.

It’s like you would like to buy a waffle. You’re ordering a waffle with cream and icing and paying for this, but when it’s prepared, you also demand fruits. Will you receive some?

It’s obvious you’ll have to pay extra or won’t get a single strawberry. But when it comes to app development, clients still demand a bunch of fruits of all kinds and, without them, are highly dissatisfied with the waffle. No matter whether they’ve already hit the ceiling price or not.

The point is, that there’s sometimes a lot of exaggeration in the striving for app excellence. In many cases, if every hour were billable as it is in the Time & Materials contract, the application would be considered good enough way earlier (perhaps with much lower actual costs), without all those detailed adjustments.

When fixed-price contracts are considered, sometimes it’s hard for clients to choose when to stop improving the app. In fact, if all resolutions were accounted for, developers would spend 80% of their time making the app look gorgeous on every device. It’s a huge loss of time and money.

In fixed-price contracts, a software developer is the one who decides about that, so clients are usually disgruntled (even if this aspect of the app would be considered great in the Time & Materials case).

The environment is constantly changing

When you conceptualise your app in the initial period, the concept might change as time goes by. The final app might not be good enough for your end-users because the project’s scope is fixed, and any change needs to be contracted. The code quality might also not be the best, and as a result, the app will work slower or generate more costs.

That means you might need maintenance or adjustments right after launching the app.

As a result, you disburse the agreed price and end with a product that requires additional investment. I bet that’s the opposite of why you wanted to choose a fixed-price contract in the first place.

When to choose a firm-fixed-price contract?

A fixed-price contract might be the right choice for projects with clearly defined requirements and, therefore, the scope of work. Although it’s possible to change the contract, it generates problems described above.

It is said that this pricing model is good for small projects. It’s true because of the clear scope of work of such a project. A developer knows what to consider in estimation, so it’s close to the actual cost of the app.

However, a firm-fixed-price contract might be successfully applicable also for big and huge projects if the requirements are properly defined. Enterprise companies often choose such a model. They have resources to investigate and conceptualize the idea and then write documentation. A software developer is hired to build exactly what was planned and described in the documentation, with no room for changes.

Summary

In fixed-price contracts, a developer is not your partner and won’t help you build the best app possible. The contractor you choose builds exactly what is planned and defined in the project’s scope.

The biggest problems with fixed-price contracts are the conflict of interests between you and the contractor and the fixed scope of work. It can ruin the relationship in case of contract price adjustments or result in worse quality of the end product, which will only generate more costs after release.

I believe fixed-price contracts can work for very small chunks of work, but I would never recommend doing a large and complicated project like that, not an IT project at least.

The only exception might be a well-planned and clearly-investigated project with detailed documentation with no room for changes. Either case, they always need a significant investment in project management on both sides.

You can read more about types of contracts in Mike’s article on billing models.

If you wonder what type of development contract will suit your project best, don’t hesitate to contact me at [email protected] 🙂

Lead Project Manager at TeaCode

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence.

As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity.

Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.

Gabriela Jarzębska
Gabriela Jarzębska

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence. As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity. Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.