Following on from our recent post “How much does it cost to build an app?” this article aims to help you understand the costs of running a digital product, once it’s live and in use.
When you are planning a product build, it’s easy to focus on the upfront price and forget about the potential impact of running costs. This article will explain some of the more significant costs and provide some tips on how to minimise them.
Ongoing costs of owning a product
So you’ve created a new digital product, it’s the app to end all apps, and it’s ready for your users to get started. Hopefully, you’ll already have considered some of the following areas. If not, this article should help you prepare for talking to your development team about controlling these costs.
Bug fixes and issues in live
The first, and most obvious consideration is what you might hear described as “Support”. Once your app is live, you will need bugs fixed, problems solved, and probably questions answered.
Usually, you or your team are the best people to answer simple questions, and if you have a control panel, you can probably manage things like account access issues. This is usually referred to as “First Line Support”.
However, if you run into more significant code issues or unexpected usage scenarios, you might need a developer. You will want to have a support contract in place to ensure they respond when you raise issues.
There are obviously variations on the theme, but broadly speaking, a support contract between you and a developer is like a safety net. If you should have any problems, they’ll be on hand to help you out.
How much you pay for support is usually based on the size and complexity of your application. A simple calculation of 20% of the development spend should roughly equate to how much you can expect to spend per year. For example, if you have spent $75,000 on design, development and testing to get your app live, you can expect to spend $15,000 per year on support, or $1,250 per month.
You might think that you can avoid this cost with lots of Quality Assurance (QA) or User Acceptance (UA) testing, but there will always be something that happens in live that you could not have predicted. To deal with this, you need a team on hand who can resolve those issues for you in a timely manner.
Regular releases
Once your product is live, it’s likely you will have either a roadmap of development you would like to do, or at the very least a laundry list of tweaks to make. This means you’ll want to be releasing updates on a regular basis to your customers. We usually recommend bi-monthly updates as a good interval that won’t annoy your users.
Each time your development team does a release, they will need to plan it, perform it, produce release notes and perform related tasks. This will mean a cost to you on each occasion. Your support and maintenance agreement might cover this, but if not, costs could mount up.
You should work closely with your development team to create a Continuous Integration (CI) process that will significantly reduce build and release time by using automated processes. This will mean a little more cost at set up, but long term, a much smoother release process. Also, make sure your product can be released at any time by using feature branches to keep unstable code out of the master branch.
Software upgrades
The tech industry is extremely fast moving, with the big tech firms producing major new versions of their technologies at least once a year, if not more frequently. So things like iOS apps, Android apps, Angular, React, etc. will need regular updates so they can remain relevant, secure and stable.
Each time you do an upgrade like this, your app will need to be retested, so as well as the development to do the change, you are looking at the cost of at least a partial regression test. This obviously sounds like an expense you can live without, but the risks of not upgrading are far higher. If you do not upgrade your app you risk:
- Google or Apple blocking you from releasing to the App Stores
- Security flaws that cannot be rectified
- Bugs in dependent packages that aren’t going to be fixed by the provider
- No upgrade path to later technologies if you get too far behind
- Expensive re-writes when the app becomes obsolete
- Inability to integrate with third party systems due to limited accessibility
- High cost of change for even small changes
- Access to fewer and fewer developers with experience of the ageing tech in use
Plan to perform small upgrades at least once a year to avoid large and unexpected bills when things stop working.
Hosting
When it comes to where you host your product, you have a lot more control. Depending on your situation, you can:
- Self-host if you have server capacity available to install your application, and it only needs to be accessible within your organisation – this can be a very low cost, as you already have the server
- Cloud-host if you have access to Azure or AWS or similar, and can install there – the cost is based on what technology is used, the number of users or the level of usage
- Data-centre host if you have access to rack space in a data-centre – the cost may be low, as you already have access, but the capacity might be limited
If none of this makes any sense, don’t worry! The important thing to note is whether you have known access to any of these options, as you will need to tell your development partner as early as possible, so that they can build your software to be compatible with it.
You may not have access to any of these hosting options, in which case you should talk to your development partner about your expectations for the product’s availability, capacity and performance, so they can make recommendations for the hosting.
Performance level increases
Hopefully, over time your application will grow and acquire more users and eventually you will need to enhance it to support the additional load. Of course, the work involved will depend on where you started – whether your application is an MVP, or a mature product.
Your application will have been built with a level of performance in mind, and all things being well, you will exceed this at some point. If you don’t keep on top of the enhancements, your product is lightly to become flaky and crack under the pressure of the load. At this point, the cost of changing the application to increase its performance will be massive.
Plan ahead and review the application’s performance once every 6 months, depending on how your user base is expanding. This way your development partner can make small changes over time to keep on top of changing requirements.
Summary
You’re probably terrified now about the costs of product ownership over the long-haul but the key to manageable spend is planning ahead and making regular small changes. If you can keep on top of everything, the cost will be much lower and you will be spending as your product grows, gains users and hopefully generates more revenue.