Koszt audytu kodu przed przejęciem aplikacji zależy od wielkości systemu i liczby części do sprawdzenia - to zwykle 20–80 godzin pracy. Aktualną cenę audytu w AppCreo znajdziesz w cenniku. Dopiero po audycie wiadomo, czy aplikację opłaca się ratować, czy taniej napisać od nowa. Niżej: sygnały do decyzji, zakres audytu, odzyskanie dostępów i przejęcie krok po kroku.
Tekst jest dla firm, które mają aplikację mobilną albo webową po wykonawcy, który zniknął, przestał odpowiadać albo dowozi coraz wolniej. Nie szukamy winnych. Najpierw trzeba ustalić, co właściwie masz i w jakim jest stanie.
Kiedy aplikację po innym wykonawcy ratować, a kiedy pisać od nowa?
Decyzji nie podejmuje się na podstawie wrażenia, że „kod jest brzydki”. Nowy zespół prawie zawsze ocenia cudzy kod gorzej niż własny, więc sama opinia wykonawcy niewiele znaczy. Liczą się sygnały, które da się sprawdzić i opisać w raporcie z audytu.
| Sygnał | Co oznacza | Decyzja |
|---|---|---|
| Aplikacja działa, błędy dotyczą pojedynczych funkcji | Fundament jest sprawny | Ratować: poprawki i dalszy rozwój |
| Brak testów automatycznych, ale czytelna struktura kodu | Każda zmiana jest ryzykowna, lecz da się to naprawić | Ratować: najpierw testy najważniejszych ścieżek |
| Przestarzałe wersje frameworka i bibliotek | Brak poprawek bezpieczeństwa, trudniejsze aktualizacje | Ratować z planem aktualizacji |
| Brak kodu części systemu, na przykład backendu | Nie da się utrzymać tego, czego nie masz | Odtworzyć brakującą część, resztę ocenić osobno |
| Ta sama logika powielona w wielu miejscach | Zmiana w jednym miejscu psuje inne | Przebudować moduł po module |
| Brak kontroli dostępu po stronie serwera | Dane użytkowników są zagrożone | Natychmiastowa łatka, potem przebudowa tej warstwy |
| Technologia bez wsparcia i bez programistów na rynku | Każdy kolejny wykonawca będzie drogi albo nieosiągalny | Pisać od nowa, etapami |
| Aplikacja nie spełnia aktualnych wymagań sklepów | Nie opublikujesz żadnej aktualizacji | Pilna naprawa zgodności, niezależnie od dalszej decyzji |
| Kod poprawny, ale praca szła wolno | Problem organizacyjny, nie techniczny | Ratować i zmienić sposób pracy |
Zasada praktyczna: pisanie od nowa ma sens, gdy naprawa wymagałaby zmiany większości kodu, gdy brakuje kluczowych części albo gdy technologia nie ma przyszłości. W pozostałych przypadkach ratowanie jest tańsze, bo zachowujesz działające funkcje, dane i opinie w sklepach.
Przepisanie ma też koszt, którego nie widać w wycenie. Przez kilka miesięcy budujesz to, co już masz, zamiast nowych funkcji, a stara wersja wciąż wymaga utrzymania. Dlatego rekomendacja „przepisać wszystko” wydana przed audytem powinna Cię zaniepokoić.
Co obejmuje audyt kodu przed przejęciem i od czego zależy jego koszt?
Audyt przed przejęciem to nie przegląd stylu kodu. Ma odpowiedzieć na trzy pytania: czy aplikację da się zbudować i uruchomić od zera, czy da się ją bezpiecznie rozwijać i ile kosztuje doprowadzenie jej do stanu, w którym zespół może normalnie pracować.
Zakres audytu
- Kompletność. Czy repozytorium zawiera cały kod aplikacji, backendu i panelu oraz czy da się z niego zbudować działającą wersję.
- Architektura. Podział na moduły, miejsce logiki biznesowej, komunikacja aplikacji z serwerem.
- Zależności. Wersje frameworków i bibliotek, ich wsparcie i licencje.
- Bezpieczeństwo. Kontrola dostępu, przechowywanie haseł i kluczy, podatności z listy OWASP Top 10.
- Baza danych. Schemat, migracje, kopie zapasowe i jakość danych.
- Testy i wdrożenia. Testy automatyczne, proces budowania, konfiguracja środowisk.
- Infrastruktura. Serwery, domeny, certyfikaty i usługi zewnętrzne - z informacją, kto za nie płaci.
- Dokumentacja. Czy nowy zespół zrozumie system bez pomocy poprzedniego wykonawcy.
Od czego zależy koszt audytu i ile trwa
Cena zależy od wielkości systemu i liczby części do sprawdzenia: aplikacja mobilna, backend, panel, integracje. Audyt aplikacji średniej wielkości to zwykle 20–80 godzin pracy doświadczonego programisty.
Platformy z wieloma integracjami i kilkoma aplikacjami wychodzą drożej. Kalendarzowo audyt trwa zwykle dłużej, niż wynika z samej liczby godzin. Najwięcej czasu zajmuje nie czytanie kodu, tylko zdobywanie dostępów, więc im szybciej je przekażesz, tym szybciej i taniej.
Co powinien zawierać raport
Raport powinien zawierać listę problemów z priorytetami, ocenę ryzyka, rekomendację dla każdego modułu i wycenę naprawy. Jeśli kończy się ogólnikiem „kod wymaga refaktoryzacji”, bez listy i kosztów, nie spełnił swojej roli.
Rzetelny audyt pokazuje też, co działa dobrze. Raport złożony wyłącznie z zarzutów to częściej wstęp do sprzedaży przepisania niż ocena stanu projektu.
Jak odzyskać kod, repozytorium i dostępy do kont?
Zacznij od inwentaryzacji: wypisz wszystko, bez czego aplikacja nie zadziała albo nie da się jej zaktualizować. Część kont może już być na Twojej firmie, część jest wyłącznie u wykonawcy, a o części nikt nie pamięta, dopóki coś nie przestanie działać.
Lista dostępów do odzyskania
- repozytorium kodu z pełną historią zmian: aplikacja, backend, panel,
- serwery albo konto chmurowe, bazy danych i kopie zapasowe,
- domena, DNS i certyfikaty SSL,
- konta w App Store Connect i Google Play Console,
- klucze podpisywania aplikacji i certyfikaty powiadomień push,
- usługi zewnętrzne: poczta transakcyjna, mapy, płatności, analityka, Firebase,
- pliki źródłowe projektu graficznego,
- dokumentacja, loginy do środowisk testowych i lista osób z dostępem.
Konta w App Store i Google Play
Jeśli aplikacja jest opublikowana na koncie wykonawcy, nie musisz publikować jej od nowa. Obie platformy pozwalają przenieść aplikację na inne konto z zachowaniem użytkowników i opinii. Potrzebujesz własnego konta deweloperskiego i współpracy obecnego właściciela.
W App Store przeniesienie inicjuje posiadacz konta (Account Holder), na którym jest aplikacja. Aplikacja zachowuje opinie, oceny i identyfikator Bundle ID, ale certyfikaty powiadomień push trzeba wygenerować ponownie. W Google Play prośbę składa właściciel konta źródłowego, a Google odpowiada zwykle w ciągu 2 dni roboczych.
Wymagania obu sklepów opisujemy w przewodniku po publikacji aplikacji w App Store i Google Play. Jeśli poprzedni wykonawca nie odpowiada wcale, zostaje Ci ścieżka formalna.
Gdy poprzedni wykonawca nie współpracuje
Sprawdź umowę: czy przenosi autorskie prawa majątkowe do kodu, na jakich polach eksploatacji i od kiedy. Przeniesienie praw wymaga formy pisemnej, a sama licencja daje mniej, niż się wydaje. Zapisy, które chronią przed taką sytuacją, rozpisaliśmy w tekście o umowie z software housem.
Jeśli prawa przeszły, a kod nie został wydany, zacznij od pisemnego wezwania z terminem i listą elementów do przekazania. Równolegle zabezpiecz to, do czego masz dostęp, na przykład kopię bazy i plików z serwera. To nie jest porada prawna - przy sporze zaangażuj prawnika.
Jak wygląda przejęcie projektu krok po kroku?
Przejęcie ma jeden cel: po kilku tygodniach nowy zespół wprowadza zmianę i publikuje ją bez udziału poprzedniego wykonawcy. Poniższa kolejność pozwala tam dojść bez przestojów dla użytkowników.
- Inwentaryzacja dostępów. Lista kont, serwerów, kluczy i usług z informacją, kto jest dziś ich właścicielem i kto płaci.
- Kopie zapasowe. Repozytorium, baza danych i pliki zabezpieczone, zanim ktokolwiek cokolwiek zmieni.
- Przeniesienie kont na Twoją firmę. Repozytorium, chmura, domena i konta w sklepach - nowy zespół dostaje w nich rolę członka, nie właściciela.
- Audyt kodu i infrastruktury. Raport z listą problemów, priorytetami i wyceną każdej pozycji.
- Uruchomienie od zera. Nowy zespół buduje aplikację na czystym środowisku według dokumentacji i uzupełnia jej braki.
- Poprawki krytyczne. Najpierw bezpieczeństwo i zgodność z wymaganiami sklepów, potem błędy zgłaszane przez użytkowników.
- Testy najważniejszych ścieżek. Logowanie, płatności i główny proces, żeby każda kolejna zmiana była bezpieczna.
- Pierwsze wydanie przez nowy zespół. Mała poprawka opublikowana w całości nowym procesem - dowód, że przejęcie się udało.
- Plan rozwoju. Decyzja moduł po module: zostawić, poprawić albo przepisać.
Kroki 1–3 zajmują kilka dni, jeśli poprzedni wykonawca współpracuje. Kroki 4–8 trwają dłużej - ich czas zależy od wielkości systemu i stanu dokumentacji. Jak wygląda współpraca z nowym zespołem od strony organizacyjnej, opisujemy na stronie proces współpracy.
Masz aplikację po poprzednim wykonawcy? Opisz ją w 3 zdaniach i napisz, do czego masz dziś dostęp - odsyłamy ocenę sytuacji i przedział cenowy w 24 h w dni robocze. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Od czego zależy koszt dokończenia albo przepisania aplikacji?
Konkretną kwotę da dopiero audyt, ale oba scenariusze da się porównać wcześniej. Różnią się nie tylko ceną startu, lecz także czasem do pierwszej zmiany u użytkowników i ryzykiem, które bierzesz na siebie.
| Kryterium | Ratowanie i rozwój | Pisanie od nowa |
|---|---|---|
| Koszt na start | Audyt i poprawki krytyczne | Pełny budżet nowej aplikacji |
| Pierwsza zmiana u użytkowników | Po kilku tygodniach | Po kilku miesiącach |
| Dane i konta użytkowników | Zostają bez zmian | Wymagają migracji |
| Opinie w sklepach | Zostają | Zostają, jeśli nowa wersja zastąpi starą w tym samym wpisie w sklepie |
| Główne ryzyko | Ukryte problemy wychodzą w trakcie | Nowe błędy w funkcjach, które już działały |
| Kiedy wybrać | Fundament jest zdrowy | Brak kodu, technologia bez przyszłości, architektura blokuje rozwój |
Przy przepisaniu budżet liczy się jak dla nowej aplikacji, a rozbudowany system wyceniamy indywidualnie. Aktualne ceny dla MVP i aplikacji webowych znajdziesz w cenniku, a czynniki, od których zależy koszt, rozpisaliśmy w tekście o tym, ile kosztuje aplikacja mobilna.
Przy ratowaniu koszt wynika z listy z audytu. Poproś o wycenę każdej pozycji osobno - wtedy sam decydujesz, co naprawić od razu, a co odłożyć. Na co patrzeć w takiej ofercie, pokazujemy w tekście o tym, jak czytać wycenę software house’u.
Koszt, o którym łatwo zapomnieć
Przejęta aplikacja często ma zaległe aktualizacje: bibliotek, frameworka i wymagań sklepów. Trzeba je nadrobić jednorazowo, zanim zacznie się regularne utrzymanie. Roczne pozycje kosztowe opisujemy w tekście o koszcie utrzymania aplikacji mobilnej.
Jak nie powtórzyć tej sytuacji z kolejnym wykonawcą?
Większość trudnych przejęć ma tę samą przyczynę: wszystko było na koncie wykonawcy, a umowa milczała o wydaniu kodu. Kilka zasad sprawia, że ewentualna kolejna zmiana wykonawcy zajmie dni, a nie miesiące.
- Chmura, domena i konta w sklepach na Twojej firmie, od pierwszego dnia.
- Indywidualne repozytorium projektu i zapis w umowie, kiedy i jak kod oraz autorskie prawa majątkowe przechodzą na Ciebie - u nas po zapłacie ostatniej faktury.
- Instrukcja uruchomienia systemu od zera jako warunek odbioru.
- Działająca wersja do obejrzenia co dwa tygodnie zamiast raportów z postępu.
- Testy automatyczne najważniejszych ścieżek w zakresie projektu.
- Zasady rozstania w umowie: termin wydania kodu i płatne wsparcie w przekazaniu projektu.
Jeśli dopiero wybierasz wykonawcę, przeczytaj, jak wybrać software house. Projekty po innych zespołach przejmujemy i rozwijamy w ramach usług tworzenia aplikacji webowych i aplikacji mobilnych - zawsze zaczynając od audytu.
