Aplikacje na iOS i Androida budujemy jako warstwę wykonawczą automatyzacji: dane wprowadzane na miejscu, formularze działające bez zasięgu, zadania przypisane przez przepływ i statusy widoczne dla klienta.
Zdjęcie, odczyt, podpis i lokalizacja wprowadzone na miejscu zamiast przepisywane wieczorem z notatnika. Zgłoszenie z aplikacji od razu rusza przepływ: opis, wpis w systemie, powiadomienie właściwej osoby.
W piwnicy, w hali i na budowie zasięgu nie ma. Aplikacja zapisuje dane lokalnie i dosyła je, gdy sieć wróci — bez powtórzeń i bez zgubionych zgłoszeń, także gdy ktoś zamknął ją w połowie.
To, co automatyzacja przypisała, ląduje na liście konkretnej osoby: co zrobić, gdzie i do kiedy. Zamknięcie zadania w aplikacji domyka krok w przepływie, a nie tylko zmienia kolor w tabelce.
Rezerwacje, zamówienia, program lojalnościowy, podgląd statusu sprawy. Wszystko na tych samych danych i tym samym kalendarzu co strona i agent głosowy — jedno źródło, trzy kanały.
Push wysyła przepływ, nie człowiek: gdy sprawa zmieni etap, gdy termin się zbliża, gdy coś się zatrzymało. Projektujemy je tak, żeby nie uczyć ludzi ignorowania powiadomień.
Wersje testowe przez TestFlight i Firebase App Distribution udostępniamy w trakcie prac. Aplikację klikacie na własnym telefonie długo przed publikacją.
Aplikacja mobilna jest najdroższą warstwą wykonawczą, jaką można postawić nad przepływem — dwie platformy, konta deweloperskie, weryfikacja w sklepach, aktualizacje przy nowych wersjach systemów. Warto ją stawiać wtedy, gdy proces już działa i wiadomo, co dokładnie ma się dziać w terenie.
Jeśli nie potrzebujecie kamery, pracy offline, powiadomień push ani ikony na ekranie telefonu, ta sama funkcja w przeglądarce powstanie szybciej i taniej, a jej zmiana nie wymaga przechodzenia przez sklepy. Mówimy to na pierwszej rozmowie, nie po podpisaniu umowy.
Jeden kod na obie platformy — przy większości projektów biznesowych to najlepszy stosunek kosztu do efektu. Wybór między nimi zależy od zakresu i tego, z czym integruje się aplikacja.
Jeśli aplikacja mocno korzysta ze sprzętu albo wymaga maksymalnej płynności, uczciwiej jest napisać ją natywnie. Mówimy o tym na etapie rozmowy o zakresie, a nie po pierwszych problemach.
Projektujemy warstwę, przez którą aplikacja rozmawia z przepływami, i mechanizm dosyłania danych po odzyskaniu zasięgu — tak, żeby ponowna wysyłka nie tworzyła duplikatów w Waszym systemie.
Często nie. Jeśli nie korzystacie z kamery, pracy offline, powiadomień push ani nie potrzebujecie ikony na ekranie telefonu, ta sama funkcja w przeglądarce powstanie szybciej i taniej, a zmiany nie muszą przechodzić przez sklepy. Sprawdzamy to na pierwszej rozmowie i mówimy wprost.
Wyceniamy indywidualnie po rozmowie o procesie — rozrzut jest tu największy ze wszystkich naszych usług, bo zakres bywa skrajnie różny. Wycenę z kamieniami milowymi dostajecie przed rozpoczęciem prac.
Ustalamy to, patrząc na to, gdzie realnie są użytkownicy. Przy React Native i Flutterze obie platformy powstają z jednego kodu, więc różnica w koszcie budowy jest mniejsza, niż się zwykle zakłada — ale testowanie i publikacja to i tak podwójna praca.
Jeśli proces tego wymaga — tak. Dane zapisują się lokalnie i dosyłają po odzyskaniu zasięgu. To osobny element projektu i osobny element testów, bo najwięcej błędów powstaje właśnie przy ponownej wysyłce.
Tak — aplikacja powinna być publikowana z Waszych kont (Apple Developer Program i Google Play Console), żeby została Waszą własnością. Zakładamy je albo weryfikujemy razem z Wami na etapie przygotowania technicznego.
Sama weryfikacja to zwykle od kilkudziesięciu godzin do kilku dni, ale bywają uwagi recenzentów wymagające poprawek. Ten etap prowadzimy i reagujemy na uwagi — nie zostawiamy Was z odrzuconą aplikacją.
Tak, i bardziej niż aplikacja webowa. Systemy iOS i Android wydają nowe wersje, sklepy zmieniają wymagania, biblioteki się aktualizują. Aplikacja bez aktualizacji z czasem przestaje działać poprawnie — zasady wsparcia ustalamy przy przekazaniu.
Zaznaczcie, czego ma dotyczyć rozmowa, i wybierzcie termin — oddzwaniamy o wskazanej godzinie. Wycenę przygotowujemy dopiero wtedy, gdy znamy realny zakres pracy.