How much does mobile app maintenance cost — in-house developer, freelancer or a block of hours

How much does mobile app maintenance cost? We break the cost down into fixed fees and work, show how many hours a month typical apps need, and compare an in-house developer, a freelancer and a block of hours at a software house.

Zespół Mobilesoft· Engineering team· 21 września 2026· 11 min czytania

The app is in the store, the first users already have it, the development invoice is paid. And then comes the question most owners don't have an answer ready for: how much does mobile app maintenance cost, if "it already works"?

The short answer: less than a full-time developer, and more than zero. The longer answer depends on how actively the app is being developed, what technology it's built in and how you buy the work. In this article we break maintenance cost down into its parts, show how many hours a month typical apps need, and run the numbers on an example: an in-house developer, a freelancer or a block of hours from a software house.

Why an app that "works" still generates costs

A mobile app doesn't live in a vacuum. It lives on phones whose operating systems change every year, in stores that change their rules every year, and on libraries that someone else updates at their own pace. Even if you don't add a single feature, the ground keeps shifting under the app.

The consequences of doing nothing are very concrete:

  • Google raises the required targetSdk level every year. An app that doesn't meet it stops being visible to new users on newer Android versions. We described this in detail in our article on why an app disappears from Google Play after the target API deadline.
  • Apple requires apps to be built with the new Xcode and SDK every year. Without that you can't ship any update — including an urgent bug fix.
  • New OS versions change how apps behave. Permissions, notifications, background work, screen layout — what worked on last year's Android or iOS can stop working on this year's.
  • Libraries and third-party SDKs age. Payment gateways, Sign in with Google/Apple, analytics SDKs — vendors switch off old API versions and don't ask for permission.

Every year without updates doesn't save money, it just defers it — with interest. An app neglected for two or three years often can't even be built anymore and needs a separate reactivation project, which costs many times more than regular, small version bumps.

What mobile app maintenance cost is made of

Maintenance cost splits into two very different categories: fixed fees, which are small and predictable, and people's work, which makes up the vast majority of the budget.

Fixed fees (independent of work)

  • Apple Developer Program account — USD 99 a year. Without an active account, the app disappears from the App Store.
  • Google Play Console account — a one-time USD 25 fee at registration.
  • Backend and infrastructure — server, database, file storage, push notifications. From a few dozen złoty a month for a small app on services like Firebase to several thousand with heavy traffic and your own infrastructure.
  • Third-party services — maps, text messages, transactional e-mails, error monitoring, analytics. Many have free tiers, but they grow with your user base.
  • Store commissions — if you sell digital content through in-app purchases. Strictly speaking this isn't a maintenance cost, but it's worth including in the budget.

For a typical business app this part usually comes to somewhere between a few hundred and a few thousand PLN a month. It's easy to calculate from invoices.

Developer work (the main part of the budget)

This covers everything that needs a human:

  • Mandatory maintenance — bumping targetSdk and the iOS version, updating libraries, adapting to new store requirements, responding when an update is rejected.
  • Bug fixing — user reports, crashes from monitoring tools, issues on specific phone models.
  • Security — updating dependencies with vulnerabilities, renewing certificates and keys, reacting to changes in sign-in and payments.
  • Releases — building, testing and publishing new versions in both stores.
  • Development — new features, changes based on feedback, adapting to changes in the business.

The first three are unavoidable. The last one depends entirely on your plans — and it's the one that makes budgets differ the most.

How many hours a month an app needs

A popular rule of thumb says the annual cost of maintenance is 15–20% of the cost of building the app. It's a useful reference point, but not a precise one — two apps built for the same amount can have completely different needs. It's better to think in hours of work per month. In our experience, the split looks roughly like this:

  • A stable app with no development plans — around 10–30 hours a month. Version bumps, library updates, small fixes, one or two releases a quarter. Some months almost nothing, noticeably more in the run-up to Google and Apple deadlines.
  • An active app with minor development — around 30–60 hours a month. On top of maintenance: regular fixes from feedback, small features and a release every few weeks.
  • An app developed along a roadmap — around 80 hours a month or more. A permanent backlog, new features in every release, work on several fronts at once.

A few factors strongly affect the number of hours:

  • Number of platforms and codebases. Two native apps (Android and iOS) means two sets of updates. A cross-platform app in Flutter, React Native or Kotlin Multiplatform is usually cheaper to maintain, although the framework itself also needs regular updates.
  • State of the code. No tests, outdated architecture and dependencies not updated for years make every small change take longer. That's the classic interest on technical debt.
  • Number of integrations. Every payment method, third-party sign-in or partner SDK is one more thing that can change without warning.
  • Release automation. Manually building and uploading versions to the stores can eat several hours per release. A well set up CI/CD pipeline does the same in a dozen or so minutes.

In-house, freelancer or software house — three cost models

The number of hours is half of the equation. The other half is how you pay for them.

An in-house developer or a long-term B2B contractor

An experienced Android or iOS developer on a B2B contract in Poland typically costs PLN 18–25k net a month today. On an employment contract, the employer's total cost is even higher.

  • Pros: full availability, product knowledge in-house, easy communication.
  • Cons: you pay for 160 hours even if the app needs 30. Add recruitment (often several months), onboarding, holidays and sick leave. One person is one set of skills — an Android developer won't fix a bug in the iOS version. And when they leave, the knowledge leaves with them.

This model makes sense when the app is the company's main product and genuinely fills a full-time job — or more.

A freelancer by the hour

The cheapest hourly rate on paper and the biggest risk in practice.

  • Pros: flexibility, you pay for the time actually worked.
  • Cons: availability depends on the freelancer's other contracts, so an urgent fix can wait for weeks. No cover for holidays or illness. If the cooperation breaks off and the store, repository and server access was on their accounts, you have a serious problem — exactly the scenario we describe in our project takeover checklist.

This model works when you have a proven specialist and keep all access on your side.

A software house on an hourly basis (outsourced maintenance)

A developer from an external company, onboarded to your project, works an agreed number of hours per month: a fixed package (e.g. 30 hours), half-time (around 80 hours) or on demand.

  • Pros: you pay for as many hours as the app needs and change the scope when your needs change. Continuity is the company's responsibility, not yours. When needed, you have access to QA, design or backend without hiring more people.
  • Cons: the hourly rate is higher than a freelancer's. You need to make sure a permanent person is assigned to the project rather than someone new every month — otherwise you pay for constant ramp-up on the code.

Let's run the numbers

Take a business app for Android and iOS with moderate development. For simplicity, let's assume an example rate of PLN 180 net per hour at a software house (real market rates vary — this only illustrates the mechanism) and PLN 22k a month for a B2B developer.

Option 1 — your own full-time developer: PLN 22,000 × 12 months = PLN 264,000 a year, regardless of how much work there actually was. Plus recruitment costs and the risk of starting from zero if that person leaves.

Option 2 — half-time at a software house (80 h/month): 80 h × PLN 180 = PLN 14,400 a month, i.e. PLN 172,800 a year. A steady development rhythm, a backlog, regular releases.

Option 3 — a fixed package of 30 hours a month: 30 h × PLN 180 = PLN 5,400 a month, i.e. PLN 64,800 a year. Enough for an app in the maintenance phase with minor changes.

The difference between options 1 and 3 is almost PLN 200k a year — for an app that wouldn't have filled a full-time job anyway. That's why companies moving from an in-house developer to an hourly model cut their maintenance cost by as much as half.

To be fair: if your app needs 160 hours of work a month or more, the math flips and your own team becomes the more sensible choice. The hourly model wins where there's less work than a full-time job — which is the case for most business apps.

What not to cut

When looking for savings, it's easy to cut things that come back later as a much bigger bill:

  • Yearly version bumps. Putting them off for a year or two means making several changes at once instead of one — often with parts of the app rebuilt.
  • Error monitoring. Without a crash-reporting tool you learn about problems from store ratings, i.e. too late.
  • Access on your side. App Store Connect and Google Play Console accounts, the repository, app signing keys and servers should belong to your company. Recovering them after a contractor disappears can cost more than a whole year of maintenance.
  • Pre-release testing. A buggy release costs not only the fix, but also lost ratings and users.

How to lower mobile app maintenance cost

A few things that genuinely reduce the number of hours needed each month:

  1. Update in small steps, regularly. Bumping one library by one version takes a moment. Bumping twenty libraries by three versions at once can take weeks.
  2. Automate builds and releases. CI/CD and tools like fastlane eliminate manual work on every release and reduce mistakes.
  3. Add tests where things break most often. You don't need test coverage for the whole app — the key paths are enough: sign-in, payment, the main feature.
  4. Remove what nobody uses. Every unused library and dead screen is something you still have to update.
  5. Start with a review of the code. A one-off audit shows what generates the highest costs and lets you plan maintenance on numbers rather than gut feeling.

When an in-house developer, and when outsourced maintenance

In short:

  • An in-house developer — when the app is your main product, there's a full-time job's worth of work or more, and you want to build a team inside the company.
  • A freelancer — when you have a proven person, small and irregular needs, and you keep all access yourself.
  • A software house by the hour — when the app needs anywhere from a dozen to several dozen hours a month, continuity matters to you, and you don't want to recruit or manage a developer.

If you don't know which group you belong to, check how many hours of work actually went into the app over the last year. That's usually the quickest answer.

Summary

Maintaining a mobile app isn't optional — it's the condition for the app staying in the stores at all and working on new phones. Fixed fees are small. The budget is decided by work — above all, by whether you pay for the hours the app really needs or for a full-time job "just in case".

For most business apps, anywhere from a dozen to several dozen hours a month is enough. That's the scope in which we provide mobile app maintenance for Android, iOS and Flutter — as a block of hours, half-time or on demand. We start with a free project analysis, after which you know how many hours you realistically need. If the app hasn't been updated in a long time, start with our 15-point checklist or simply get in touch.