Generally speaking, one of the first things our potential customers are interested in when contacting us is a ballpark estimate on how long the project will take to build, and of course, the associated cost. This can lead to a rather funny exchange which I’ll paraphrase below:
Customer: Hey there - I’m looking to build this particular app (insert idea here).
Us: Great, we’ll be happy to help! Do you have a particular budget in mind?
Customer: Erm, no… could you tell me how much it costs to build an app?
Us: That depends entirely on what features you want to implement, your timelines, etc.
Customer: Well, could you tell me how much it will cost approximately based on the idea I told you?
Us: Not with any degree of accuracy. Do you have designs or mockups you could share with us? Technical scope documents? Some list of specific functionalities the app should have?
Customer: No, I figured you’d be able to provide that.
Us: We certainly could, but in that case, we won’t know how much the cost will be until we do that assessment.
Customer: Well, look, my app is pretty similar to (insert established app that’s been on the market for 5 years already). Could you tell me how much it would cost to build something similar?
Us: Well… that app has been in development for several years, has a technical team of 50+ engineers, and is filled to the brim with features, integrations, and cross-platform support. They probably spent millions of dollars on development at this point.
Customer: Okay, but...can’t you just tell me how much it would cost to make something simpler?
…
I had this exchange on a weekly basis with potential clients, which you can guess - never ended well. Then one day, I got wise to the situation and, seeing the flaws in this approach, started proactively guiding folks away from this sort of “fixed-price” mindset (which I wrote a different blog post about) and more towards an agile, development-as-a-journey approach that reflects much more realistically on what it means to create a successful platform for end-users.
A Developer’s Work is Never Done
The first thing to keep in mind is that most software applications are living, breathing beasts for the most part. If you are looking to put together a SaaS-type platform that people will regularly pay money for, you should immediately dispel any notion of a platform that will be “finished.” That is to say, something that will reach a point in development when it will no longer require any further work, and it will just function into perpetuity, and you can just lay off your tech team because the platform is “done.”
The subscription business model works because users are willing to pay for a continually evolving and supported platform that has all the latest integrations with popular 3rd party services, payment support, and features that keep it above its competitors on the market. When development stops, the market catches up, and things start becoming obsolete - whether it’s the framework the app uses, its features, integrations, or even the app itself.
Therefore, it’s important to avoid the mistake of estimating for a finished product that may never be well and truly finished. Instead, it would be best to look towards the first major milestone - the MVP or first release.
MVPs - estimating for production-ready
Having a clear idea of the core features of a particular app will help you identify what needs to be in the minimal viable product - or MVP - of the platform. This can significantly help estimate the initial phase of development and what will be required to put the app in front of users and even monetize it.
By narrowing the scope of the platform to its essential components, it may be possible to get something into production in a matter of weeks or months as opposed to years. Once a platform goes live, and users begin to interact with it and provide feedback, you may find that some of the “major” features you are interested in aren’t actually needed or even desired by your clients - which means you avoid a lot of wasted time (and of course money) in developing those features that weren’t required in the first place!
Avoiding the Chicken Game - state your budget and deadlines.
There’s an adage in sales that whoever is first to mention a price will lose the negotiation. However, in the world of software development, this is a rather unnecessary point to dwell on. There is an app for every budget and every development firm worth their salt will be clear and upfront with their prices from a T&M perspective. Good development firms are not in the market to fleece clients and stretch out development longer than necessary - it’s a cutthroat market, and any established software engineering company would quickly fall to the wayside if they either overestimated a project or underestimated and failed to deliver on time.
You can save a lot of time and energy by simply stating your approximate budget upfront to see if it's at least in the realm of what can be expected for a first development cycle. The same is true regarding timelines - if you have a hard deadline you must meet, such as finishing an MVP to present to investors or before the peak season for your particular business, it’s better to know that at the beginning so that the development firm can take that into account when putting together a team.
If you are still concerned that a firm will exploit this information to increase its own margins, you can start the negotiations off by inquiring what the development firm’s minimal contract obligation is. Most established firms have a minimum contract commitment in mind that they will consider when starting any new collaboration with a client - anything less than that isn’t within the scope of what the firm is willing to engage in.
This will essentially allow you to see the starting price for a particular engagement without “showing your cards” to the firm. If this minimal obligation isn’t within the ballpark of what you can afford, you can move onward to other options quickly instead of getting bogged down in sales pitches from a company representative.
Sticking to Estimates - how to ensure promises are kept
Besides inflated estimates, the next biggest concern clients have accountability. How can one be sure that the developers will meet the estimates they put forth? After all, working on a T&M contract means that the longer they’re on the contract, the more money they’re going to make. What assurances can be made to protect the client from this exploitation?
In these cases, it’s prudent to establish a few things:
- The platform should be broken down into a list of individual features and functionalities, with separate estimates for each item.
- There should be a trial period in the initial part of the engagement, which allows the client to stop development on short (1-day) notice if they’re not happy with the progress.
The idea here is to provide some first-hand evidence of a development team’s ability to stick to their own estimates and deadlines while providing the client the ability to cancel a contract early if things aren’t going as planned. Since most T&M engagements will have a cancellation notice (on average, 30-60 days), clients are reluctant to get “married” to a development firm without having some firsthand experience with them.
While there is still some risk inherent to this mode of engagement for both sides, it allows both parties to start small and get a sense of working together before fully committing to a long-term engagement. Clients get to see whether a development firm is honest in their individual estimates and are essentially on the hook for just the work that has already been completed.
The biggest downside of this approach is that it takes considerable time and sometimes research from the development firm to make such an in-depth estimation in the first place. At Binary, we have a process called Inception, which precedes the actual start of development, which produces such estimates. It’s a paid process that takes up to a week to conduct and requires close communication with the product owner to produce an accurate final roadmap for development.
While there is still time and money investment from the client to create such a detailed proposal, it’s a fairly minimal amount of resources in the grand scheme of things. Also, it provides a clear picture for clients who want to have a plan laid out before committing to the start of development.
The Devil is in the Details - other things to keep in mind with estimates
Beyond these basic points, there are several other factors for product owners to keep in mind when requesting or making estimates.
- The more information you provide about your vision for the app, the more accurate the estimate will be. Wireframes, mockups, technical scope documents, requirements - giving this info to development firms will help take the guesswork out of estimates and allow them to commit to a tighter overall estimate. It will also help developers work more efficiently since they’ll be able to digest what needs to be done before starting work and save you time in briefing them on your ideas.
- There should be a clear and honest assessment of how essential QA processes are to the initial development project to weigh them accordingly in the estimate. For some clients, time is the priority - they are looking to release as quickly as possible. Their end-users might be internal employees who are more willing to tolerate bugs or incomplete features than paying customers. Other product owners might need an airtight app for use in the medical or financial sphere, so 100% test coverage is mandatory. Making this clear to the dev firm will greatly help with providing accurate estimates.
- Boilerplate estimates provide a ballpark figure and help development firms and potential clients screen each other - they are generally not accurate and should be construed as such. Just because an MVP for another platform took 3 months does not mean your MVP will take the same amount of time. But if you have a budget of 5k, and you see that on average, MVPs from a firm will take anywhere from 30-60k, you know that you need to either look elsewhere for a solution or increase your budget.
- Be wary that every estimate is, by its very nature, an educated guess. From the developer's standpoint, there can be unforeseen issues that crop up - either oversights on the engineers’ part or simply external factors which couldn’t be predicted. From the client’s perspective - any changes or new features added to the app during the development process will undoubtedly move the deadline back. Also, keep in mind things like vacation days, holidays, sick leave, etc., when calculating how many calendar days will be necessary to finish the development cycle.
Wrapping Things Up
Estimates are a natural part of starting a collaboration with a development firm. While there is a degree of uncertainty involved, they still play a key factor in determining which development partner you should select in starting a partnership with. By following the above guidelines, you can ensure the greatest degree of accountability and planning and rest easy. The estimate you received paints a reasonable picture of how much time and resources will be required to get your platform into production.
