What billing models are there for software projects?

You have decided - you need custom software developed for you. You can already get an overview of the costs incurred in software projects in our first blog article on the topic of "What does custom software cost".

Now you want to know which billing models are available? In our second part of the mini-series, we explain what you need to know to be able to distinguish and understand common concepts.

Fixed price models

Time-and-Material

Other models

Conclusion

Fixed price models

The traditional way of charging for custom software projects is fixed-price models. This means that you agree on a price for the implementation of the software with the software producer right from the start. In return, the contractor estimates the total project effort in advance - including possible correction loops. In addition, serious providers plan a safety buffer to cover unforeseeable aspects.

This sounds great at first, because it allows you to plan with fixed amounts for investments. The provider initially assumes the risk of exceeding the planned expenses.
But there are also disadvantages. As a rule, providers pay for assuming the budget risk - and this results in higher costs for you.

In addition, it is almost impossible for you as the client to think through all aspects and functions of complex systems in advance. Even with precisely worked out drafts and requirements, there are almost always requests for changes when the software can actually be tried out. This is not surprising - software projects are complex and good user experiences come from repeated testing and revision. During longer projects, changes often occur due to new user needs, technological innovations or the further development of the market. This results in changes to the requirements (so-called "change requests") during the course of the project. In a fixed-price project, they have to be negotiated separately and increase the costs later on.

If you want to determine the costs in advance, you can only work with estimates, which is particularly difficult with large projects. Black sheep among the providers initially entice you with low fixed prices in order to conclude a contract. When the end of the budget is reached, they make additional demands on you. Disputes are inevitable. We reject such practices, but unfortunately we hear about them again and again.

#Our Advice: Fixed price models often convey a false sense of security. Often enough, they do not produce the quality of results you need. If the budget is too tight, a predefined scope of functions forces the software developers to cut corners in the end - or to make additional demands. We therefore recommend a fixed-price model only for small or very clearly defined tasks. Most companies will not offer this option at all, because in practice they can hardly be implemented fairly for individual projects. Either the provider or the client ends up paying more - neither of which is desirable.

Time and Material

If instead you want to pay for the actual effort involved, time-and-material is the better way. This approach is very often used in agile projects and is especially useful when not all requirements are clear from the beginning. Especially with new developments, this is the rule rather than the exception.

Time-and-material can be used to reduce the effort for budget coordination at the start of the project. You pay for exactly what is actually needed in terms of resources. This eliminates the need for time-consuming detailed estimates and later renegotiations. As a rule, there is a fixed sprint price, so you don't receive completely unexpected invoices, but agree in advance on the size of the team needed and the resulting costs per month or sprint. The model lets you keep a clear focus on the content of the project, rather than tying up your time and resources negotiating contingencies.

History has shown that even with pre-planned budgets, projects are rarely completed on time and on budget and deliver the required results. Agile methods such as SCRUM emerged as a result of these findings. The supposed budget security of fixed-price projects is replaced here by a transparent mode that deals openly with the fact that not all aspects of complex systems can be predicted exactly.

Nevertheless, companies often have to make an internal budget calculation and have their investments released if necessary. Of course, it is also possible in agile projects to prepare estimates for you in advance and to set partial budgets for intermediate goals. This way, you can keep a good overview of the cost development throughout the project, even though estimates are never exact predictions.

Especially clients who have no experience with this type of project fear uncontrollable cost developments in agile mode. However, this is not the case. On the contrary, a well-executed agile software project offers two decisive advantages: On the one hand, you get the greatest possible transparency about the progress of the project and the use of personnel. On the other hand, an agile approach allows you to continuously control the use of the budget and the content. This gives you permanent control over the use of your budget, and you can make adjustments if necessary. If you are unsure, you can perhaps agree on an agile mode "on trial" with your provider and initially implement a subproject in this way.

#Our Advice: We recommend time-and-material accounting for exploratory approaches. It makes sense primarily for projects in which something new is created and there is still a certain variability in the concrete design. Get advice on this and choose software partners with whom you have a trusting relationship.

Other models

Of course, there are other models for financing a software project. Perhaps your project or a feature from it has the potential to be offered to other customers of your software partner? Under certain circumstances, the contractor may be willing to contribute to the development costs - if you grant them rights of use in return.

In extreme cases, they may even pre-finance the development completely. In exchange, they then own the licence rights to the software or individual modules. In this case, you pay periodic licence fees, as is often done with standard software. In this case, instead of being owners, you are preferred pilot customers with the option of helping to shape the development roadmap.

Another possibility is that the development costs are offset by business shares. This "IT for equity" model is especially interesting for start-ups that have only a small or no IT team of their own, or for joint ventures with IT partners. The model creates congruent goals between the partners, and is therefore often more attractive for both sides than normal contractual relationships.

Conclusion
There are different models with different advantages and disadvantages when it comes to billing.

Fixed price: A fixed sum is agreed for your project, regardless of the actual time needed. However, later adjustments to the budget may be necessary.

Time-and-material: Here, the effort for the development of the software is billed based on the actual time needed. So you only pay for the work actually done.

Other: Hybrid models or licence fees are alternative financing options. They can be agreed upon in individual cases.

Regardless of the billing model you choose, costs - and especially their control - are an important issue in software development. Therefore, in the third part of this series, we will show you which cost drivers there are and how you can ensure that your project is as financially advantageous as possible. Until then!