Aplikacje mobilne
Tworzenie aplikacji mobilnych dla marketplace'ów i produktów na żądanie
Klient rezerwuje z telefonu. Osoba wykonująca pracę też ma telefon, często przy słabym zasięgu i z jedną wolną ręką. To są dwie różne aplikacje, a większość briefów przewiduje budżet tylko na pierwszą.
- produktów wdrożonych
- 20+produktów wdrożonych
- niszy branżowych
- 4niszy branżowych
- lat budowania
- 4lat budowania
Pytanie rzadko brzmi: natywnie czy cross-platform.
Zespoły przychodzą z decyzją technologiczną już postawioną jako ta trudna. W praktyce jest najłatwiejsza i wynika z kilku faktów: jak często aplikacja musi działać bez połączenia, czy potrzebuje sprzętu, do którego web nie sięga, i jak szybko produkt wciąż musi się zmieniać.
Realny koszt leży gdzie indziej. Powiadomienia push, które przychodzą wtedy, kiedy mają znaczenie, a nie o drugiej w nocy. Stan, który przeżyje martwą strefę i ubity proces aplikacji. Weryfikacja w App Store, kiedy wydanie jest spięte z datą kampanii. Aplikacja dla wykonawcy, używalna w rękawicach i przy dwudziestu procentach baterii.
Budujemy stronę klienta i stronę operacyjną jako jeden system, bo dzielą backend, model uprawnień i tę samą kolejkę wsparcia. Wypuszczanie ich jako osobnych projektów to sposób na to, żeby się rozjechały.
Co budujemy w warstwie mobilnej
Oba końce produktu na żądanie, nie tylko ten ładny.
Aplikacje dla klientów
Rezerwacja, terminarz, zarządzanie adresami i płatnościami, historia zamówień i status na żywo. Projektowane tak, żeby domknąć rezerwację w mniej niż minutę, bo to ta liczba decyduje o konwersji.
Aplikacje dla wykonawców i operatorów
Kolejka zleceń, przyjęcie i odrzucenie, przekazanie do nawigacji, potwierdzenie wykonania zdjęciem i ewidencja czasu. Zbudowane pod obsługę jedną ręką i słaby zasięg.
Odporność na brak sieci
Stan lokalny, kolejkowanie akcji i rozwiązywanie konfliktów po powrocie połączenia. Aplikacja terenowa, która wymaga pełnego zasięgu, nie jest aplikacją terenową.
Powiadomienia, które mają sens
Push, godziny ciszy, grupowanie i linki prowadzące do właściwego ekranu. Plus zapasowe ścieżki na wypadek wyłączonych powiadomień, a wyłącza je sporo osób.
Płatności na urządzeniu
Zapisane metody, preautoryzacje, napiwki, zwroty i potwierdzenia, z regułami płatności obu platform obsłużonymi z góry, a nie odkrywanymi w trakcie weryfikacji.
Wydania i obsługa sklepów
Konta w sklepach, cykle weryfikacji, stopniowe wdrożenia, raportowanie awarii i możliwość wypuszczenia poprawki w tym samym tygodniu, bez czekania w kolejce.
Jak przebiega budowa
Najpierw decyzja o platformie, potem jeden system z dwoma frontami.
- 01
Decyzja o platformie
Web, cross-platform czy natywnie – wybór z wymagań co do zasięgu, sprzętu i tempa wydań. To rozmowa, nie warsztat.
Tydzień 0 - 02
Najpierw przepływy, potem piksele
Obie aplikacje rozrysowane na tym samym backendzie, razem ze stanami, które istnieją tylko na telefonie: przerwany, w tle, offline, rozładowany.
2-3 tygodnie - 03
Budowa w tygodniowych sprintach
Wersje testowe w twoich rękach od pierwszego sprintu przez TestFlight i kanały wewnętrzne, żeby informacja zwrotna przychodziła z urządzenia, a nie z dokumentu.
8-16 tygodni - 04
Publikacja i to, co po niej
Zgłoszenie do sklepów, stopniowe wdrożenie, monitoring awarii i pierwsza runda zmian, które wymusza realne użycie w drugim tygodniu.
Na bieżąco
Aplikacje, które wypuściliśmy
Produkty, w których praca dzieje się z dala od biurka.
Pachaca
An on-demand cleaning service needed a complete digital ecosystem across mobile, web, and internal operations.
YachtMate
Private network for yacht club members needed secure, real-time communication
Teya Logistics
Logistics company needed a modern landing page to clearly present their services and attract new clients
Na czym to budujemy
Jeden backend, dwa fronty, nudna infrastruktura.
Aplikacje
- React Native
- TypeScript
- Moduły natywne tam, gdzie trzeba
Backend
- Node.js
- NestJS
- PostgreSQL
- MongoDB
- Redis
Operacje
- App Store
- Google Play
- Infrastruktura push
- Raportowanie awarii
Pytania, które dostajemy przed budową aplikacji
Cross-platform pokrywa większość marketplace'ów i produktów na żądanie, w tym nasze. Natywnie idziemy, gdy potrzebna jest ciągła lokalizacja w tle, głęboki dostęp do sprzętu albo wydajność specyficzna dla platformy. Przy webie zostajemy, gdy produkt jest używany okazjonalnie, a ty chcesz wypuszczać zmiany codziennie. Dłuższe porównanie opisaliśmy na blogu.
Dwa do czterech miesięcy na pierwszą wersję spiętą z istniejącym backendem, dłużej, gdy platforma pod spodem powstaje równolegle. Weryfikacja w sklepach dokłada dni, nie tygodnie, o ile konta zostaną założone odpowiednio wcześnie.
Jeśli osoby wykonujące pracę nie są twoimi pracownikami, zwykle tak: ich potrzeby różnią się na tyle, że jedna aplikacja nie obsłuży dobrze żadnej z grup. Czasem właściwą odpowiedzią jest aplikacja dla klientów plus mobilne narzędzie webowe dla wykonawców, co jest tańsze – powiemy, kiedy to pasuje.
Wymagania offline, płatności, śledzenie w czasie rzeczywistym i liczba odrębnych ról. Sama obecność w sklepach to niewielki stały koszt; zmienną jest to, jak duża część produktu musi działać, kiedy sieć nie działa.
Tak, po audycie. Powiemy uczciwie, czy warto kontynuować na tym kodzie, czy pozostała praca wyjdzie taniej na nowym fundamencie. Rekomendowaliśmy jedno i drugie.
Do ciebie. Aplikacje publikujemy z twoich kont deweloperskich i twoich certyfikatów, więc przy wydaniu nigdy nie jesteś od nas zależny.
Powiedz nam, gdzie dzieje się praca. Trzydzieści minut, bez sprzedaży. Powiemy, które części naprawdę potrzebują aplikacji, a które spokojnie zostaną w webie.
Umów rozmowę