Pricing Software Projects The Right Way

Most people know the downfalls of hourly pricing and instead ask for fixed prices. What if we tell you fixed pricing on software projects is no better? This blog post is for you, if you don't want to get surprised on the next invoice from your trusted software provider.

First of all, every project is different. We also have clients who we generally work with on an hourly basis, as well as clients who have received a fixed fee from us. However, we were able to gain the best experience with the agile fixed price.

Before we look at what agile fixed price is, let's briefly discuss the advantages and disadvantages of traditional pricing models:

Hourly Billing

Invoice based on actual work. The Service Provider and Client agree on a set hourly rate and work towards agreed goals. The scope of the project is usually vaguely defined.

• Good for Software Agencies if they underestimated the amount of work.
• Generally speaking, there is less budget certainty - the final cost may be higher than the Client's expectations.
• On the other hand, the project is much more flexible and project requirements can change without additional bureaucratic effort and project delays.

Fixed Price

Fixed price set for the project with a strictly defined set of requirements. Out of scope tasks are usually priced on an hourly rate or are separately scoped.

• Good for Software Agencies if they overestimated the amount of work - bad for clients because they overpaid. With a fixed price, software service providers always have to add an uncertainty surcharge so that they don't have to pay extra themselves.
• In general there are a lot of uncertainties. Project requirements must be specified down to the last detail (overhead), which also makes the project itself very inflexible when new project requirements arise.
• If the software service provider has underestimated the effort, the quality drops drastically - because it no longer covers costs (see figure).

"Never compromise the Plan for presumed Speed."

Agile Fixed Price

There is one very common misconception amongst Software Providers about Agile Projectmanagement. An agile approach doesn't remove the necessity to plan a project - yet as so often that is exactly what is being done.

For that reason we usually divide larger projects into 3 phases.

And almost more importantly: So that you don't become dependent. Each project phase is structured in such a way that you do not fall into an “agency trap”. This means that you have the option to end the collaboration at any time and further develop the project internally or with an alternative service provider without having to start from scratch.

1. Discovery Phase

Within 1-2 weeks we collect as much information as possible and develop a common strategy for your project. This includes, among other things, monetization strategies, the actual goal of the project (e.g. saving costs, raising money from investors or developing a directly profitable & market-ready product).

At the end of the project you will receive a concept sheet. Depending on the size of the project, this covers 1-5 pages and represents a self-contained deliverable that you can use to go to other software agencies or then implement the project internally.

This document is not a requirement specification, but rather covers essential key points relating to your project. About priorities, timelines, core functionalities and much more that is otherwise often forgotten.

2. Test Phase

Now it's time to get down to business. We start your project!

During the test phase, an hourly price and an hourly quota are set. The test phase allows the project to start earlier and creates clarity of the project complexity and the actual requirements. In addition, new requirements and user feedback can be responded to quickly.

During the test phase you will receive ongoing updates about the progress of your project. In addition, the progress will be reviewed by you or one of your employees at 1-2 week intervals so that the project develops in the desired direction.

As soon as the hourly quota has been used up, the requirements and the software status are evaluated. If the defined project goal has not yet been achieved, the project moves into the “Finalization Phase”.

The result of the test phase is not necessarily an MVP (“Minimum Viable Product”), but rather a self-contained deliverable including documentation that you can further develop by other agencies or internally if desired. If the project goal “First paying customer” was defined in the discovery phase, then we will work specifically towards this.

3. Finalization Phase

If possible, the remaining project requirements are defined as epics and user stories. These are then offered as fixed prices and offer more budget security.

This is possible because all parties are clear about the priorities and goals of the project.

In addition, the greatest uncertainties in the project could usually be eliminated.