How to Visualize Your App’s Google Play Store Metrics in Looker Studio
Android App Development
Software is just like anything else you can possibly own – keeping it in tip-top shape requires regular maintenance. Much like how your home will eventually need items repaired or replaced, from roofs to refrigerators, it’s critical to plan for app maintenance costs to keep it up and running.
Nothing stays shiny, new, and perfectly operational forever without care – this is just as true for apps. At Blue Label Labs, we cover this topic during our design sprints when spend a week working with you to create and test the prototype for your idea. However, the cost of maintenance is different for every app as there are a ton of variables so we’re going to look at the baseline for figuring out long-term costs.
The bedrock of app maintenance: distributing investment funds and app revenue
When you look at software, regardless of whether it’s a mobile app or something else, it needs to be monitored and cared for. Just like you have to remember to change your furnace filter and feed your dog, software is subjected to various costs that surface at different intervals in its lifecycle.
For HVAC systems, the degree to when and how you perform maintenance depends on multiple variables. The amount and frequency you feed the dog depends on the size and breed of the beast.
Of course, your app is (or should) be designed to be monetized. Your heating and cooling system might save money if you’ve recently installed a more efficient system than a previous unit. Your dog probably won’t ever make a dime – although I did hear from an employee how his buddy’s dog won some “first place” award while they were at a music festival that paid for their beer.
Generally speaking, most pets are in “the red” if you look at their earnings against your expenditures.
You build an app to generate revenue or at least deliver content as part of your sales funnel and customer journey. As such, there are different business techniques that need to be considered in every situation – you can’t always rely on the revenue you’ve projected you’d make to cover expenses as sometimes even the best ideas don’t translate to quick money.
Like ‘yin and yang’ or the Force from Star Wars, there’s a balance to learn how to allocate existing funding, properly spend revenue you generate and make the best decisions to scale based on backend requirements, new features, and financial resources.
In the beginning, you’re likely going to need extra funding to cover expenses from early growth. Often, revenue has to be immediately reinvested to cover overhead – don’t count on these earnings to cover every cost. Plan on setting aside some of your funding to cover costs for additional resources and development needs.
Maintenance costs to consider when building an app
Initial development and procuring the right equipment – or more than likely, finding the right hosting provider – is where it all starts. Down the road, it’s about maintaining code and adapting these systems around your growing user base.
Let’s look at some of the most significant costs with maintaining an app, starting additional or new development costs. Next, we’ll look at backend costs for cloud hosting services.
Additional development costs
Ongoing costs for development are a necessary item to plug into your budget. In terms of additional development, these are some of the most significant in terms of cost to maintain an app.
Accommodating new features, OS updates, and new devices. Of course, a successful app will require additional development in time. This could be for new features that are rolled out in time. Too, new devices and updates to operating systems sometimes require tweaks to the code to accommodate device form factors or new features in a platform update.
There are other issues that arise when apps are used for enterprise applications and managed by a mobile device management (MDM) solution. Aside from platform updates, certain policies that change require tweaks to code or within the MDM console. While some policies can be updated without altering code, there are some cases where policies and app code (depending on the solution) can conflict – in some cases, these issues can be resolved in the MDM console but other times, code needs to be altered.
Apple Annual iOS App Store changes. It’s borderline painful to even type“iOS App Store” changes as this is one of the most problematic issues for customers and developers. In our experiences, this is a bit unpredictable as they will deprecate frameworks or force compiling standards, demanding emergency intervention.
Sometimes iOS version changes that come out each year might break an app. In the past, Apple has forced apps to use HTTPS and ousted components like the traditional web view. In other cases, new capabilities that might benefit an app, such as the dark mode introduced in iOS 13, won’t break an app but requires small changes in-app so a user can take advantage of the feature in your app. If these issues aren’t mitigated in a timely fashion, it can result in Apple flagging an app as obsolete and pulling the app from the store.
Third-party plugins for your app on Android, iOS, and Windows are subject to the same kind of issues. For example, Google Places just recently force upgraded the software development kit (SDK), creating a scramble for developers as apps using the deprecated version suddenly stopped working, basically the coding version of Indiana Jones in “The Temple of Doom” sliding under the closing door then reaching back to grab his hat just before it crushes his arm.
This exact scenario just occurred at Blue Label Labs with a project last week. This meant we had to quickly rebuild and review an existing app before Google kicked it from their store.
Not paying attention to minor OS updates. If a team is not testing and updating their app for the new version of iOS then they might find their app has suddenly broken with the new version of iOS. It’s vital that your team, or at least one designated person, is paying attention to the small updates that are introduced throughout the year as well as major platform updates.
Certain changes to underlying dependencies can break an app completely, cause a feature to be inoperable or do nothing at all. Code review is a continual process, so it’s important to allocate funds for an internal development team or agency to stay on the ball and keep your app operable.
Cloud hosting costs
To run an app, you need servers to host the code and databases to store information that the end client (i.e. the app) use to push and pull information. Every provider works a little different and costs vary, so we’ll use Amazon Web Services (AWS) as an example.
Amazon’s “all-in-one” database solution: RDS
Amazon RDS is their hosting option that tethers the database service that stores all data within an app such as user and product information. An RDS setup works in conjunction with a virtual machine (VM) that typically hosts the code which runs the app. An app requires a database like MySQL, SQL Server, PostgreSQL or another system to save and use data for various portions of the app. The great part about this option is that database management is mostly removed, allowing teams to focus on other tasks.
Pricing varies depending on the flavor of the system, which can range anywhere starting around $0.03 per hour but can go up to as high as $33 an hour (really, it can go much higher), depending on other factors such as footprint-size of the system (i.e. capacity), uplink speed and whether the system is pay-as-you-go (i.e. on-demand) or part of a contract.
For apps that have just launched, we’ve seen that RDS costs tend to be the highest ongoing part of a monthly AWS bill. The screenshot below is just an example, as there is a multitude of different RDS combinations between the OS and database type as well as on-demand or reserved service levels.
Note: There are other storage options under AWS such as Redshift for data warehousing and S3 that can be used for data lake applications but this is atypical for an app fresh to the market.
Amazon standalone VMs on EC2
EC2 can be thought of as a computer in the cloud that runs the backend logic for your app. Your code deployed on EC2 acts like the glue between the front end mobile app and the data that rests in an RDS database. The benefit with EC2 systems is that they’re modular, giving developers more flexibility for customization and control when the feature set is expanded.
The screenshot below is AWS price for our de facto standard machine, though this can change depending on app requirements. Depending on the goals and technology, we’d typically choose Windows or Linux, with the former being just less than twice the cost of a Linux system because, well, it’s a Microsoft product.
Generally, to ensure high-availability and uptime, we deploy two EC2 instances to power an app behind a load balancer. This allows the app to handle spikes in traffic and keeps your app afloat if, for whatever reason, one of the machines decides to take a sick day.
Horizontal and vertical scaling
At some point, your user base grows and there will be more connections and storage requirements, meaning you need to launch new instances to accommodate redundancy and ensure availability in which case, costs begin to multiply. In other cases, a system may simply need to be augmented with additional resources to get it up to speed.
Imagine if you were running a small delivery company. For a while, it might work with just one driver, so you invest in making their vehicle faster and more efficient – this is like vertical scaling, as you’re simply upgrading the vehicle which is less pricey than buying a whole new vehicle. If all goes well, you might need another driver – this can be likened to horizontal scaling as you’re buying a whole new vehicle to add to your fleet.
It’s important to plan for additional systems for the future as increasing the power of any single system doesn’t help your app stay running in the event of a failure, which is where horizontal scaling comes into play. Depending on how the app is used, it might be best to soup up a system (or systems) with more resources, which is where vertical scaling comes into play.
Blue Label Labs can guide you through the pricing and development of your app
If this is your first time building software, it can seem overwhelming. This is why we design our process to be as transparent as possible while we work through a design sprint. We also help solve the mysteries with infrastructure pricing, whether you’re going to use your own hosts or ideally, select a provider like Amazon, Microsoft or another service.
Reach out to us at Blue Label Labs to learn more about how we design your app and help you parse the complexities of pricing to solidify your financial strategy.
Bobby Gill
