Table of content
Fixed-Price contracts may seem safe and easy, but are they risk-free? Unfortunately not. There are cases where a Fixed-Price contract will work well, but don’t let them tempt you until you understand the risks and challenges they involve.
In this article, I will go over the details of a Fixed-Price contract and show you a Fixed-Price contract pros and cons. However, if you want to learn more about other pricing models and their comparison, you can go to our article about software development billing models that will help you determine which pricing model will be the best for your project.
What is a Fixed-Price contract?
A fixed price pricing model is based on an estimate of the amount of work that needs to be done. It guarantees a fixed budget for the project, no matter the actual work time your development partner spent and the expenses they incurred.
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. Sometimes, 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.
A Fixed-Price contract means the client can sleep tight as they know they will get exactly what they need and on time. The key priority is to meet the terms that have been specified in the Fixed-Price contract.
Types of Fixed-Price contracts in software development
So now you know that a Fixed-Price contract is an agreement with a specific price for a well-defined service. However, as I said earlier, some contracts may be more flexible than others. Different companies approach this differently, so always remember to read contracts carefully. The differences can be described according to how rigid and stable the price is and the level of flexibility when it comes to changing the scope.
The most frequent Fixed-Price contract varieties in software development are Firm Fixed-Price contract, Fixed-Price contract with economic price adjustments and Fixed Ceiling Price contract. Sounds complicated? Let me make it clearer.
Firm Fixed-Price Contracts
When you look for a definition of a Fixed-Price contract, you will probably find something about a Firm Fixed-Price contract (FFP). In a Firm Fixed-Price contract, the contractor takes on more risk and must absorb any additional costs or delays that may arise during the project. For the client, an FFP contract means that the price is set and will not change, even if additional costs caused by external factors occur. In an FFP contract, the contractor usually assumes all risks associated with the project.
The difference between other types of Fixed-Price and Firm Fixed-Price contracts (FFP) is that FFP contract is usually not subject to any adjustment, whereas a more flexible Fixed-Price contract might have a provision for economic price adjustment such as inflation or changes in time and material costs.
Fixed-Price Contracts with Economic Price Adjustments
Let’s assume that work on your project will take several years. In such cases the type of Fixed Price Contract you may use is a Fixed-Price contract with Economic Price Adjustment (FP-EPA). This contract type takes into account the dynamics of the market that change over time. A fixed price agreement with economic price adjustment is a type of contract that allows for adjustments to the contract price based on changes in certain economic factors, such as labour or material costs. Such an agreement can be beneficial for both the vendor and the client. As an example, when the costs of the service drop suddenly, the client may request a price reduction, but this also works the other way around – when material prices go up, the vendor may request adjustments to the contract price to cover the increased costs.
Fixed Ceiling Price contracts
Another option, much more flexible, is a Fixed Ceiling Price contract. The developer and the client set the top price they can reach and together adjust the scope so that it never exceeds this value. This is a very flexible approach to Fixed-Price contracts, where the scope does not have to be so precisely defined and therefore decreases the risk for both parties.
Fixed-Price Contracts Advantages
Before you decide to sign anything, be aware of the Fixed-Price contract pros and cons that come with it. Understanding Fixed-Price contract risks and challenges will allow you to take a responsible decision for the sake of your software project.
Actually, the biggest benefit of a Fixed-Price contract is that you know the exact software development cost right after the contract is signed. It cannot be changed by the software development company without your consent. This fixed price billing model is usually highly predictable for a client because they know how much they will have to pay for the software project.
Fixed-Price contracts require careful planning and management to ensure that the project is completed within the agreed budget and timeline, but if everything is properly discussed and scheduled, it should be easy to monitor the progress. Well-specified final scope and features allow the contractor to specify the timeline better. There are strict deadlines, and everybody in the software development team knows what work should be done at any stage of the development process.
You can sleep well understanding all the expectations and requirements for the project because this type of billing model doesn’t require you to supervise the project completion. Everything can be managed by the development team, so you can focus on other business tasks unless you want to monitor the progress on your own.
However… That’s it. There are not many advantages from my perspective. You may know the fixed price, but it can also be a minus, as cutting the costs on the way may be a bit tricky. Why? Let’s discuss the disadvantages of a fixed-price model.
Fixed-Price Contract Risks and Disadvantages
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 on 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).
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. But we cover this topic in detail in the section below.
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 has 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 jeopardization 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 of 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.
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 of a developer (at least in TeaCode) 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 thing 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.
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.
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 a lot of 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.
Not what you expected
All those aspects mentioned above lead us to the final problem – the app is not what you expected. First of all, if you don’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 working hours. There’s a limited man 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 conceptualize 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.
Can you modify a Firm Fixed-Price contract?
Like any other contract, Fixed-Price contracts cannot be changed unless both parties agree on changing the agreement. It works both ways – neither you, as a client, nor your software developer can change the terms of the contract without the consent of the other party. Both the client and the contractor have their rights and obligations listed in the contract, and before any change, both parties must agree to it.
However, if you want to add new features that weren’t specified in the contract, it is possible, but it comes with a higher price. That’s the trick: even if the client comes up with the idea that they would like to change something because they don’t like the results (due to wrong assumptions, changes on the market etc.), they still have to pay for it because it is in the contract.
But let’s say you really need to modify a Fixed-Price contract and the contract’s terms.
Usually, you need to complete the change request form and talk with the software development team if the change is technically possible. But first, think if changes are really needed and add value to your project because, as I said above, implementing them will influence the project’s cost and deadlines. Notice that even if your idea gets rejected, you will have to pay extra fees to the software company for their time spent researching and analyzing the issue. But if you and the development team go with the changes, you can start negotiating the price and timing.
As you see – with modifications it’s a high-priced process, which is why, it’s better to avoid changes in Fixed-Price contracts.
What should a Fixed-Price contract include?
The Fixed-Price contract ensures that a project is done and delivered within a specific timeframe and fixed budget. You cannot enter the project development stage before finalizing the contract. In Fixed-Price contracts, both the buyer and the service provider carry some scope-related risk.
That’s why it’s crucial to write down all project requirements and the project scope in detail. You need to have all the necessary documentation for the project. It should include technical specifications, workflows, wireframes, user journey maps, etc. The contract has to include the service provider’s and the client’s duties and areas of responsibility in detail (deliver data, quality standards), as well as the concrete budget.
When to choose a 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 the 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
The biggest problems with Fixed-Price contracts are the conflict of interest 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 releasing the final product.
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 and a predictable scenario, with no room for changes. In either case, they always need a significant investment in project management on both sides.
If you wonder what type of development contract will suit your project best, don’t hesitate to contact me at [email protected] 🙂
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.