Rozbudowa istniejącej aplikacji mobilnej — jak dodać nowe funkcje do aplikacji napisanej przez kogoś innego

Aplikacja działa od kilku lat, ma użytkowników i zarabia. Teraz potrzebujesz nowej funkcji: subskrypcji, logowania przez Apple, modułu rezerwacji albo integracji z nowym systemem. Zespół, który ją napisał, już się tym nie zajmuje, więc prosisz o wycenę inną firmę. W odpowiedzi dostajesz kwotę kilka razy wyższą, niż się spodziewałeś, i listę prac, które z samą funkcją mają niewiele wspólnego.

To nie musi być naciąganie. Rozbudowa cudzej aplikacji ma koszty, których nie ma przy rozwijaniu własnej, i dobrze jest wiedzieć, skąd się biorą, zanim zaczniesz porównywać oferty.

Pierwsza funkcja kosztuje więcej niż kolejne

Każda wycena rozbudowy składa się z dwóch części, nawet jeśli oferta tego nie rozdziela:

1. Koszt wejścia — wszystko, co trzeba zrobić, żeby nowy zespół mógł bezpiecznie zmienić kod i wydać nową wersję. Płacisz go raz.
2. Koszt funkcji — zaprojektowanie, napisanie i przetestowanie tego, o co faktycznie prosisz.

Przy drugiej i kolejnych funkcjach zostaje już prawie tylko koszt funkcji. Dlatego dwie oferty na tę samą funkcję potrafią się różnić dwu- albo trzykrotnie: jedna firma uwzględnia koszt wejścia, druga zakłada, że go nie będzie, i odkrywa go w trakcie pracy.

Co musi się wydarzyć, zanim powstanie nowy kod

Dostępy

Repozytorium z pełną historią, konta w Google Play Console i App Store Connect, panel Firebase lub innej chmury, dostęp do backendu, klucze do zewnętrznych usług. Jeśli któregoś z nich brakuje, praca się zatrzymuje, zanim się zacznie. Pełną listę opisujemy w checkliście przejęcia projektu po innym software housie.

Zbudowanie projektu

Brzmi banalnie, ale to najczęstsze źródło niespodzianek. Projekt, którego nikt nie budował od dwóch lat, zwykle nie zbuduje się na aktualnym Android Studio i Xcode: stare wersje Gradle, wtyczek i bibliotek wymagają aktualizacji, zanim aplikacja w ogóle się uruchomi. Bywa też, że w repozytorium brakuje plików konfiguracyjnych, które poprzedni programista trzymał tylko u siebie.

Wymagania sklepów

Tu jest pułapka, o której właściciele aplikacji najczęściej nie wiedzą: nowej funkcji nie wydasz, dopóki aplikacja nie spełnia bieżących wymagań sklepu. Google Play od 31 sierpnia 2026 wymaga, żeby aktualizacje celowały w Androida 16 (API 36), a App Store od 28 kwietnia 2026 przyjmuje tylko aplikacje zbudowane w Xcode 26 z SDK iOS 26. Jeśli aplikacja jest kilka wersji w tyle, mała funkcja pociąga za sobą aktualizację całej platformy. Co dokładnie się zmieniło, opisujemy w tekście o tym, dlaczego aplikacja nie działa na nowym Androidzie lub iOS.

Zrozumienie kodu wokół zmiany

Nikt nie musi czytać całej aplikacji. Trzeba jednak zrozumieć moduły, których nowa funkcja dotknie: jak działa logowanie, skąd biorą się dane, jak aplikacja rozmawia z backendem. Bez tego nowy kod będzie dobudowany obok starego, a nie w niego wpasowany, i każda kolejna zmiana będzie droższa.

Trzy sytuacje, trzy różne wyceny

Koszt wejścia zależy od stanu aplikacji. Poniżej orientacyjne widełki z naszych projektów — konkretne liczby zawsze wychodzą dopiero po obejrzeniu kodu.

Przy przykładowej stawce 180 zł netto za godzinę (realne stawki na rynku się różnią, to tylko ilustracja) koszt wejścia wynosi więc ok. 1 500–4 300 zł w pierwszym przypadku i ok. 7 200–29 000 zł w drugim. Jeśli aplikacja napisana jest w starszym frameworku cross-platform, sama aktualizacja bywa największą częścią pracy — piszemy o tym w tekście o podnoszeniu Fluttera i React Native po latach.

W trzecim przypadku pierwszym zadaniem nie jest funkcja, tylko decyzja. Czasem rozsądniej jest dokładać nowe moduły w nowoczesnym kodzie obok starego, a czasem przepisać fragment aplikacji. Jak podjąć tę decyzję na liczbach, opisujemy w tekście refactor czy przepisać od zera.

Jak nie zepsuć tego, co już działa

W aplikacji pisanej przez kogoś innego największym ryzykiem nie jest sama nowa funkcja, tylko to, co przy okazji przestanie działać. Starsze aplikacje rzadko mają testy automatyczne, a dokumentacja, jeśli istnieje, opisuje stan sprzed kilku lat.

Kilka praktyk, które to ryzyko wyraźnie obniżają:

• Testy wokół zmienianego miejsca. Zanim zespół zmieni moduł, pisze testy, które utrwalają jego obecne zachowanie. Nie chodzi o pokrycie całej aplikacji, tylko o fragmenty, których zmiana dotyczy.
• Punkt odniesienia przed zmianą. Odsetek sesji bez awarii, czas uruchomienia, konwersja w kluczowych ścieżkach. Jeśli aplikacja nie ma monitoringu, warto go dodać w pierwszym wydaniu — opisujemy to w tekście o monitoringu awarii aplikacji.
• Pierwsze wydanie bez nowej funkcji. Same aktualizacje techniczne wydane osobno. Jeśli coś się zepsuje, wiadomo, że przyczyną jest aktualizacja, a nie nowy kod.
• Stopniowe udostępnianie. Staged rollout w Google Play i phased release w App Store pozwalają wydać wersję najpierw części użytkowników i wstrzymać ją, jeśli metryki spadną.
• Wyłącznik funkcji. Nową funkcję warto móc wyłączyć zdalnie, przez zdalną konfigurację albo flagę w backendzie, bez wydawania nowej wersji i czekania na recenzję w sklepie.

Stare wersje aplikacji i backend

Nowa funkcja często wymaga zmian w API. Tymczasem część użytkowników przez miesiące nie zaktualizuje aplikacji i dalej będzie korzystać z wersji, która zna tylko stare API. Jeśli backend zmieni odpowiedź w sposób, którego stara wersja nie rozumie, aplikacja zacznie się u nich sypać, choć nikt jej nie dotykał.

Dlatego zmiany w API powinny być wstecznie zgodne: nowe pola dodaje się obok starych, a stare endpointy zostają do czasu, aż prawie nikt nie korzysta z wersji, które ich potrzebują. Pomaga też mechanizm minimalnej wspieranej wersji, który pozwala wymusić aktualizację, gdy stara wersja naprawdę nie może dalej działać. Musi on jednak być w aplikacji wcześniej — opisujemy to szerzej przy wycofanych SDK i API.

Jak przygotować zapytanie, żeby dostać rzetelną wycenę

Im więcej wykonawca wie przed wyceną, tym mniej założeń musi w niej zrobić — a każde założenie to albo zapas w cenie, albo ryzyko dopłaty w trakcie. Przygotuj:

• opis funkcji z perspektywy użytkownika — kto, co i po co ma zrobić, plus przykłady z innych aplikacji, jeśli takie znasz,
• dostęp do kodu do wglądu — nawet tylko do odczytu, na czas wyceny,
• listę integracji — płatności, logowanie, systemy zewnętrzne, z których aplikacja korzysta,
• informację, kto ma konta w sklepach i chmurze, i czy są firmowe,
• datę ostatniego wydania i to, czy ktoś zgłaszał ostrzeżenia w Play Console lub App Store Connect,
• rozkład wersji u użytkowników, jeśli masz analitykę.

Poproś też, żeby oferta rozdzielała koszt wejścia od kosztu funkcji i wymieniała założenia. Łatwiej wtedy porównać oferty i zobaczyć, co któryś wykonawca pominął. Więcej o czytaniu ofert piszemy w tekście o tym, o co pytać przy wycenie aplikacji.

Czerwone flagi w ofertach

• Stała cena bez obejrzenia kodu. Albo ma duży zapas, albo wykonawca nie wie, co go czeka.
• „Przepiszemy wszystko" bez analizy. Przepisanie bywa właściwą decyzją, ale nie da się jej podjąć bez zajrzenia do kodu.
• Brak słowa o wymaganiach sklepów. Jeśli aplikacja jest w tyle z targetSdk albo Xcode, a oferta o tym milczy, ta praca wyjdzie w trakcie.
• Brak planu wydania. Nowa funkcja w cudzej aplikacji bez testów, monitoringu i stopniowego udostępniania to ryzyko, które poniesiesz Ty i Twoi użytkownicy.
• Dużo nowych zależności. Każda biblioteka dodana „dla wygody" to kolejna rzecz do aktualizowania przez następne lata.

Podsumowanie

Rozbudowa istniejącej aplikacji jest zwykle tańsza i szybsza niż budowa nowej, pod warunkiem że wiesz, za co płacisz. Koszt wejścia ponosisz raz i warto go poznać przed decyzją, a nie w trakcie. Pierwsze wydanie najlepiej poświęcić aktualizacjom technicznym i monitoringowi, a nową funkcję wydawać stopniowo, z możliwością wyłączenia.

Rozwijanie aplikacji napisanych przez inne zespoły to nasza codzienność — zaczynamy zwykle od przejęcia aplikacji mobilnej, a potem prowadzimy ją w ramach utrzymania i rozwoju. Jeśli chcesz wiedzieć, ile wyniesie koszt wejścia w Twoim przypadku, zamów bezpłatną analizę aplikacji. Sprawdzimy, czy projekt się buduje, jak daleko jest od wymagań sklepów i co trzeba zrobić przed pierwszą nową funkcją, a wynik dostaniesz na piśmie.