First, it's important to understand the difference between custom application development and off-the-shelf applications. The latter has usually been tested for many hours and used for many more hours by the time you start using it. So there will generally be very few bugs remaining - if any at all. Applying the same expectation to an application that did not exist a few months ago is setting yourself up for disappointment.
Testing
You need to make sure that your developer and you share the same definition of “launch ready”. Does it mean finished development and internal testing - which is what many developers will consider finished, or will you not consider the application finished until it’s completed beta phase or even not until it’s ready for a full production launch? Because then you need to ensure that these post-development testing cycles are included as part of the project scope.
Testing takes time. A lot of time. And sadly, it’s one of the first corners to get cut if a project is running out of budget. Your project estimate should include at least 20-30% internal testing budget and an additional 100% on the timeline for testing after development before the project is considered production launch ready. Even after it has launched you need to factor in time for monitoring and debugging.
These testing cycles will make the full project timeline 140% longer than just the development phase. For example:
- 5 months of development and internal testing
- 2 months of closed group testing and fine-tuning
- 3 months of beta with minimal promotion and marketing
- Production launch then 2 months monitoring and fine-tuning
Most clients will receive a developer estimate that only covers the first 5 months and they will assume that this is the point when they can do a full live launch and start making plans around that date. This obviously leads to disappointment and frustration at how buggy the system is.
Why does testing take so much time?
This will in part depend on the devices to be supported. The easiest to test with the least amount of time is an iOS app. This is because the iOS devices are fairly limited and usually you would only target the newer versions making it even less devices you need to support.
But lets look at a web application example, one that needs to support desktop, tablet and mobile. That can be easily 10 resolutions, 4 operating systems and 6 browsers or a total of 240 combinations - although some browsers will not be available or not common on some operating systems. If you start factoring in support for older browsers, toolbars and plugins that may affect the application this number grows exponentially.
Changes
Besides factoring in the post-development testing cycles, you also need to factor in changes to the application during development. Solution Architects aim to minimize such changes by planning ahead as much as possible and foreseeing potential issues before they occur so they can be dealt with more efficiently.
But most people need to see and use something to come to the conclusion that they actually want something different or added. A good development estimate will include margins for this but margins are basically nothing more than a best guess based on experience and risk evaluation. They are not a certainty and the developer has to balance margins with competitive pricing making them even less reliable.
You will need to manage your own expectations for project changes. Assume that you will want to make changes and additions during development and assume that the estimate was not margined sufficiently. In your mind you should always add another 30% to estimates and make sure you still feel comfortable with that amount and timeline. If not, then consider removing functionality to lower the estimate closer to what you feel comfortable with. Any remaining budget at the end of phase 1 can go towards phase 2. If you have a lot of changes during development you will have a lot more flexibility to deal with those changes without going over your budget or deadline. Either way, the result should be more in-line with your expectations and the experience far more enjoyable.
To summarize
- Accept that custom applications will have bugs and you will need time for sufficient debugging and testing
- Confirm with your developer if the estimate is for development and internal testing or if it also includes closed group, beta and production monitoring phases. If not then you will need to adjust your timeline accordingly: +40% closed group testing / debugging, +60% beta debugging / fine-tuning, +40% post-launch monitoring / debugging / fine-tuning.
- Always add 30% to an estimate (in time and cost) for your own safety margin. Adjust the requirements of the project to fit within your available budget including that 30%. Unused budget at the end can always go towards additional features once phase 1 is completed.