An app can need work even when you haven't requested a single new feature. Here's how we handle maintenance, warranty fixes, hosting, and ongoing development at Petadev.
Your app is live. Customers are using it. You haven't requested any new features.
Then your development team tells you it needs an update.
For a business owner, that's a reasonable moment to ask: if nothing has changed in the product, what exactly are we paying to change?
The answer is often outside the product itself. Apple and Google update their platforms. App stores change submission requirements. Third-party services change the interfaces your app depends on. An application can continue doing exactly what you asked it to do and still need work to remain compatible with its surroundings.
Our team has ongoing relationships with nearly 30 clients that span multiple years. Several have continued for seven or eight years, and one is approaching a decade. These collaborations include development, hosting and operations, and technical consulting. That experience shapes how we plan for the life of an application beyond its first release.
Here's what that work looks like, and what you should agree on with your development team before launch.
The short version
After launch, a mobile app needs someone responsible for compatibility updates, hosting and backend operations, issue investigation, and future releases. How much work each area requires depends on the application and the support agreement.
At Petadev, we distinguish between three types of work:
| Type of work | What it covers | How we handle it |
|---|---|---|
| Warranty fixes | Defects caused by our implementation that depart from the agreed specification and fall within the warranty terms | We address them promptly, at no additional charge. |
| Maintenance | Work needed to keep the application compatible with changes in platforms, dependencies, or external services | We assess the affected application and scope the necessary work. |
| Feature development | New capabilities or changes to the agreed product behavior | We estimate and price the requested scope, then schedule development. |
Hosting and infrastructure operations also need an explicit agreement. Paying for a server and keeping a mobile app compatible are separate responsibilities, even when the same team handles both.
Why a working app can still need maintenance
A mobile app depends on more than its own source code. It runs on an operating system, uses libraries and development tools, and may connect to a backend and several external services.
Those dependencies continue changing after launch.
For example, Google Play's target API requirements distinguish between requirements for submitting new apps or updates and requirements affecting an existing app's availability to new users on newer Android versions. Apple also publishes minimum SDK requirements for App Store Connect uploads.
These requirements can create work even when the business has no new features planned. The consequence depends on the specific requirement: a submission restriction is different from a compatibility problem affecting people already using the app.
We occasionally see issues appear after an iOS or Android release. We've also encountered differences between Android manufacturers' devices. That's one reason physical-device checks remain part of our work when we update an application.
For a startup that hasn't started generating revenue, maintenance can be a difficult expense to absorb. An established company may have a budget, but still needs to understand why the work is necessary.
A useful maintenance proposal should explain what changed, how it affects your app, and what happens if you postpone the work. “The app needs updating” isn't enough information to make that decision.
Why framework updates need an assessment
“Update the framework” sounds like a single task. The actual work depends on what has been built around it.
An application may use separate packages for notifications, navigation, payments, file uploads, and other capabilities. Those packages can depend on particular framework versions or native platform components. Changing one part can require changes elsewhere.
The React Native upgrade documentation reflects this: an upgrade can involve dependencies and native project files across Android, iOS, and JavaScript, rather than just changing one version number.
In our experience, more complex apps tend to have more of these relationships to check. Smaller apps are usually easier to assess, although a single dependency can still introduce unexpected work.
We have handled enough upgrades to know what to look for, and we still encounter unfamiliar combinations. That makes assessment an important part of pricing the work responsibly.
A useful upgrade scope should establish:
- The change that makes the update necessary.
- Which framework versions, packages, and integrations are affected.
- Whether those dependencies have compatible versions available.
- What code or project configuration needs to change.
- Which workflows need verification before the updated app is released.
An app-store requirement does not automatically mean the entire framework must be upgraded. The appropriate change depends on the project's current state. Equally, a framework update should not be treated as complete just because the app builds successfully.
Is it a warranty fix or paid maintenance?
From the user's perspective, something that stops working is simply a problem. To decide how to resolve it and who pays, the development team needs to understand the cause.
If our implementation fails to meet the agreed specification and the issue falls within the warranty terms, we fix it promptly at no additional charge.
If a platform or external service changes and the app needs adapting, that is generally maintenance. If the business wants different behavior, that is a change to the product.
Consider three illustrative situations:
- An agreed account-recovery flow doesn't work because of an error in our implementation: a warranty issue, subject to the warranty terms.
- A third-party service retires an interface the application uses: maintenance to adapt the integration.
- The business adds a new approval step to account registration: feature development.
The fact that a problem appeared after an operating-system update doesn't, by itself, settle the classification. Investigation may reveal an existing implementation defect or a compatibility change that requires new work.
The cause and the agreed scope should determine the category. A clear specification gives both sides a practical reference when making that decision.
Who runs the backend after launch?
Many mobile applications depend on a backend for accounts, shared data, business rules, or integrations. Publishing the app doesn't resolve who will operate that backend.
We usually handle hosting and operations for our clients, but the arrangement is flexible. Some clients choose to manage their own infrastructure or use another provider. We work with dedicated servers, VPS environments, and AWS, and operate multiple projects across those environments.
The right arrangement depends on the product, the client's internal capabilities, and the responsibilities each party agrees to take on.
Before launch, establish the following:
| Area | What to agree on |
|---|---|
| Infrastructure | Who runs the backend and database, and who pays the hosting provider? |
| Backups and recovery | Who maintains backups, checks that recovery is possible, and handles restoration? |
| Operational issues | Who receives reports, investigates failures, and communicates with the business? |
| Access | Who controls the repository, cloud accounts, app-store accounts, and third-party service accounts? |
| Updates | Who tracks relevant changes, approves the work, and publishes releases? |
| Support coverage | What hours, response expectations, and escalation arrangements have been agreed? |
These responsibilities should be explicit even when one development company handles everything. Hosting alone doesn't tell you what support coverage or recovery arrangements are included.
Our Trinity Guard infrastructure write-up shows one example of how we make hosting decisions around a product's requirements, including AWS and dedicated infrastructure.
How we plan new features after launch
Once people start using an application, the business usually learns more about what it needs. Some requests are small adjustments. Others become substantial additions.
We organize planned improvements into defined development packages. The client identifies the features they want, we assess and price the scope, and we schedule the work in advance. For these post-launch feature development packages, payment is due after development and handover.
This gives the client a concrete decision: which improvements are worth building now, and which can wait?
Maintenance should be visible alongside that roadmap. If a compatibility update and a new feature both affect the same integration, it may make sense to plan them together. Their purposes should still be clear in the scope and pricing.
We also look at ongoing work in the context of the existing product. A team that has supported an application for years has accumulated knowledge about its integrations, earlier decisions, and business rules. That continuity is one practical benefit of a long-term development relationship.
How should you budget for maintenance?
Separate the budget into three parts:
- Recurring operating expenses: hosting and external services your product uses.
- Maintenance work: compatibility changes, dependency updates, and other work required to keep the existing product supported.
- Product development: new capabilities you choose to add.
The first category may be relatively predictable. The second depends partly on changes outside your control. The third follows your priorities and the agreed development scope.
We assess maintenance individually because an application's dependencies and current condition matter more than a generic price attached to the word “update.” The number of screens alone won't tell you how involved the work will be.
You don't need a feature release every month to justify keeping an app in service. You do need a way to identify necessary work, approve it, and get it scheduled before a deadline becomes urgent.
Questions to ask before you sign a development agreement
If you're evaluating a development partner, ask how the relationship will work after delivery:
- What falls within the warranty, and what are its terms?
- Who assesses platform changes and lets us know when action is needed?
- What does the hosting or operations agreement include?
- How are maintenance and new features scoped and approved?
- Who controls the accounts and access needed to keep the product running?
- What happens if we bring operations in-house or change development teams?
Our guide to evaluating a mobile app development company covers the broader hiring decision. If you already have an application and need a different team to maintain it, see how we approach taking over an existing app.
The goal is to know who is responsible when something changes and to understand how the work will be assessed, approved, and delivered.
