Introduction
Long-term budgeting for web and mobile apps is crucial in determining if your company has the resources to sustain what it is building. The work that takes place after the initial launch could determine the success or failure of your project. Consider the difference between a wedding and marriage for analogy. The work completed prior to the project launch, is the wedding. What remains after the launch, is the marriage. Unfortunately, planning for that is often a missed step.
The How and What of Budgeting
Estimating how much to budget for software updates will often depend on the business purpose of the project, the dynamics of your business, whether the initial launch is intended as a proof-of-concept or a minimum viable product, the competitive space, and a number of other factors. As a starting point for your discussions, consider a project that has a known finite set of requirements. In this case, I recommend budgeting annually 20% of the cost of the initial build-out project. For example, if a project costs $100,000 to build, then start with a budget of $20,000 annually for updates. The important point here is that your team works through the long-term costs of budgeting for web and mobile apps.
What types of updates should you consider for budgeting purposes? Details will vary, but updates will generally fall into the following buckets:
- Enhancements
- Security and Bug Fixes
- Ecosystem Updates
Enhancements
No matter how many rounds of reviews you have before launch, important aspects are still likely to be neglected. Considering all the angles and possible conflicting interests, coming to a consensus on how an app should function is challenging. Also, people who feel threatened by the changes imposed by the new project may not be forthcoming with feedback. Inevitably, you will get feedback that something is not working as expected or could work more efficiently, if done differently.
Over time, you may also discover that people are using the app in ways that you had not anticipated. For instance, you may learn that people are using it in unexpected ways as they compensate for missing workflows. Or that people are using it to solve business problems that were not previously in scope.
Also, as business processes change, partnerships are formed, opportunities arise, new legal and regulatory requirements are enacted, and a host of other dynamic activities take place, your app may require changes to continue to serve its purpose.
Budgeting for these possibilities is essential.
Security and Bug Fixes
Over the last 20+ years I have had the good fortune to work with great software and quality assurance engineers. Sadly, I do not recall launching any software that was free from defects. The specifics for each failure are unique but are generally due to a combination of insufficient test coverage and inadequate test environments.
Test coverage refers to the area which testing will cover, namely the test cases and device configurations used while testing. For example, for a “To Do List” web app this may include testing the “Sign Up” and “Sign In” process on Windows 10 with Edge and Chrome and on Mac OS with Safari and Firefox.
To validate these tests, engineering teams create test environments that mimic the real world as closely as possible. However, due to the complexity of the real world, test environments are rarely accurate reflections of reality. Even in instances where test coverage is sufficient, running those tests against unrealistic environments leaves room for defects. Large, feature-rich app, with lots of users and third-party data dependencies are especially prone to defects.
Although having a test plan will help considerably, the odds of releasing defect-free software are not favorable. Most defects will be observable immediately after your launch, but you should prepare for defects well past that date.
Unfortunately some of these defects are potentially exploitable, rendering them as security risks. Planning security audits before launch will help to expose vulnerabilities that engineers can then patch. As with other defects, prepare to address security defects well after launch. One of the culprits for this is our next topic, Ecosystem Updates.
Ecosystem Updates
Software Ecosystems
The term “ecosystem” refers to the environment and all the dependencies that software needs to exist and function. For example, a mobile app ecosystem will include the following:
- the host operating system that is running the app (examples: Android and iOS)
- the development frameworks used to create the software (examples: React Native, Java SDKs, etc.)
- third-party service providers (example: Amazon Web Services)
- databases, servers, and other infrastructure
Developers build apps leveraging a lot of third-party software components. For example, a “To Do List” mobile app may have 200+ third-party dependencies. Those dependencies have their own development roadmaps that are frequently updated to fix defects and add features. Keeping up with the dependency updates is a critical part of making sure your software is secure, reliable, and maintainable.
Fragility of Mobile App Ecosystems
Mobile apps in particular are more fragile due to their ecosystem. While desktop and web apps need to be updated regularly—if for no other reason than to plug security holes—they generally reach a state of maturity and stability where ignoring the need to update may not have functional consequences for the end user. That is, unless the app is 5+ years old, the environment in which it runs, such as Windows 10 for a desktop app or the Chrome browser, will continue to support the app [disclaimer: in no way do I recommend ignoring the need to update].
In contrast, mobile ecosystems evolve at a much faster pace than desktop and web environments, and the companies that have created the mobile operating systems (Android and iOS), their software development frameworks, and their app stores, have a keen interest in increasing the adoption of their ecosystems. To make their platforms more appealing and secure they frequently introduce new features and remove old features. The only way to guarantee that your app will continue to function as intended is to keep it updated.
Conclusion
Long-term budgeting for web and mobile apps is vital. Plan for software updates, ideally before you embark on a new project. If your project is already live and humming along, I hope I have convinced you to at least consider working with a software development shop to plan for updates. The risks of not updating your custom software include having your app lose functionality, exposing your users and business to security vulnerabilities, and/or possibly having the software reach a legacy point where an update becomes untenable and a rebuild is your only option forward.
Please contact us if you would like to learn more about budgeting for web and mobile apps or need planning assistance.
