Extending an existing mobile app — how to add features to an app someone else built

Your app has been live for a few years, it has users and it makes money. Now you need a new feature: subscriptions, Sign in with Apple, a booking module or an integration with a new system. The team that built it has moved on, so you ask another company for a quote. What comes back is several times higher than you expected, along with a list of tasks that have little to do with the feature itself.

That isn’t necessarily overcharging. Adding features to an app someone else wrote carries costs you don’t have when you develop your own, and it helps to know where they come from before you start comparing offers.

The first feature costs more than the next ones

Every quote for extending an existing app has two parts, even if the offer doesn’t separate them:

1. The entry cost — everything needed before a new team can safely change the code and ship a new version. You pay it once.
2. The feature cost — designing, building and testing what you actually asked for.

From the second feature on, you pay almost only the feature cost. That is why two quotes for the same feature can differ by a factor of two or three: one company includes the entry cost, the other assumes there won’t be one and discovers it halfway through.

What has to happen before any new code is written

Access

The repository with its full history, Google Play Console and App Store Connect accounts, the Firebase or other cloud console, access to the backend, keys for third-party services. If any of them is missing, the work stops before it starts. The full list is in our checklist for taking over a project from another software house.

Getting the project to build

It sounds trivial, but it is the most common source of surprises. A project nobody has built in two years usually won’t build on current Android Studio and Xcode: old versions of Gradle, plugins and libraries need updating before the app even launches. Sometimes the repository is also missing configuration files the previous developer kept only on their own machine.

Store requirements

This is the trap app owners most often don’t know about: you can’t ship a new feature until the app meets the store’s current requirements. Since 31 August 2026 Google Play requires updates to target Android 16 (API 36), and since 28 April 2026 the App Store only accepts apps built with Xcode 26 and the iOS 26 SDK. If the app is a few versions behind, a small feature drags a whole platform update along with it. What exactly changed is covered in our article on why an app stops working on the new Android or iOS.

Understanding the code around the change

Nobody has to read the whole app. But the team does need to understand the modules the new feature will touch: how sign-in works, where the data comes from, how the app talks to the backend. Without that, the new code ends up bolted on next to the old code instead of fitting into it, and every later change gets more expensive.

Three situations, three different quotes

The entry cost depends on the state of the app. Below are rough ranges from our projects — the actual numbers only come out once we’ve looked at the code.

At an example rate of PLN 180 net per hour (real market rates vary, this is just an illustration), the entry cost comes to roughly PLN 1,500–4,300 in the first case and PLN 7,200–29,000 in the second. If the app is built on an older cross-platform framework, the upgrade alone can be the largest part of the work — we cover that in our article on updating an old Flutter or React Native app.

In the third case the first task isn’t the feature, it’s a decision. Sometimes it makes more sense to add new modules in modern code alongside the old, and sometimes to rewrite part of the app. How to make that call on numbers is described in refactor or rewrite from scratch.

How not to break what already works

In an app someone else wrote, the biggest risk isn’t the new feature itself, but what stops working along the way. Older apps rarely have automated tests, and the documentation, if there is any, describes the state of things from years ago.

A few practices that noticeably lower that risk:

• Tests around the area being changed. Before the team changes a module, it writes tests that pin down its current behaviour. The goal isn’t coverage of the whole app, only of the parts the change touches.
• A baseline before the change. Crash-free sessions, startup time, conversion on key flows. If the app has no monitoring, it’s worth adding it in the first release — see our article on mobile app crash monitoring.
• A first release without the new feature. Technical updates shipped on their own. If something breaks, you know the update is to blame, not the new code.
• Gradual rollout. Staged rollout on Google Play and phased release on the App Store let you ship a version to a share of users first and pause it if the metrics drop.
• A kill switch. It’s worth being able to turn the new feature off remotely, through remote config or a backend flag, without shipping a new version and waiting for store review.

Old app versions and the backend

A new feature often needs API changes. Meanwhile some users won’t update the app for months and will keep running a version that only knows the old API. If the backend changes a response in a way the old version doesn’t understand, the app starts failing for them even though nobody touched it.

That’s why API changes should be backward compatible: new fields go next to the old ones, and old endpoints stay until almost nobody uses the versions that need them. A minimum supported version mechanism also helps, letting you force an update when an old version genuinely can’t keep working. It has to be in the app beforehand, though — we explain this in more detail in our article on deprecated SDKs and APIs.

How to prepare a request so you get a reliable quote

The more the vendor knows before quoting, the fewer assumptions they have to make — and every assumption is either padding in the price or a risk of extra charges later. Prepare:

• a description of the feature from the user’s point of view — who does what and why, plus examples from other apps if you know any,
• read access to the code — even read-only, for the duration of the quote,
• a list of integrations — payments, sign-in, external systems the app uses,
• who owns the accounts in the stores and the cloud, and whether they are company accounts,
• the date of the last release and whether anyone has seen warnings in Play Console or App Store Connect,
• the version distribution among users, if you have analytics.

Also ask for the offer to separate the entry cost from the feature cost and to list its assumptions. That makes offers easier to compare and shows what a vendor has left out. More on reading offers in our article on what to ask about a mobile app quote.

Red flags in offers

• A fixed price without looking at the code. Either there is a lot of padding, or the vendor doesn’t know what they are in for.
• “We’ll rewrite everything” without an analysis. A rewrite can be the right call, but it can’t be made without looking at the code.
• No mention of store requirements. If the app is behind on targetSdk or Xcode and the offer says nothing about it, that work will surface mid-project.
• No release plan. A new feature in someone else’s app without tests, monitoring and gradual rollout is a risk carried by you and your users.
• Lots of new dependencies. Every library added “for convenience” is one more thing to keep updated for years to come.

Summary

Extending an existing app is usually cheaper and faster than building a new one, as long as you know what you are paying for. You pay the entry cost once, and it’s worth knowing it before the decision rather than during the work. The first release is best spent on technical updates and monitoring, and the new feature should go out gradually, with a way to switch it off.

Developing apps written by other teams is our everyday work — we usually start with a mobile app takeover and then look after the app as part of maintenance and development. If you want to know what the entry cost would be in your case, order a free app analysis. We’ll check whether the project builds, how far it is from store requirements and what needs doing before the first new feature, and you get the results in writing.