So you’ve started talking to a few app development agencies and kicked off the process of evaluating them and deciding who will be your vendor. Don’t be surprised if you receive some very different estimates from the different companies you engage with. It’s actually very common to find yourself with (for example) a 200 hour estimate from one company and 800 hours from another, based on the exact same brief. How can you compare estimates that seem so different? There are various reasons why this happens, which I’ll discuss below.
The main thing to remember though, is that this is not an unusual situation. Ask questions. See if you can work out why that difference exists. Make sure that you’re going to get both a fair price and a quality product.
Compare the contract types
It can be helpful to start by checking that you’re comparing the same sorts of contracts. Fixed price contracts propose a total sum to be paid for a fixed scope of work regardless of whether the developers manage to do the work in the estimated time or not. This incentivises developers to estimate accurately and means that you can have confidence in exactly what you’ll get at the end of the process and exactly how much it will cost you. One downside though, is that often the vendor will over-quote to allow themselves some leeway. With a time and materials contract, in contrast, you pay only for the work done. At the same time this style of contract leaves the door open for dishonest vendors to deliberately mislead clients about the amount of time a project is likely to require.
Beware bad actors when you compare estimates
We’ve actually seen this happen to a number of unfortunate businesses. They turned down our seemingly high, fixed price quote because another vendor offered them a price based on a much lower number of hours on a time and materials contract. They base this estimate on the easiest possible version of the project and either don’t provide a ‘maximum’ or project an unreasonably low ‘maximum’ figure for the project (either way, they’re not bound by the estimate because the project is done on a time and materials basis). Once the client fully committed to the vendor it only then became clear that their original estimate was much lower than required and with hourly fees they soon ended up paying much more than our original ‘high’ quote.
What causes the difference?
Assuming though that everything is above board and you’re comparing the same sort of contracts, you’re still likely to find quite a bit of variation when you compare estimates. Here are some of the reasons that might be the case:
First off, they may have different assumptions about or approaches to the same bit of functionality. An original way of solving a technical problem quickly might put one organisation in a position to make a lower offer because they know they’ll be able to handle the work at a faster rate.
Similarly, if the developer has already made apps with the same or similar functionality, this experience might give them confidence in their ability to do the work more quickly. Depending on the relevance and legal status of the code, they may even be able to use past projects as a starting point for new work.
Secondly, it could be that one or both of the agencies has simply misjudged the complexity of the task. Sometimes the implementation of a feature turns out to be more complex or time intensive than expected and the opposite can also be true. Ask the company with the longer quote about why it will take so long, then (armed with info.) ask the other vendor how they anticipate solving the problems mentioned.
Thirdly, accurately estimating the number of hours involved in a project that might last for many months is a tricky task and sometimes the developers themselves over or underestimate their own work speed. The larger the project scope, the higher the potential for these sorts of errors. At ekreative we have internal tools in place to help improve developer time estimates, but even so we’d always remind you that an “estimate” is exactly that and shouldn’t be treated as a final number of work hours (though if you’re on a fixed price contract, it won’t affect you anyway).
Taking it further
If you’ve got any questions about how to compare estimates or development contracts or you have advice of your own to add, please do write in the comments below. And if you want to get a quote from us for some development work you’ve got upcoming, get in touch now.
If you want to read more about the app development process, check out my last article on how to choose the right vendor or my intro to the topic of developing apps which contains a list of the topics I’ve written on and links to the relevant articles.