Fixed price is not just a pricing model in custom software development; it predefines project processes and responsibilities of all involved parties. First and foremost, the constraints of the well-known Project Management Triangle—scope, time, and cost—are all fixed. They don’t have the ability to go over budget, and that’s the most favorable outcome for both parties. First, the scope must be defined. The Client should put forth the product requirements. After that, the contractor will calculate the price and timeframe. Thus it becomes easier for the project manager to control the app development process. The contractor will bear more risks, and the team maximizes the precision of their estimates.
The main problem of a fixed software development price is that there is almost no flexibility for the Client. Flexibility becomes a necessity in midsized and large projects, which are under constantly changing business and technology conditions. In that case, the dedicated team approach and its pricing become optimal from the business point of view, and the software development price equals the contractor’s standard hourly rate. As opposed, fixed price works well for small- and midsized projects that take on average up to 3 months: more documented requirements, less backend logic.
In order to understand how we make a custom fixed price project successful, let’s take a closer look at the software product development process, with specific details related to this contract type.
How Does A Fixed Price Project Run?
1. A fixed price project is never started without fully documented requirements:
- Product specification, where requirements are described in detail.
- UI/UX design – software product mockups ready for implementation.
- Acceptance criteria, which define what must be treated as a ready product. They may comprise: checklists of actions with expected results, selected test devices, supported browser and platform versions.
These requirements must either be created by the Client or elaborated together with the contractor, and then clarified and approved. When the scope is fixed, an estimate for UI/UX design and development can be made. The Client and the contractor should know precisely what they want and come to an agreement on it.
2. After the requirements are elaborated and approved, the contractor receives an offer of implementation, which typically includes type of collaboration, goals, a fixed scope divided into milestones with indicated intermediate results, scheduling of work and payments, possible risks and ways of solving them, terms of acceptance, and procedure of work with change requests.
3. A pre-payment is conducted. Typically it amounts to 50%. Further payments are due upon achieving each milestone.
4. The result of each milestone is an intermediate product build with implemented features. It is provided to the Client in order to track the progress.
5. Any change in requirements is handled via a change request – an additional agreement, created by the project manager. Mid-development changes affect the scope and software development cost, and the team makes re-estimations, including them into the change request. Then it either gets approved and signed by the Client, or rejected, and the development goes according to the initial approval.
6. The penultimate milestone results in the alpha build with all the features being implemented. The team makes sure that the product works properly on a test server.
7. The final milestone is refinement and polishing. It results in the beta build (the final build). The product is put into the Client’s actual work environment on a production server. The product starts its work with real users and real data.
8. After the Client is provided with the final build, the acceptance period begins. During this time, the Client checks the product according to the approved acceptance criteria and sends feedback to the contractor. The acceptance period usually lasts 5 days. If there is a bug on an approved test device, or a mismatch with the checklists is found, it is corrected by the contractor and the Client does not pay any additional costs. The time spent on these fixes is not included in the acceptance period.
9. After the test period is successfully completed, the contractor receives the final payment, sends the source code to the Client, receives feedback, and generally finalizes the project. At this stage, the custom product may be deployed on the application store, as a standalone operation conducted at the Client’s will according to the contractor’s standard pricing.
Fixed Price Contract: Pros & Cons
WHAT ARE THE POSSIBLE RISKS OF FIXED PRICE SOFTWARE DEVELOPMENT?
#1. Scope-related risks are carried by the Client. They can be resolved through the abovementioned Change Requests, which in turn affect the cost.
#2. The Client also bears the risks that concern third-party services, which have to work under certain approved conditions, defined by the Client in product requirements. The contractor should be aware of them from the beginning.
#3. Human risk factors are carried by the contractor. They can affect the scheduling, but not the cost of software development. In case a developer cannot perform their duties, the Client is warned, and a substitution is selected.
#4. Risks concerning third-party libraries, services, API, SDK, or other tools selected by the contractor for development, become the contractor’s responsibility. They do not affect the cost.
WHAT’S NEXT?
After the delivery, the Client starts getting feedback, bug reports, suggestions of new features from users, and so on. The understanding of product concept and functionality may change. It may as well be dictated by business and technology. Therefore, the Client has two options: either to continue the iterative software product evolution, or employ the team for minor updates and fixes (usually 10-20 hours per month). The pricing equals the contractor’s standard hourly rate.
CONCLUSION: WHICH PRICING MODEL SHOULD BE USED FOR CUSTOM SOFTWARE DEVELOPMENT?
Agile software outsourcing companies tend to avoid projects with fixed price because there is no changeless weather in the world of custom software development. Sometimes it’s the Client’s will that introduces changes, sometimes it’s a technological necessity or a business condition, dictated by the dynamic market. When the custom product is bound to evolve, iterative development is an advisable solution. It’s faster, because there are no Change Requests and lengthy re-estimations. It shows the progress, because the Client receives intermediate builds upon each milestone.
What’s most important, it allows for changes and flexibility, and immediate reaction to any change on the market. The product’s relevance is easier to maintain. Otherwise, if a particular project fits well into the fixed price approach in terms of both requirements and cost, it surely is the better way for the Client.
