Why Waterfall-Based Cost Estimation Is Practically Impossible for Modern Digital Products

The Evolution of Complexity in Software Development

Back in the 1990s and early 2000s, simple websites were built using HTML, CSS, and JavaScript. With fewer technologies available and lower adoption in general, software was much less complex than it currently is. That simplicity meant predictable scope.

But in the 2000s, Python 2.0, C#, and JQuery were released, allowing developers to build safer and more robust software and websites. With the release of these technologies, the complexity of software increased. More complex software took longer to develop, and the standard approach to development at the time — the Waterfall methodology — started showing cracks.

Complex projects often resulted in irrelevant software that fell short of customer expectations — by the time the solution was released, the market and customers already had different needs.

Welcome Agile Manifesto

Because of these growing complexities in software development, fixed-price contracts became increasingly difficult to estimate accurately. The need for a change was recognized, which gave birth to the Agile Manifesto.

Following the Agile principles let developers release software in iterations and collect feedback that guided further development. Agility in that sense meant delivering relevant and highly user-focused digital products.

Of course, it doesn’t mean all projects have to be Agile and that the Waterfall methodology is inherently flawed. To learn which types of projects are a good fit for fixed-price contracts, read Waterfall methodology vs Design Thinking, Lean Startup, and Agile.

Note: Even the projects that can be built in a Waterfall model, should be broken up into chunks for the stakeholders to review and give feedback. This helps avoid a situation where the product has already lost its relevance at the launch date (by that time so much development work has been done that any changes are simply not viable financially).

Let's see what may happen if we try to build successful projects in a strictly fixed-price model.

Fixed-Price Model’s Potential Pitfalls

Handing the project to junior developers

When a software agency can’t deliver a complete product within budget, they might restructure the initial team and let junior developers finish the work. This frees up their senior devs to pursue more profitable projects.

Scope cuts or workarounds to meet the deadline

When a vendor nears the deadline but the product is far from being finished, the company might turn to quick workarounds or scope cuts. Quick workarounds make the product unstable and unreliable in the long term. On the other hand, scope cuts result in an unfinished product that doesn’t meet the initial requirements fully.

Inability to get all details prior to project’s kickoff

The fast and hectic decision-making process in software development projects makes it difficult to collect all the details upfront. Even with a detailed specification, there's always some level of assumptions on both sides.

For example, during development, it might turn out that certain parts of the app have to be written from scratch to secure a fully custom code that’s not limited by OS policies or third-party solutions. Another example can be the inability to use certain paid tools and libraries.

It’s close to impossible to learn which parts of the product need a custom approach before the contract begins.

Plugin validation

It’s difficult for developers to validate all open-source libraries and plugins before they actually start implementing them. Conversely, when there’s nothing reliable in the currently available resources, the necessary plugins have to be written from scratch. If the available libraries are outdated, developers have to update them.

This goes on to show just how difficult it is to accurately estimate what will and won’t be available in projects that run for, say, half a year.

Vendor bankruptcy 

If a software agency doesn’t have any inflow of cash and is waiting for product release, it can run out of money to operate and as a result, abandon your project altogether.

With a partially finished product, it might be difficult for another vendor to take over the development work and meet the release deadline. The second team needs to familiarize itself with your business and the product.

Technical lag

Once a fixed-price and fixed-scope contract is signed, you can make very few changes. If a better solution enters the market during development, you’ll still have to go with what’s agreed on in the scope.

A vendor might also use the opportunity and valuate something simple as complex to make up for the loss.

That said, you might end up releasing a product that’s already irrelevant technologically.

Missed market fit at launch

Some complex software solutions take upward of six months to develop. Half a year is enough for consumer preferences to shift. As a result, once you release your product, market fit might already be lost.

What Makes Fixed-Price Project Estimation Difficult

Problems with internal infrastructure

When you want to add a mobile product to your existing infrastructure, this process greatly depends on what’s already there. For example, connecting a mobile app to the backend API is determined by the quality of that API. In this context, the software agency has to work with existing solutions. If these are low quality, this can generate time losses.

Performance issues with existing assets

Working with existing architecture that is complex and influences the performance of the app requires developers to create solutions that improve performance within the available ecosystem. The development of such solutions takes time. This can also generate issues difficult to predict.

Custom integrations

Any integrations with existing systems are tricky to estimate time-wise because they are not repetitive code elements. A vendor can estimate based on similar past experiences, but solutions are rarely the same. Thus, these estimations can compound inaccuracies.

New government regulations

A new regulation that changes how a certain application should behave can go into force halfway through development. The application then needs to be adjusted to meet the new requirements enforced by the regulation.

Third-party dependencies

Most mobile applications rely on integration with other services. When there’s a change in 3rd-party integration policies (e.g., inability to import contact information from Facebook or Instagram), depending on the application type, a pivot or a change in scope might be necessary.

Consider Contract Alternatives to Build Relevant Products

Trends and customer preferences change rapidly. The competition rarely sits quiet, eagerly pursuing new and better ways of serving customers.

An estimate for a mobile app that will offer solutions no one is looking for once it enters the market will be drastically skewed. If you don’t want to drop your idea, you’ll have to act. You will have to include the costs of potential pivots to save the legacy and still deliver a working product that can have a shot at saving ROI.

That said, consider time and materials contracts to retain flexibility and ensure the software you’re building is up-to-date technologically and relevant to your target audience.