When stakeholders discuss the cost to build a solution, many limit consideration to the launch budget. Veteran teams know software maintenance costs must be factored into the planning phase. Without digging into expected traffic, supported devices and other factors that impact expenses, teams risk building a solution with upkeep that threatens the financial security of the business.
Ask these 4 questions before beginning development to better predict software maintenance costs in 2017.
What Devices Will You Support at Launch and Continue Servicing as Your App Matures?
There’s a direct correlation between the number of supported devices and the cost to build a solution — more supported devices means a higher cost. This holds true for a variety of reasons the most obvious being quality assurance. More devices equates to increased hours testing required to validate that interactions and functionality perform as expected across supported devices. If discrepancies arise, more time must be spent troubleshooting and retesting. Then if/when functionality is added, regressions should be performed over supported devices. More devices means more regressions, which equates to a higher cost.
Teams who approach app development with a highly-defined user base and an understanding of the devices most used by this audience can save on development, eliminating support and widespread testing for devices not commonly in the target demographic.
That said, this can (and will) change. Unexpected combinations of variables including device, carrier and operating system can expand the expectations of the app beyond the combinations it was designed to support. Having a starting position will guide the team’s decision making to troubleshoot and release fixes.
How Much Does User Traffic Impact Software Maintenance Costs?
Defining user traffic will significantly impact decisions about where and how you host data associated with your app. Does the product team expect to house large quantities of records in the database? Will content from your app also be published to the web? What functionality will be of most interest to users?
Data is expensive to store. By selecting a method in line with user adoption expectation, teams can avoid paying for more robust storage that wouldn’t realistically be needed until higher traffic or adoption levels are reached.
How Frequently Do You Plan to Release Updates?
To manage software maintenance costs, settle into a long-term rhythm respectful of existing team bandwidth. Rather than launching an app with all imagined functionality, many businesses opt to develop an MVP version (Minimum Viable Product). They build the leanest iteration of the app to test value, appetite and behavior with real users. It’s especially important to groom the backlog and plan your product release schedule after MVP development.
Find a balance between perception and need. Enhancements and bug fixes up to once a month will maintain interest in your app, anything more can be perceived as “buggy.”
Product teams must balance proactively responding to user feedback with obnoxiousness. Users’ ability to tolerate updates can depend on the user’s vertical.
Take PokemonGo for example. The gaming audience generally expects updates, especially if a game gains popularity quickly and tests the load expected by the development team. This audience will likely clamor for new features. They are willing to forgo the minor hassle updating presents to test new experiences within the app.
What Happens If Disaster Strikes?
Having a separate complete version backups in different physical locations and a documented disaster recovery plan can mitigate costs if worst comes to worst and the internal servers where you store the latest version of your solution become corrupted beyond repair.
In the simplest sense, keep a copy of everything needed on the build machine to recreate the released app and supported versions. Store them in two separate places. That way your investment and reputation is safeguarded.