“How much will it cost?” is usually one of the first questions we get asked when it comes to app development. Many customers declare they have no clue, which is fair enough. Others just don’t want to divulge what they’ve set aside for their app budget either for commercial reasons or fear of being wildly wrong. Some give you a discounted number so they’ve contingency set aside. There are all sorts of tactics deployed to avoid being taken for a ride by a 3rd party software vendor - for understandable reasons, too. The problem is, however, that without intelligent preparation and/or a healthy tolerance for assumptions, your budget will always be wrong.
We’ve looked at our actual client spend vs their original budgets for projects over the last couple of years and our analysis shows some common patterns of omission, process and attitude that consistently deliver inaccurate budgets for the development of apps. The margins of error can be staggering (>100%) in some cases.
Here we’ll highlight the top 5 things to do to avoid being way out on your app budget:
1. Don’t take a half-baked idea to market, you’ll get burned. We see examples of tenders that describe the required app in a matter of paragraphs, with a budget of £
* is usually a very low number). Suppliers can’t accurately bid on this basis, and you may as well start preparing for that awkward ‘re-budgeting’ discussion now - it’s gonna happen shortly after the champagne corks have popped at the contract signing. Instead, start your app journey with a different question. Instead of “how much will it cost?”, ask how much do i need to spend to quickly develop
robust functional requirements? Investing a little here up front will drastically reduce the contingency, risk and error margins going forward. If you then take these to market (in an RFP for example) your much more likely to be comparing apples with apples
2. Front-load and invest in
_up-front strategic thinking, design and prototyping. _Often app costs are seen as exclusively software driven, which is simply not true. Time and money spent on strategy and design might just be the most important investment you’ll make in the whole process. Developing testable prototypes will give you the critical feedback you need to take your product into the field or market. As a rule, you should be investing [
*]% of your budget into this phase.
3. You are going to
unit test this thing before you release it, right? Hardly any of our clients ask about the testing phase - and it’s so critical to the enduring success of your app. You’ll save a lot of money, risk and heartache if you unit test this baby properly rather than squashing loads of bugs later down the line.
4. As our client,
you are the most important collaborator - for expert input, sign-off and other resources (e.g. data, APIs, infrastructure capacity etc). Not understanding these inputs and dependencies has serious repercussions for the budget - both the fees you’ll pay us, but also the internal costs to you in your day to day business. Just think, in a fortnightly sprint cycle, you’re going to need decision makers, experts, users etc to be available to help keep the pace of development going and make key decisions.
5. All the cost is related to the mobile app and as they’re free in the app store, they must be cheap to build, right? Nope. Firstly, many apps demand significant back end development to ensure the app delivers a great, integrated service on the device and in the cloud. So you’re non-device development costs could be substantial. Secondly, mobile apps are increasingly prevalent in mission and business critical environments and as sophisticated as anything available in ‘traditional’ desktop markets. If anything, investment in a mobile platform will be the most strategic investment you’ll make this year - so don’t do it on the cheap.
If you want to make sure you’re App-fit for 2018, and that you’re properly budgeting for your apps this year then we’d love to hear from you and give you some expert guidance to help you make sure you maximise your app ROI.
<!-- [if lte IE 8]>