Fixed-Price or Time&Material - which payment model is best for your project?

Software development companies base their pricing model on different concepts. Software Houses most often choose to offer Time&Material or Fixed Price models. Each of those has its pros and cons, and each one will work out better in the case of different projects. However, we begin to notice the growing popularity of the Time & Material model. Let's try to analyze why that is happening.

Which model is the most beneficial one?

Unfortunately, that question won't have a straightforward answer because each IT project is different. Small analysis, however, is necessary - the wrong choice of how the settlements are made between software house and a customer may lead to problems, blown budgets, and a lengthy development process. In addition, new functionalities may be problematic to implement, and the development may stall, leading to an unfinished product. So let's dig deeper into the difference between the two most popular payment variants.

Fixed-Price - a preset cost of application development.

Fixed-Price assumes the notion of customers paying a pre-defined amount of money negotiated before the development process starts. The estimation is created based on the product requirement document, which strictly defines the scope of the application to be made. Delivery milestones and deadlines are agreed upon, and everything is enclosed in a tightly constrained frame. Fixing the price is a practice that is liked because it gives businesses confidence that the budget is set and what will be charged is known well in advance. If the product owner has tight limitations when it comes to spending, with no additional financial support, this model will be captivating. However, experience suggests that the situation described above is improbable and rare. It is ubiquitous that even in the case of well-defined projects, uncontrollable circumstances cause the Software Development Life Cycle to shift and pivot. In those cases, even though parties involved wrote the scope and rules in stone, development must come to a halt. Renegotiation of the agreement then follows, which is quite a lengthy process. The resources reserved for the development of the ordered application - have to be put either on hold or a completely different project. Such changes will make them unavailable for even longer than the renegotiation. 

Example of Fixed-Price cooperation.

Let us use an example to visualize the approach with ease and simplicity. Let's assume that we change the vertical and want to order a custom-made cabinet. It has a specified size, the material that we choose is an oakwood, it has to include two separate drawers and swinging doors. We agree upon a set delivery date and price, and we can now rest at ease and wait for the furniture. Some additional documents are handed to us for storage in a couple of days, and now we realize that our cabinet needs an additional third drawer. In addition, a colleague who will use the cabinet points out that it's better for the doors to be made of glass. It will allow us to peek into the storage space without opening it. We reach out to the furniture maker to ask about the manufacturing status only to find out that the majority of the work is already done, and no changes to the furniture frame are possible at this stage. We can scrap what has been made so far and start from scratch because modifying the unit will cost more than making it over from the beginning. All will lead to a significant delay and unplanned additional costs. 

Software Development is, in this case, very similar. If we have a fixed budget, a list of requirements, a development plan, and assumptions that we are sure will not undergo any changes, we can try and work with that model. However, the problem is that in most cases, this scenario is illusionary - and the sooner we realize that, the better for all the parties involved. 

Another obstacle is of a beaurocratic theme. Each change to the project will require added workload on the Project Managers behalf. Along with the developers, he needs to verify if the team can implement the changes at the base level of the application - when the developers initially laid out the plan, certain technologies and methods were assumed - and those might not be compatible with new features that are to be added. All threats we have outlined are getting proportionally more dangerous when paired with the scale of the project. The bigger it is, the more probable it will be that the Fixed-Price approach will be a nail to its coffin. 


Predictability: it's easy to plan spendings, and we get precise information about the scheduled delivery dates of the project.

Transparency: clearly defined scope and budget provide security against surprises over the development course. 

Management ease: work is planned well in advance, and the project doesn't need constant maintenance.


Lack o flexibility: there are no changes to be made over the development course. If any ideas appear and circumstances that need reaction occur, development might stall, and it will threaten delivery dates.

Loosening of the responsibility: tightly defined constraints makes contact between the parties less regular. In effect, the information is shared less frequently, which may cause problems.

To summarise : when to choose the Fixed-Price model?

  • When ordering small, uncomplicated projects, which will not change over time.
  • when building a limited MVP,
  • when the risk of development impairments is minimal,
  • we have a small, fixed budget

Time and material - paying for what gets done.

The T&M model works quite differently than the Fixed-Price one. In this case, instead of one preset amount of money up-front, payments are monthly and include only actual work hours spent on developing the application. This is most popular in situations when a customer understands IT development and has good knowledge about the tools of the trade. Such a grown product owner usually went through some projects using the Fixed Price model and already had a bad experience. It's a well-established fact that readiness for a pivot of the product is crucial to a successful release - especially from the business standpoint. Securing the development team early in the life of an application is a good practice - and during the early stages, the uncertainties are in abundance. This by no means is a bad thing - the proper customer development processes that should be conducted at the beginning are good practices - and imply that the product requirement document will change over time. Selecting a T&M model with a chosen Software House makes implementing those changes possible and beneficial to the final product. 

Let's visualize once again. The T&M model simplified.

In this case, our influence over the work to be done is much more significant. The project is split into small tasks that can be programmed independently. Let's see our cabinet once again. If we order it based on the T&M model, then, after gathering base requirements, the team that builds the cabinet will proceed to the analysis phase. We provide specifications such as what we need to store in the cupboard, how many people will use it, where it will be located, are the locks to be placed in all, some ore none of the doors, etc. During the analysis, what will be found will be thoroughly discussed with us to reveal additional conditions that were not verbalized initially. Such conditions as the possibility of receiving new documents will be easily identified at this stage. In addition, an approach that makes the team ready for sudden changes in the furniture's core functionality will also be applied. Whatever occurs along the way will not be an impairment to the product. It will be delivered incrementally, part-by-part, with reviews after each manufacturing run (in the case of software development - after each SPRINT), eventually handed over as a whole.

The downsides of the T&M model. 

The only real threat that the Time and Material pose is going over the planned budget in the long run. To minimize this problem, we should concentrate more on communication and control in the development process. Because the product is delivered in phases, and charging happens every month, it is theoretically possible to go overboard with the costs. However, if the product owner is active, reviews and signs off each sprint, the risk will be minimized. They will be able to react as soon as it turns out that the work hours are spent faster than expected. Such an event might occur when the team has to adapt to a new goal added to the project, e.g., additional functionality that wasn't in the initial plan. The agile method also helps in this case since the functionality, before being coded, will have to be planned and scheduled first - and this will happen with the inclusion of the product owner.  The responsibility the product owner has is crucial. The more they are engaged in the process, the more chances we have, control spending and deliver a perfect web application to the market.


Flexibility: we can create the application with ease, with the ability to shift and change priorities on the go. 

Dynamics: It's the final product that is most important, not the pre-made constraints absent in the T&M model.

More straightforward time estimation: Bigger control leads to more accurate estimates. Tasks split into small enough chunks are much easier to handle. 


Less budget control: if not taken care of properly, lack of control might endanger the budget.

Higher commitment: The customer's product owner needs to participate in the development process actively.

Running late:  if tasks are not handled correctly and goals are added without control, the development will stretch over time.

So, when to choose Time and Material? 

  • handling big and complicated projects
  • we are aware of the software development reality 
  • there is a high chance the functionalities might change
  • using customer development approach
  • we want to pay for what we get
  • we need a flexible system that can compensate for the changing circumstances

So what about your project?  

Both methods have their pros and cons.; there is no doubt about that. However, in the experience, we have learned that the conditions that allow for a Fixed Price approach are rare enough to consider every project's worth of the Time & Material investment. The best thing to do is to ask - think about where you're at with your web application and what your vision is. Bring that into the meeting with the software house, and you will be led by the hand. If you have anything you wish to ask about - go ahead and click the button below - we will try to help you out as much as we can!