An App Really Begins After Launch: What Operations and Maintenance Actually Cost
Launch Is Not the End of the Cost, It Is the Start
Most app development quotes stop at the launch date. The day money actually starts flowing, however, is the day after. A released app sits on top of an environment that keeps moving, and if nobody adjusts it to that movement, it eventually stops working. Operations and maintenance are not optional line items. They are the condition for keeping the app alive.
Development cost is relatively easy to budget. There is a screen count, a feature list, and a schedule, so it resolves into numbers. Operating cost is harder because the line items themselves are invisible from the outside. If you do not know what will occur, it enters the budget as zero, and anything budgeted at zero comes back a few months after launch as unplanned spending.
Post-launch cost is easier to reason about in four separate strands. The first is mandatory upkeep, the work that keeps the app from breaking. The second is infrastructure that scales with users and data. The third is human time spent answering users and fixing defects. The fourth is new features and improvements. The important part is that the first three happen even if you never add a single feature.
In practice many buyers sign contracts treating only the fourth strand as maintenance. That leads to the conclusion that since there is no roadmap for new features right now, maintenance is not needed either. Leave out the first three and it sounds reasonable, but an app ages without new features. Standing still does not mean staying in place: everything around it moves and the app falls behind.
Yeowubie Interaction builds for clients and runs its own products at the same time. onSpots, our attendance service, is published on both the App Store and Google Play and runs in Korean, Vietnamese, and English. Job Connect VN, a jobs service for the Vietnamese market, and Langtori, which connects Korean language learners with teachers, are operated the same way. The items below are not a list assembled to persuade a buyer. They are the list we work through every month ourselves.
This article does not discuss amounts. The spread is wide depending on the nature of the app, the size of the user base, and the response speed you commit to, so a generalized figure would distort judgment more than help it. Instead this lays out which items arise, why they arise, and what to ask before a contract is signed.
The Work That Keeps an App Alive: OS Updates, Store Policy, Certificate Renewal
Some work is mandatory even if you build nothing new. Operating systems move to new versions, store review standards change, and the certificates used to sign your app expire. Neglect these three and you will find you cannot upload a new build, new installs are blocked, or the app crashes for people who already installed it.
iOS and Android ship major versions every year. When a version moves, base rules change: permission handling, background execution, notification behavior, file access. Your code is unchanged but the runtime is not, so a feature that worked yesterday can stop. Apps that use the camera, location, Bluetooth, or background sync feel this most. On top of that, if an open source library you depend on has not adapted to the new version, replacing that library becomes its own piece of work.
Both stores continually revise the standards an app has to meet. Common ones include the SDK level a build must target, how a privacy policy is disclosed, declaration of the data types you collect, providing an account deletion path, and how payments are handled. The specifics of these requirements and their effective dates change often, so please do not treat this article as the reference: check each store's official developer documentation for the requirements in force at the moment you upload. Miss the standard and the build is rejected, and in some cases the visibility of the existing app is restricted too.
Publishing to a store requires signing, and the certificates and keys used for signing have expiry dates. The developer account itself is also subject to renewal. So are the keys used for push notifications and for map or payment integrations. Renewal cycles and procedures differ by platform policy and sometimes change midstream, so the safe approach is to put expiry dates on a calendar and check the official guidance each time. Miss an expiry and releases are blocked, and even an urgent fix can burn days just locating whoever holds account access.
The hardest failure to reverse in this category is losing a signing key. On Android the app signing key is close to the identity of the app itself, so without a decided storage method and recovery path you can end up unable to ship an update at all. A recurring pattern in practice is that accounts and keys stay under the personal name of one person at the development vendor until the contract ends. Section five returns to this, but it is a contract problem rather than a technical one.
The external services your app depends on need the same attention. Maps, social login, payments, push, SMS delivery, and analytics all move their API versions forward and retire the old ones. Deprecation notices usually arrive months ahead, but if nobody reads them, the feature dies quietly on the shutoff date. Operations includes reading those notices and getting them onto a schedule, not just editing code.
Servers and Infrastructure: What Grows When Your Users Grow
Server cost is not a fixed value set at build time. It is a variable that moves with usage. As users grow, so do compute, database, storage, egress traffic, logs, and the volume of notifications you send. Which of those grows fastest depends on how the app is structured, and that structure is decided during development.
The lines that actually appear on an invoice usually look like this: server compute time, database capacity and throughput, storage for images and files, outbound traffic, retention for logs and monitoring, backup retention, the count of push notifications, text messages, and emails sent, and external APIs billed per call such as maps or verification. Alongside those sit fixed annual items unrelated to scale, such as domains and store developer accounts.
The places where budgets go wrong are fairly predictable. Photos and videos uploaded by users come first. Store the original and serve the original, and storage and transfer costs rise together. Logs come second: leave the verbose logging you enabled for debugging switched on and retention quietly accumulates. Text message verification comes third. It is billed per message, so it scales honestly with signups, and it spikes unexpectedly when automated signup attempts arrive.
Free tiers on cloud and third party services deserve attention as well. Early on almost everything fits inside the free allowance, so infrastructure looks nearly free. Billing starts the moment you cross the threshold, and that moment usually coincides with you being pleased about user growth. Without budget alerts and usage caps set in advance, you find out when the invoice arrives.
Most of the ways to lower operating cost sit in the design phase rather than after launch. Whether images are resized before storage, whether frequently read data is cached, how list queries are written, when old data is cleaned up: these decisions change the order of magnitude of the monthly bill. Asking a vendor at quoting time what monthly operating cost they are designing toward is enough to reveal whether they have thought about it.
Some items should not be cut. Backup and restore procedures, error tracking, and basic health monitoring are genuine costs, but removing them means a single incident returns a far larger bill. Backup does not end at producing a copy: the item includes the time spent verifying that the copy actually restores. A backup that has never been restored in a drill is hard to describe as existing.
The Human Hours Behind Support and Bug Fixes
The largest post-launch line is often not servers but human time. Someone reads the report, reproduces it, finds the cause, fixes it, checks that nothing else broke, ships it, and waits for store review. Even a one line change drags the whole sequence along with it.
On the web, a fix goes live the same day. Mobile is different. You build, upload, pass review, and then users still have to take the update. Anyone who does not update stays on the old version. That is why mobile operations plans a path for handling urgent fixes without a store release. Configuration served from the backend, switches that disable a single feature, and copy managed server side are those mechanisms. Built in from the start, they buy you days when it matters.
Human time leaks fastest on bugs that will not reproduce. A single line saying login sometimes fails means narrowing by device, OS version, network, and account state one at a time. Attach crash reporting and error tracking and that process compresses from hours to minutes. It is the clearest case where tooling costs less than people's time.
Support requests do not arrive through one door. They scatter across store reviews, the in app contact form, email, the company's main phone line, and messages to a salesperson. What the contract has to settle is who receives them first. Whether the buyer's support staff triage and pass only technical matters to the developer, or the developer takes everything from the start, changes the workload on both sides considerably. Leave it undecided and complaints in store reviews pile up unread.
How fast you promise to respond is itself the cost. Answering by the next business day and responding within a fixed window that includes nights and weekends require different staffing. There is no reason to treat every report at the same speed, so it serves both sides not to put a payment blocking outage and a typo on a screen in the same tier. Writing the severity tiers and target response time per tier into the contract removes most later arguments.
An app served in several languages has to be supported in those languages. Running onSpots in Korean, Vietnamese, and English taught us that translation does not end at the screen. Replies to users, the store listing, announcements, and error messages all have to hold the same quality, and that consumes human time too. For an app aimed at both Vietnam and Korea, budgeting this from the start is simply more accurate.
The Maintenance Scope to Agree On Before You Sign
With maintenance it is better to settle scope before asking about price. If the scope differs, placing two quotes side by side does not compare anything. What follows is a checklist for the buyer to work through when reading a contract or proposal. The same questions apply whichever vendor you work with.
Start with the free defect liability period and the definition of a defect. Behavior that does not match the agreed acceptance criteria is a defect. Behavior requested after acceptance is an improvement. Without that boundary in writing, both sides spend the first months after launch in an argument that produces nothing. It is also worth remembering that the distinction is only possible if the requirements document and acceptance criteria still exist.
The form of the maintenance agreement is the next item. There is a fixed monthly scope, settlement against hours actually spent, and quoting each request individually, and each fits a different situation. An app that changes little and runs steadily is comfortable on a per request basis, while a product you intend to keep working on is easier to manage on a retainer or hourly settlement. Either way, the essential part is listing what is included and what is not.
Be explicit about whether the mandatory upkeep described in the second section falls inside maintenance. Whether major OS version support, store policy changes, certificate and key renewal, and external API deprecations sit inside the base agreement or are billed separately changes the real burden substantially. If those items never appear in the contract at all, that absence is itself the question to raise.
Write down who carries infrastructure cost and how it is billed. Settle whether the vendor pays cloud charges and invoices them onward or whether they come straight out of the buyer's account, and who raises a flag first when usage exceeds expectations. Usage based items move month to month, so folding them into one fixed figure guarantees months where one side loses.
Ownership of accounts and assets is checked last and matters most. Cloud accounts, store developer accounts, domains, signing keys, source repositories, and third party service accounts should each be recorded in writing under a named owner. Holding them in the buyer's name and delegating operational access to the vendor causes the fewest problems later.
The last item is how it ends. Record how source code and documentation are handed over at termination, whether another vendor can reproduce the same build from that source, how many weeks of transition support are included, and how much notice termination requires. A contract with a clean version of this clause is not a document for parting ways. It is a document that makes long working relationships easier. The party that leaves the exit open usually works more honestly inside it.
The sequence we suggest is simple. When you request a development quote, ask for the operating items in the same document, sketch a full year of burden even roughly, and only then fix the development scope. An app you can build and an app you can sustain are different things. We handle these same items every month for our own products, so if you are unsure which item to sort out first, feel free to ask.
