Why Fixed Price Engagement Model is a BIG NO for Product Development

I have been working in the software industry for over a decade and have been part of great products like Frontrush, Coach and Sampleboard. But, can you guess which question scares me most in all these years.

No, it is not technology. Not quality of resources and not even the complexity of software development process. The biggest question that come to haunt me is this:

What will you quote for my product?

Being a CTO of a firm which has helped many startups build successful products, I believe, I am qualified to answer why this question is wrong in the first place and why fixed price engagement model is a completely suicidal approach in the path of building a great product and lead to glitches in client-contractor relationships. In fact my failures with fixed price engagement model have taught me more than anyone else.

We have tried to explain earlier what mistakes to avoid while before you do product development and have also tried which engagement model works best for product development scenario but I felt a strong desire to write a dedicated blog on this topic to clear confusion for all times.

Quoting a Product on Fixed price engagement model is like gauging how many fruits will the little sapling you just planted in your garden bear? Is it possible to predict a count for them?

All you can do is give your best to it, water it timely, add the manure, prune it, and take care of the temperature and other similar needs. There are high chances that your plant will bloom into a full-fledged tree and it will not simply be the fruits, but the relaxing shade too.

Similarly, your product develops and evolves during the various stages of its development and so there are high possibilities that the final product will be absolutely different than what you imagined it to be, nonetheless better too.

The biggest flaw of a fixed price model is the limitation it sets on the quality of work. The bigger flames of doubts arise in terms of overpricing in the mind of the client and under-pricing for the contractor. By opting for a fixed price model, the client eliminates any rooms for adjustment at a later stage. Hence, with a technologically underdeveloped product you are putting at stake your investment as well as the scope of your product.

There are many strong reasons voicing out why adopting a fixed price model will not work for product development.

Challenges in Fixed Price Product Development Model

  1. Product Development is a Constantly Evolving Scenario

    The software development showground has never seen stagnation, your idea turns stale even before it finds a vent to come out of your brain. As the development process moves forward the different layers of your products come forward, some of which might have never crossed your mind. If there are formerly untried options involved in your product and you still want to settle with a fixed price model; then you are certainly compromising on the possibility of building a better application which can be feature-rich and competitive to your technology standards.

    You have to stay innovative and ensure that your User Experience is better than other products trying to compete with yours. In the endless queue of technologies you need not pick one that is latest, rather it should be the one which is most applicable to your User Interface. As mentioned earlier a product changes at every stage and the final outcome might not have an echo of what it was in the conception stage.

  2. Estimations have a Huge Error and Variance Rate

    No matter how detailed and well-planned your RFP there is always space for newer ideas to bloom and enhance your application’s user-friendliness. One cannot cover all the features and functionality related to an application in its embryonic stage. One of the most recurring scenarios with a fixed priced model is the client expecting a mobile site which will also work like mobile native app but he has to settle with a simple form based redirection (from one page to another one); because the budget is a constraint here.

    The error happens because the client just demands for a smooth navigation, overlooking the fact that in order to create a native app which he has in mind, huge JavaScript libraries need to be build which requires professional expertise and of course funds.

    Your highest and lowest estimations might give you a good assessment however, no matter how upright your speculations are, you will not be able to discard a redundant option that you have included in your fixed contract; nor include a really worthy one at a later stage.

  3. Delivery Timelines are at risk in Fixed Price Model

    The difference between the estimated and actual timeline in case of product development is considerable, actually even huge at times. Co-operating with patience and tackling the job with intelligence is the key to a great product. Taking the above mentioned example into consideration, if the client decides to go with the JavaScript Library building option, then it is certainly going to exceed the timeline earlier ascertained.

    Also when working on fixed timelines I have seen clients overlooking some vital points, beginning with simple ones like mentioning ‘Search’ functionality, when actually the expectation is that of ‘Faceted Search’. These minor discrepancies get extended from simple 1 & 2 level of CMS programming to the more complex 4, 5, 6 and even level 7. Now as these levels rise so do the cost estimations and the timeline stretches accordingly, which are often not heeded in the earlier stages. In simple terms a smooth functioning product can be build when you give the required time to it.

So, what exactly is the Solution?

For those not comfortable with going for an absolutely flexible pricing and management model, the hybrid prototype works; as it did for one of our clients.

Take the Agile and Scrum Methodology Route

Also known as the Iterative process this is about continual re-evaluation of every aspect of development unlike its traditional counterpart Waterfall. Scrum being a part of the Agile methodology is preferred more for being uncomplicated. It saves on the time and cost through its inspect-and-adapt approach. The teams are simultaneously collecting requests and carrying out their developing jobs. While the testing and inspection job is taking place at regular intervals, so there is no stagnation to lower the work rhythm and all the alterations happen real-time.

Regular reviewing of the progress of the set sprints, helps in maintaining a dedicated and organized approach. Moreover, there are regular sessions for reviewing the job done and categorizing new sprints. The meetings between the scrum master and product owners proves helpful in exchanging the updates, thus the client too stays informed of his project’s progress.

Choose either Dedicated Resource or Time and Materials (T&M) engagement model

Why Dedicated Resources Price Engagement Model

Hiring dedicated resources who will devote their time and skills to your product development can be a better option over settling with a rigid price and leaving no space for reconciliation later. If you have professionals handling your project with full commitment, then it will take lesser time and with regular updates and feedback sessions, you can avoid piling up of unapproved work.

Why Time and Materials (T&M) Engagement Model

As suggests the name this model works on the time utilization and material or labor input from the contractor’s end. The client stays in control of the product’s progress and this model has proved to be the most customer-centric procedure of software development. The biggest concern for the one outsourcing his product’s development is the budget; however with the time-and-materials billing system you have total clarity on how the resources and time have been utilized towards productivity.

You are being billed according to the time spent on doing your job; there is always the window of getting changes and alterations done at any stage. The first sign of working with professionals is a smaller gap between your highest and lowest estimate.


To sum it all up your product is your baby and in order to nurture it in the best way, you need to adopt the most functional measures. Before finalizing your pricing model you must consider its effects on the product development in the later stages. The more flexibility you keep for yourself, there will be more room to integrate useful functionality which might not have been part of the plan earlier but are now indispensable to the product’s future. Moreover, with a hybrid approach you can integrate different project management styles and make it effective according to your suitability.

Kundan Singh

About the Author

Kundan Singh heads the .NET team at Net Solutions and has over 14 years of experience in Microsoft Technologies. He also heads the Software Engineering & Processes Group at Net Solutions and is responsible for delivering key .NET projects.

Leave a Comment

contact us

Pin It on Pinterest