Fixed Price (FP) vs Time & Materials (T&M): Software Development Pricing Models Comparison

When it comes to software development outsourcing there are 2 pricing models that work for IT consulting companies: Fixed Price and Time & Materials. We at Cprime believe that both approaches are good if you apply them to the right projects. Let’s dive into the differences, use cases and pros, and cons for both of these approaches.

Fixed Price (FP) Contract in Project Management:

• Fixed Budget;
• Scope, features, definitions, and often timeframe are fixed too;
• Payments are usually made by installments.

The downside of the Fixed Price model is that it is very rigid when it comes to changes and involves a lot of bureaucracy to make significant amendments to software development, sometimes it even takes a whole contract to be re-concluded.

Use case: Fixed Price is the right pricing model if you’re building a landing page or a fairly simple corporate website, where the functionality is clear, limited and delivery will be short-term. For the majority of the projects that last longer than one man/month, however, this approach will result either in a lack of the right features or problems with their integration. And here’s why: a deeper vision of the necessary functionality for a product comes with the project’s progress, and understanding of the target audience’s needs and expectations comes with users’ feedback. Therefore, the most valuable product features often start taking much better shape closer to the end of the MVP development stage rather than when the initial requirements are defined. And the FP model by definition is not meant to accept changes to the original scope.

Summary: With FP you get your software development partner committed to the budget constraints rather than being flexible to deliver the best value if the requirements change.

Time and Materials (T&M) Contract in Project Management:

• Software development budget is estimated in terms of magnitude but not fixed to a specific amount;
• Scope, features, and delivery plans are flexible and open to on-the-go changes to a rather high (but justified) degree;
• Payments are usually made on a monthly basis for the resources used within the past month.

The downside of the Time & Materials model is that the final cost of the software project is not defined and fixed but rather narrowed down to some decent range.

Use case: For large projects without a clear close date, and/or with substantial functionality to be developed, big development team engaged, and/or implying long-term ongoing development, support, and scaling of the product, the T&M model proves far more suitable than FP. T&M enables agility and the ability to pivot development if needed at any stage of the project. It might seem a bit contradictory, but T&M also gives better control over the budget as the client is billed on a monthly basis which leverages short-term ad hoc planning.

Summary: With the T&M model, you get your software development partner committing to the delivery and quality of the needed functionality with adjusting fast and within the budget constraints if the requirements change.

What if the Vendor Team is New and You Are Not Sure About Their Quality, Skills, and Trustworthiness?

You want risks to be carried by the vendor, not by you. But the truth is, the Fixed Price approach does not solve this problem, at least it is not doing it any better than the T&M model.

From the first glance, it seems like you’re only risking wasting your pre-payment (and time, of course) if the new vendor fails to deliver against the FP contract. But if you look closer this doesn’t have any difference from the first 2-week sprint with the team running the project under the T&M contract. You can evaluate the results and make a decision to stop the work if you are not satisfied with the skills/quality/communication.

The mixed or Proof-Of-Concept approach has proved to be far more useful when it comes to checking the quality of a new vendor. In this case, you have your vendor deliver a simple and small prototype while researching for the biggest technical risks and proving the technical ability to build the project as planned. This allows you to verify the idea itself, the vendor team skills and approach, and see if the chemistry between your team and theirs is right and will set your product up for success.

Fixed Price vs Time and Materials

Pros of Fixed price

• Certain cost
• No need to control the process
• Exact deadlines

Cons of Fixed Price

• Costs are usually higher
• Longer preparations
• Difficulties with applying changes
• Limited quality control

Pros of Time and Materials

• Faster decision-making
• High flexibility in the project development
• Better control on the project

Cons of Time and Materials

• Lower control over the project’s budget
• The need to be more involved in the process
• More uncertain timelines

What if You Have a Limited Budget to Develop the Product and There’s No Way to Increase It?

When dealing with an outsourcing partner offering a T&M model follow these process:

• Request a vendor to estimate the range of the resources needed to complete the scope.
• Freeze, let’s say, 20% off your limited budget for a while. Depending on your own understanding of the ultimate product functionality you can tweak the size of this buffer – the clearer the definition of the feature is, the smaller the buffer can be.
• If the budget leftover is within the estimation range, start the work and be with the team under T&M with every 1 or 2-week delivery.
• Start working with the core features first – the most important or the most representative for the app.
• Tweak the scope and change the priority of the features if needed, and if the Project Manager provides you a clear understanding of the impact these changes will have on your budget, product value, and timeframe.
• When getting closer to the end of the project budget, consider if the 20% buffer you froze is worth spending on completing the initial set of features or on new features from the backlog that you need now.

In fact, following this format, with T&M you will have business-level control of your product (unlike with the FP process).

One of the challenges with FP is that the vendor here would be that, on their side, they will reasonably try to balance the risks that you are putting on their team and will have to add the resource buffers to cover the technical and management risks. That means that in an average situation with FP, not only will you pay more than you have to, but you will also have your requirements frozen.

Under the T&M pricing model, this delta if available can be spent to implement some extra nice-to-have features and tasty delights. In a worst-case scenario, when the outsourcing vendor starts to run out of time and budget, he will choose the only workaround available and not fixed in Fixed Price Contract – a decrease in quality. So in fact, while running the project under FP you control neither the features nor the quality of the product implemented.

On the other hand, there’re a few cases when FP will be an appropriate model and will work for you:

• Medical, governmental, military, and other projects where the quality bar is obliged to be so high or the business cost of change is so dramatic (e.g. additional licensing procedures are required) that all the requirements are strictly defined, clarified, documented, approved, and officially frozen by business and development teams.
• Small prototype-alike, temporary solutions, or apps for internal usage where the quality bar is not important and product needs are not dependent on the market.

Simply stated:

“Fixed price works well for small, well-defined projects. If you use it for anything else, you will pay a price in product and technology-implementation quality” – Andrey Akselrod, Co-Founder & CTO, Smartling.

Why Can Fixed-Price Projects Fail?

The lion’s share of FP projects fails because changes are made at the development stage. Why do those changes come so late in the process? These are some common reasons:

• Initial requirements were not clear or defined because an in-depth analysis of everything that was needed was not made during the project definition and planning stages.
• The technical team underestimated the complexity of the tasks involved.
• There is no flexibility to make changes. Modifications are possible at the prototype stage if the product does not suit the client’s expectations or the prototype inspires ideas that require changes.

Even if the customer is convinced that changes won’t be needed and everything will proceed according to the plan, in our experience 90% of projects require changes in the development process and that becomes a big problem when there are many adjustments. If the change represents 10-20% of the project development, the development company can add[t those changes without increasing the price tag. But if the number of changes goes up and keeps growing, there’s a great risk of the customer losing money on the development project and getting no viable product.

In other words, the failure of the project can lead to loss of money. The fixed-price contract model doesn’t guarantee a result so the customer bears all the risk.

Fixed price project failure example: You’ve got an idea for a product and a budget. However, at this stage, nobody can estimate with confidence how long it will take to complete this project and whether the idea can be developed. You sign a FP contract and mid-project you realize that the idea cannot be implemented. In this example, you are at risk of wasting your budget and not getting a working prototype.

What Can You Do in This Scenario?

To avoid going over budget when the finished product is far out of reach, you have to divide the project into small parts, each of which produces a result getting you closer to your ultimate objective while having a fixed price safety.

To do this, you divide your project in accordance with the stages of the project life cycle. The result of the first stage will be the precise definition of requirements. This means you get a realistic estimation of how your idea will work for a small amount of money. What would be the point? You decrease your risk of not realizing the idea at all and save the rest of your budget if you find out that there are no technical capabilities to bring your project to life because you find that your budget is not big enough to accomplish the goal. If the estimate works for you, you can proceed to the second fixed stage.

The second stage deals with a detailed solution design (it can refer to interface design or the project architecture, for example). Oftentimes the same functionality is seen differently by the customer and the developer. Moreover, the two can have different views on the appearance of the interface. At the design development stage, you gain insight into whether the interface you want fits your budget.

You can save your funds in this case because you’ve spent only a small part of it to get two completed tasks for your product. That way you can make a more deliberate decision on whether you should proceed with development or not. The second stage can also involve the proof of concept (POC) step. Here you check the technological feasibility of your product modules. Proof of concept is applied for complex and original products that need a more thorough and exact estimation.

The third stage involves the software development cost estimate. Based on the previous two stages, we can give you a final price. At this stage, we can remove some features from the project to fit in the budget as we know how long it will take to develop each of them. This again allows you to avoid wasting the budget without getting a result.

What Doesn’t Work With the FP Model?

The very idea of the fixed price model implies that the customer is paying once for the whole project and they get the final solution as a result. However, it doesn’t work this way in the software development domain. To ensure you get a ready solution you have to divide the process into small iterations, which will have a fixed price and result.

Why Do Time & Materials Projects Fail?

One of the biggest disadvantages of the time and materials pricing model is the necessity to motivate the developer’s team to do their best work. You have to keep an eye on the team constantly to make sure that they are working toward delivering the approved scope within the agreed amount of hours. This risk is on the customer solely. However, you can minimize it by hiring a project manager.

Another reason for project failure is low budgeting control. The overall cost can go far beyond the expected budget and make your project unviable.

The core difference between a time and materials contract vs a fixed price one is who bears the risks. With the FP model, all risks are carried by the customer, and with the ТМ model, it is the provider who has risk exposure.

This model has a distinct advantage. if you realize the current team or developer is not up to the task, you can always replace them in the process of product development. Moreover, you can stop the development process at any time without spending all of your budget.

This model is the developer’s favorite as it increases the provider’s involvement in the development process dramatically.

Time and Materials vs Fixed Price Contracts – What to Keep in Mind

When is a fixed price contract viable, and when should a time and materials contract be used instead?

There is no absolute answer, but there are some markers that can help you make the right decision. For instance, the larger the scale of the project, the better the chance that the time and materials pricing model is the best move. The fixed price model is more suitable for small projects with a development time of up t three months. Keep in mind that a considerable part of the FP budget is spent on management.

Another difference between time and materials vs fixed price models is in the degree of customer involvement in the development process. With the FP model, the customer assumes everything will be done without them taking part, and with the Т&М model, the customer is more involved in the process as the customer can have input on the process.

How Does Cprime Approach Fixed Price Projects?

There are some cases where a Fixed Price model is preferable. FP can be used in fields where formality is needed like healthcare, military, or the law. It can work for very well-defined systems, with external limitations on possible changes such as low-level hardware or security applications.

When working on a project which is estimated to take 6-10 months, you’ll encounter additional requirements that are capable of changing the initial price estimates dramatically. To minimize this risk for both the customer and the provider, we at Cprime strongly recommend developing the project on a step-by-step basis. At that, the maximum, a particular stage should take should not exceed three months using the iterative Agile approach to development. The key goals of such an approach are:

1. To release the first version of the product, which is the minimum viable product (MVP), with working functionality in a short time as possible, and launch user testing of this version. This will reveal both defects and new functions that users need.
2. Using the Agile approach with short (up to two weeks) iterations, to release updates including the most in-demand ones with user functionality. When working on the project using the fixed price model, it is necessary to divide the project into comparatively small steps with clear and concrete results for each step. On completion of several basic stages, you can proceed with cyclic (iterative) functionality development in accordance with priorities.

The Phases of Development for FP Should Include:

• The idea including architecture and the general design of the application. At the end of this stage, you should have a dummy application and a description of its architecture.
• Planning and estimation. Here initial re-estimation of the development cost of the application functionality is made in accordance with the design and functionality agreed upon at the previous stage. Also, here the initial functionality priorities are set. The result of this stage is the formulation of a minimum viable product.
• MVP development. At this stage, the detailed functional design of an MVP is created with subsequent development of the first app version to be released for user beta-testing. You also collect user feedback at this point. The result is the internal beta version of the product.
• Transition to application cyclic development. At this stage, you plan the completion of the project in which a new version of the application is released with new functionality and, possibly a new design based on priorities from users during beta testing. At this stage, you also plan and release a commercial version of your application.

Based on our experience, this approach allows the customer to obtain a workable version of the application as soon as possible while minimizing risks and costs. Taking user reviews into account will allow your application to fulfill user requirements.

Upon completion of stages 1-3, it is possible to replace the provider if you don’t like the work. Also, the provider can get insight into the infrastructure, which will result in more exact estimates of the development schedule and cost, as well as providing more clear accountability for such estimates. If the scope of work is big enough, you can involve two providers to create a competitive development environment and cross-check code, which will allow dramatic quality improvement of the developed functionality.

When choosing between T&M and FP models, it is essential to weigh all the strengths and weaknesses of each contract type and how they fit with your product development. We hope this article helped you decide which approach is best for you.

Maxwell Travers