Tworzymy aplikacje mobilne na iOS i Android dla firm 30–150 osób w fazie scaling. Stack — native iOS, native Android, React Native lub hybrid — wybieramy w Discovery, pod konkretny cel biznesowy. App Store i Google Play w cenie projektu.
Aplikacja mobilna jako główny produkt, mobilne rozszerzenie istniejącego systemu lub aplikacja terenowa dla zespołów operacyjnych. Każdy typ ma inną logikę projektową — i inny stack po Discovery.
Aplikacja mobilna to główny punkt kontaktu z użytkownikiem końcowym. B2B SaaS gdzie wersja na komputer nie ma sensu, produkt branżowy (logistyka, healthcare, sprzedaż w terenie), poważny produkt B2C z konkretnym uzasadnieniem biznesowym.
Stack indywidualnie — natywny lub wieloplatformowy.
Aplikacja mobilna jako część szerszego ekosystemu klienta — uzupełnienie produktu webowego, dodanie mobilnego dostępu do istniejącego backendu, wieloplatformowość ze stroną webową. Typowo React Native, ale stack indywidualnie.
Pracownicy w terenie — serwis, audyty, dostawy, instalacje, sprzedaż mobilna. Synchronizacja w trybie offline-first, MDM klasy korporacyjnej, integracje z ERP/CRM, tryb kiosku. Często natywny Android dominuje (Samsung/Xiaomi MDM).
Nie wiesz który typ pasuje? Discovery to wyjaśni — razem ze stackiem
Nie wiesz który typ pasuje? Discovery to wyjaśni — razem ze stackiem.
Natywny iOS, natywny Android, React Native lub hybrydowy — decyzja zapada na podstawie celu biznesowego, kryteriów technicznych i kosztu długoterminowego. Discovery kończy się ADR (Architecture Decision Record) z wybranym stackiem i uzasadnieniem.
Wybieramy gdy:
Xcode, Swift 5, SwiftUI, Combine
Wyższy koszt długoterminowy (osobny zespół)
Wybieramy gdy:
Android Studio, Kotlin, Jetpack Compose, Coroutines
Wyższy koszt długoterminowy (osobny zespół)
Wybieramy gdy:
RN 0.7x, Expo SDK 5x, TypeScript, EAS Build/Submit
Niższy koszt długoterminowy, jeden zespół
Wybieramy gdy:
80–90% zakresu standardowy + 10–20% wymagający wysokiej wydajności
Wzorzec: RN + moduły Swift/Kotlin dla camera processing, audio DSP, specyficznych integracji z systemem
Kompromis: czas wprowadzenia RN + wydajność natywna gdzie potrzeba
RN + moduły Swift/Kotlin, EAS bare workflow
Średni — RN baseline + selektywne fragmenty natywne
Tak samo jak frontend mobilny — backend wybieramy w Discovery, nie z góry.
Domyślnie pracujemy w stacku Next.js + Payload CMS + PostgreSQL (jeśli masz już aplikacje webową, jeden zespół, niższy koszt długoterminowy).
Ale jeśli problem lepiej realizuje:
…to idziemy tym, co realizuje cel biznesowy.
Decyzja w Discovery, ADR z uzasadnieniem.
Trzecia ścieżka — integracja z istniejącym backendem klienta (REST, GraphQL, gRPC) bez przebudowy.
Dyscyplina stabilnego stacka. React Native ma ponad 5 lat doświadczenia produkcyjnego (Meta, Microsoft, Shopify, Discord), większy zespół specjalistów w Polsce i lepszą integrację z naszym stackiem React/Next.js.
Flutter wymaga osobnego ekosystemu Dart, Google jest jedynym sponsorem, a polski rynek specjalistów jest mniejszy.
Tak. Discovery (5–15k, płatny etap z rezultatem) kończy się ADR z wybranym stackiem i uzasadnieniem. Klient dostaje dokumentację z kryteriami wyboru i może iść z nią do innego dewelopera.
Część rozmów „chcemy aplikację mobilną" kończy się decyzją, że PWA lub strona responsywna realizuje cel biznesowy taniej i szybciej. To wynik Discovery, nie wstępna teza.
Mówimy wprost — nasz zakres to aplikacje mobilne dla firm w skali, nie wszystko mobilne:
Standard procesu Digital Vantage — Discovery jako płatny etap z rezultatem, sprinty 2-tygodniowe, publikacja w sklepach w cenie projektu, trzy opcje współpracy po stabilizacji.
Audyt problemu i celu biznesowego.
Decyzja stacka (natywny iOS / natywny Android / React Native / hybrydowy) z uzasadnieniem. Zakres per platforma, integracje, strategia trybu offline.
Brief biznesowy + ADR + ostateczna wycena + harmonogram. Klient może iść z dokumentacją do innego dewelopera.
Figma, wzorce mobilne (iOS HIG + Material Design 3), prototyp interaktywny dla 3–5 kluczowych ścieżek. Design system mobilny — typografia, odstępy, komponenty świadome platformy.
Design system + prototyp interaktywny + materiały sklepowe
Sprinty 2-tygodniowe, demo per sprint. Kod w repozytorium klienta od dnia 1. EAS Build / Xcode Cloud / Gradle CI zależnie od stacka. TestFlight + Play Internal dla klienta na bieżąco.
Działająca aplikacja w środowisku testowym
Matryca testowa — iOS 17/18 (3–5 modeli), Android 13–15 (4–6 modeli marek Samsung / Xiaomi / Pixel), różne sieci (3G/4G/WiFi/offline), różne języki. Nie tylko emulator.
Raport QA + lista błędów rozwiązanych per urządzenie
Konfiguracja kont (jeśli klient nie ma), materiały sklepowe (zrzuty ekranu, opis, ikony, URL polityki prywatności), zgłoszenie, odpowiedź na weryfikację Apple (często 1–2 rundy), pierwsza wersja produkcyjna.
Aplikacja w App Store i Google Play
Trzy opcje po stabilizacji:
Stabilna produkcja + decyzja modelu współpracy
Publikacja w sklepach to standardowy element procesu — nie dodatkowa pozycja w cenniku. Konta deweloperskie pozostają po stronie klienta (firma musi być wydawcą własnej aplikacji).
Widełki cenowe per poziom z konkretnym zakresem. Ostateczna wycena po Discovery — wcześniejsze widełki to estymacja na podstawie typowych projektów w danej kategorii.
Zakres:
Zakres:
Zakres:
Dyscyplina pracy, którą stosujemy w każdym projekcie mobilnym — niezależnie od stacka, zakresu i branży klienta.
Natywny iOS, natywny Android, React Native lub hybrydowy — decyzja w Discovery na podstawie kryteriów biznesowych i technicznych. Bez domyślnego „RN bo szybciej" ani „natywny bo lepiej".
Publikacja w sklepach to standardowy element procesu, nie dodatkowa pozycja w cenniku. Konta deweloperskie po stronie klienta (musisz być wydawcą własnej aplikacji), reszta po stronie DV.
Część rozmów „chcemy aplikację mobilną" kończy się decyzją, że PWA realizuje cel biznesowy taniej i szybciej. Mówimy to wprost, jeśli Discovery to pokaże.
Discovery (5–15k) to płatny etap z konkretnymi rezultatami — brief, ADR, ostateczna wycena, harmonogram. Klient może iść z dokumentacją do innego dewelopera — to dyscyplina, nie pułapka.
Każda biblioteka w produkcji ma minimum 5 lat doświadczenia produkcyjnego. Bez eksperymentowania na żywym projekcie klienta. Lista decyzji technicznych (ADR) z uzasadnieniem każdej.
Po wdrożeniu trzy ścieżki — wewnętrznie, abonament, współpraca strategiczna. Kod w repozytorium klienta od pierwszego sprintu, zero uzależnienia od dostawcy. Pełna dokumentacja i ADR jako standard.
Pytania, które dostajemy najczęściej w Discovery. Pełne FAQ tworzenia oprogramowania (15+ pytań w 7 grupach) zostanie opublikowane w osobnej sekcji.
To decyzja Discovery, nie wstępna teza. Natywny (Swift, Kotlin) wybieramy gdy potrzebne są funkcje wymagające wysokiej wydajności (camera ML, AR, audio DSP), specyficzne API platformy (HealthKit, MDM klasy korporacyjnej) lub głęboka integracja z ekosystemem. React Native gdy priorytet czasu wprowadzenia, jeden zespół na dwie platformy i ~80% parytet funkcji wystarcza. Hybrydowy (RN + moduły natywne) gdy 90% zakresu to standard, a 10% wymaga wydajności natywnej.
Dyscyplina stabilnego stacka. React Native ma ponad 5 lat doświadczenia produkcyjnego (Meta, Microsoft, Shopify, Discord), większy zespół specjalistów w Polsce i lepszą integrację z naszym stackiem React/Next.js. Flutter wymaga osobnego ekosystemu Dart, Google jest jedynym sponsorem, a polski rynek specjalistów jest mniejszy. Jeśli klient ma już zespół Flutter — wtedy rozmawiamy.
Tak. Discovery (5–15k, płatny etap z rezultatem) kończy się ADR — Architecture Decision Record — z wybranym stackiem i uzasadnieniem. Klient dostaje dokumentację z kryteriami wyboru i może iść z nią do innego dewelopera. Decyzja stacka przed Discovery byłaby zgadywaniem.
Tak — konfiguracja konta, zrzuty ekranu, opis sklepu, zgłoszenie, odpowiedź na weryfikację Apple, pierwsza wersja produkcyjna. Po stronie klienta zostają konta deweloperskie: Apple Developer 99 USD/rok i Google Play 25 USD jednorazowo. Aktualizacje po wdrożeniu są poza projektem — abonament lub godzinowo.
Trzy opcje po stabilizacji. Wewnętrznie — przekazujemy dokumentację, ADR i szkolenie, klient prowadzi dalej sam. Abonament — utrzymanie i nowe funkcje godzinowo lub stała stawka miesięczna. Współpraca strategiczna — DV jako współwłaściciel produktu z umową stałą i SLA. Wybór indywidualnie, najczęściej decyzja pada 4–12 tygodni po wdrożeniu.
Oba scenariusze. Projekt od zera — domyślny stack DV: Next.js 15 + Payload CMS + PostgreSQL (spójny z aplikacjami webowymi). Integracja z istniejącym backendem klienta — REST, GraphQL lub gRPC, indywidualnie. Decyzja w Discovery, na podstawie tego co już macie i jaki jest cel długoterminowy.
Pełne FAQ tworzenia oprogramowania znajdziesz w osobnej sekcji. Zobacz pełne FAQ tworzenia oprogramowania
Discovery to konkretny etap z rezultatem — ADR, ostateczna wycena i harmonogram. Każdy klient zaczyna od tej samej rozmowy, niezależnie od zakresu projektu.