Obviously when you go looking for a development firm to build your app, one of the primary factors in making a selection is price - everybody has a budget they need to stick to, and generally when you are signing a contract, you’d generally like to know the price before choosing a vendor.
Unfortunately in the world of software development, this logical approach is hampered by the very nature of the business - it is often nigh-impossible to accurately predict how much it will cost to create your app in advance. Outsourcing firms have been struggling with this issue for ages, yet there is no easy answer we can give to clients who want to know the final price tag of a project before they commit their hard-earned cash to it.
Why is it so frustratingly difficult to get a fixed estimate on building your app? This post will briefly address the nuances of contract estimation on why it’s just so darn difficult to nail down a price before signing that contract.
1) It’s frustratingly difficult to change a contract after its written
Let’s say you are very diligent in writing down every feature, functionality, and design that you want implemented in your app - and that your development firm gives you a solid, accurate breakdown of how much time (and therefore, money) each of those components will require to implement. We certainly appreciate a client who spends a great deal of energy in preparing a plan for what they’d like to build - it certainly makes our job easier!
That being said, I have some terrible news for you - if the app is anything more complex than a few weeks of work to build, I can say with near certainty that your plans will change. More on that below.
Okay, let’s say your plans change. What’s so bad about changing a contract?
In short - renegotiating a contract is a huge waste of time and resources, not to mention a terrible strain on the relationship with your development provider. Every new feature must be considered, and both sides need to commit attention to recalculating the new terms of the contract - time better spent actually building the product. There is almost always a rush for time in these situations, and just when you get everything figured out - something else may go wrong and the whole problem starts from the beginning!
This is why nearly all firms push for Time and Materials (T&M) contracts for the development of any project longer than a month or so. Software development has too many variables to consider and the time wasted on contract negotiation is simply not worth it, for either party.
2) External forces will almost certainly change your app as you build it.
“No!” you say, “I carefully calculated every feature, I know exactly what I want!”
Sure, but do you know what your customers want? Once you build an MVP of your product and start getting feedback on your app, you may be surprised about what sort of feature requests you get and what amazing functionality actually turns out to be completely worthless to the vast majority of your customers.
What happens if a competitor beats you to the bunch and releases a similar product, and you need to pivot into a different niche? Or when you decide to push for a faster release in order to meet a deadline for your investors? Or, heaven forbid, your funding runs out and you need to push the product as-is in order to drum up some cash?
All of these factors can drastically change the timeline for releasing your product, and therefore, the conditions of your contract. Besides…
3) Your own idea for the app will evolve.
I know, I know - you said before that you did your research and you know precisely what you want to build - other factors be damned, you are sure you know every feature you’d like to implement!
However - you’re probably in for a surprise. The thing is that you will be growing along with this app, and you will naturally have new ideas that you want implemented, that you need implemented, which you could never have predicted prior to starting down the long-road of development.
4) A successful app will grow… and grow, and grow!
Building a complex business solution is never an open and shut case. Take a look at every household brand name app on the market and see how many of them have stopped adding features, making fixes, or gone through complete revisions in order to stay on top of their respective spheres.
If you were to ask Brian Chesky, CEO of Airbnb, how much it cost to build the popular shared economy platform, I doubt he could give you a fixed price - because they’re still building it! At this point, they’ve most likely spent millions of dollars making Airbnb the platform it is today, by employing hundreds of developers in their engineering department, and there is no sign of those costs stopping any time soon - not if they want to keep their market share and stay competitive.
I always shake my head when I see firms quote hard prices for building the “next Uber” or “a social network site like Facebook” because they grossly underestimate the commitment required to not only build but maintain and improve on a successful app. Rarely does a hit app ever truly get to the point where further upgrades and versions are no longer necessary - otherwise they’d stop being used in favor of their competitors!
This is why the T&M model is actually far more meaningful and useful to product owners - they can accurately predict their monthly costs and compare them with their anticipated revenue. That being said, a solid development firm will be happy to give a time estimate in man-days for implementing a given feature, once you decide which features you and your customers want. However, a development firm can’t predict everything you’re going to want to implement in advance, so it will be impossible for them to state a final price for what you want to build.
There is a time and place for fixed price contracts
It would be disingenuous of me to say that there aren’t situations where a development firm can and should provide a fixed price to a customer. Let me briefly go over some possible scenarios:
- Small, simple projects that are routine and easily replicable. For example, we will always provide fixed rates for clients seeking to have us do a test task for their platform - these are often a week or so of work and have very clearly detailed specifications due to the size of scope.
- MVP’s. In the case of some startups, there is a hard deadline and budget limitation which demands a relatively fixed budget to produce an MVP. This MVP doesn’t need to be perfect, merely functional - and it’s agreed upon in advance that no additional features or changes will be implemented beyond what is agreed upon during the initial planning phase.
- Fixed time maintenance/support contracts. Often a client will simply need someone to manage an existing platform, fix bugs, and respond to severe crashes if they occur, and they have a set period of time they need this coverage. One-off apps for special events, for example, may fit into this model. In these cases, a fixed contract length (and therefore, price) can be negotiated fairly easily.
Conclusion
It’s a common belief that development firms like the T&M model and fuzzy price estimates because it allows them to exploit a product owner and milk them for all their worth. However, in the highly competitive world of outsourcing, such firms rarely last long. As long as you conduct due diligence, you will be able to find a company that can provide you a solid time estimate and deliver constant results which you can track, ensuring that you’re not getting fleeced and are actually receiving a quality product.
