Two main concepts are relevant to the pricing of software development solutions. One is time & materials, and the other is fixed price. It’s not difficult to guess that the latter involves an established fee to be paid for the entirety of a project and often involves the waterfall approach to project planning, while the former is all about flexibility, Agile principles and adjusting to shifting market realities. Time & materials contracts require the client to pay only for the amount of work that’s actually done by the provider’s team. In this article, we’ll help you understand what goes into the process of pricing software development services in both of those models.

How software development pricing works

The best way to understand both the time & materials and the fixed price models is to take a closer look at what goes into pricing software development services. There are many factors affecting the costs of developing a software project, some more impactful than others.

Time
The most obvious one is the amount of time it will take to develop your app. This is most often counted in hours spent on the work per developer, as many of them can be writing code simultaneously. In a time & materials scheme, you’ll find that developers’ hours will be the most common measurement by which they’ll calculate their fee. And for a good reason - it’s fair to pay them for the amount of work they do. In a fixed price estimation, the time could be rounded up to days, weeks or another unit of time agreed upon by the parties.

Number of developers
As mentioned above, developers can work simultaneously, on different tasks or different parts of the app. Because of this, development can go much faster, but you need to consider how much you’re willing to spend (per month, for example) and adjust your team size accordingly (within the limits of project requirements).

Seniority of employed developers
If you were ever handed a time & materials pricing, you might have noticed that different developers cost you different amounts per hour. There’s a good reason for that. The time of a junior developer who can do simple tasks efficiently but would likely fail at more difficult ones isn’t as valuable (and expensive) as that of a senior developer. You often need the expert for selected tasks and to oversee the project, but a good chunk of the work can be done by someone with less experience. Don’t worry if you see junior developers assigned to your team - they won’t be left alone to make costly mistakes. In fact, their presence means you’re getting real value for money. And don’t worry about the extra cost of hiring senior developers - they can complete tasks much more quickly and efficiently than less experienced devs, which can actually help you reduce project costs.

Expertise in a highly demanding field
Like with seniority, expertise is often required to a certain extent, but also more expensive. If your project involves Artificial Intelligence, Machine Learning or Big Data, for example, you’ll need true experts in these fields. Remember that it’s often better to pay the higher price than to risk major delays to the project, as extra time is needed to fix mistakes that could have been avoided.

Risk
There’s always risk associated with a business project. Requirements might be misunderstood or unclear, users can be difficult to reach, documentation can lack crucial information. With a time & materials contract, the provider might err on the side of caution while estimating project cost. A software house preparing a fixed price estimate, on the other hand, will add appropriate buffers (a direct extra cost for the client), taking possible delays and complications into account.

Buffers
With a fixed price plan used for a waterfall project, the provider needs to consider the unpredictability of the development process. Something might happen, caused by the client, the development company, or neither, and someone needs to be prepared. This is why the provider will usually include a buffer in their estimation, using their professional experience to judge how much potential complications might cost. If they overestimate, the client might never agree to sign the contract, seeing that the price is too high. But if they underestimate, they run the risk of dealing with major project delays. It’s a difficult conundrum that requires a lot of thought.

Licensing fees, if applicable
You might not be aware of the hidden costs of software development - the licensing fees. Depending on the technology you choose, you might need to pay for using it. There are good reasons to do so, too, even though there are open-source (free to use) solutions on the market. A paid solution might be a better fit for your current technological stack, or include some unique advantages. Weighing these against the costs requires careful consideration.

If you’re having trouble with this, ask your team for advice. They should be more than happy to help you out.

The differences between fixed price and time & materials pricing models

Fixed price contracts can be costly for both sides, and things may get stressful before the project even starts. Estimating a project correctly is in itself a time-consuming (and therefore expensive) endeavour. Potential risks have to be carefully considered ahead of time. There’s almost no effective way of introducing changes to the project requirements or scope once the contract is signed. New functionalities are difficult to introduce in the middle of development. Should the MVP make it obvious that a different approach would be better, the contract and project requirements will need to be renegotiated, introducing extra costs and causing a delay. It can turn into quite a conundrum with larger projects, especially on fast-changing markets or ones dependent on a still-developing technology.

The benefits of the fixed price approach include a precise cost of the project presented at the outset, which can help with budgeting, defined deadlines, and a lot of predictability to the entire development process. The client doesn’t have to stay as closely involved in project planning after the initial phase, as the development team will schedule their work in the most efficient way possible. This approach could work especially well for less complex apps, or even particular features.

Time and materials pricing, on the other hand, is perfect for full application development services, particularly for SMEs. It’s easy to divide the work into chunks (e.g. sprints in the Agile model) and change project requirements considerably when there’s a big shift on the market or when an investor makes it possible to develop a whole new set of features on a larger budget. It’s also easier to make sure that your development partner is being fair. Fixed estimations can be difficult to parse and often include large margins for the provider’s safety. The client may end up consciously overpaying, or they might not recognise that something in the estimation is overpriced.

With time & materials, you’ll usually get weekly or even daily reports on what your development team is doing and what tasks they have completed. You have a lot of control over what they do and where the project goes. If it suddenly turns out you need a different team, you can make the change easily and with minimal losses, because you haven’t agreed to pay a fixed amount. If a number of features needs to be killed, so be it - it’s better they be culled than get out of hand and turn into full-on feature creep.

Conclusions

It’s our opinion that the time & materials model is better in most cases, because it include no buffers (making it cheaper), the client pays exactly for the amount of work completed, and changes to the project can be made when necessary. However, some aspects of the fixed price model are attractive, such as the ability to show a rigid spending plan to investors. The final decision should be up to you and your development team - they can likely advise you on the best course of action.

Not sure which model suits your business better? Or are you confused about any of the elements that go into the cost of developing an app?
Talk to us. We’re always happy to answer any questions about our business.