If you have ever purchased software development services, you have likely come to a fork in the road at some point, bearing two very different signs: "fixed price model" and "hourly work model". In some cases, the answer is pretty obvious, but at other times, it’s not an easy choice to make. To clear up this common mystery, let's summarize the cons & pros of each model. For those who are going to order software or app development services at some point in the future, this article will help you move past this fork in the road without any delays or doubts.

The image of two cars for Hourly rate and Fixed model

 

Fixed price model pros and cons

 

This model is best suited for projects that are going to be started from scratch, and those that have full documentation that will not change during the development process.

  

Pros

The price is fixed and will not change unless you request any modifications or new features to be implemented into the app. In that case, every new feature/set of features could be estimated separately and implemented under the same fixed price project.

Cons

A fixed-price approach requires full documentation before the start of the project. You'll need to consider every button in your app before the project can begin. Otherwise, developers won't be able to provide an accurate estimate. This could be a very complex task when you have a big project.

Pros

You know the end date of a project. Therefore, you can plan your steps accordingly, such as planning an advertising campaign, for example.

Cons

There is no flexibility in terms of work scope. If you decide to change any app requirements, the project manager (PM) will need to initiate a re-estimating procedure, which usually results in a delay to the project. The work will continue after a new estimate is generated and confirmed. Another downside of this approach is the need to change and re-sign an agreement.

Pros

As a customer, you don't have to apply much effort during the process of development. The biggest task is checking on progress and occasionally answering questions from the manager.

Cons

The fixed price development cannot be used in the cases, such as:

  • the app has a very specific functionality that cannot be measured and estimated by the developer. For example, when the usage of private API's is required;
  • the app was written by another developer(s) & support of the app is required. In such cases, developers cannot estimate the time required to implement modifications, as they cannot guarantee the operability of another code.

 

 

Hourly rate model pros and cons

 

This model is best suited for projects that have no definitive end, such as big corporate projects that constantly evolve and improve. Or, the hourly basis could be effectively used for passive development, such as application support or fixing and improving an app by doing small tasks from time to time.

 

Pros

No need to have full documentation. It doesn't mean that the project can be started without specification, but it does not need to be complete. Developers need some work scope to start the project, but you can expand the app scope throughout the development process. Adding new requirements on the run is much easier with this model.

Cons

No one knows what the end price will be for your project because no one has the complete work scope. Therefore, it's up to you to track all the expenses for the project.

Pros

You can change previously stated requirements at any time. Since the project has no milestones or total estimation, the developer will just move in the new direction and keep going.

Cons

Since the developers don't have a work plan with a list of milestones, they cannot determine the end date of a project. You determine when the project is finished. When you feel that the app has all the functionality you wanted, you have to finalize the project.

Pros

This model fits any kind of project. Whether it is support of an existing project or some experimental exploration of your unique idea, it can be used without a problem.

Cons

Since programmers don't have full documentation, you will need to constantly cooperate and communicate with the team and send them new tasks in order to keep them busy.

 

 

Conclusions

 

Each model has its own advantages and disadvantages. However, if you have the full specification for your app and don’t plan to change it, you should definitely pick a Fixed Price model. If you don’t have the full app documentation, but still want to use a fixed price model, Appus team can help you by creating a wireframe for ourselves. This is a conditionally free service, and you may read more about it here. Good luck with your project!