Aplikacja webowa (PWA) vs aplikacja mobilna vs strona internetowa: co wybrać dla firmy i ile to kosztuje

Sporo rozmów w aveneo zaczyna się tak samo. Ktoś dzwoni i mówi, że potrzebuje apki, najlepiej w sklepie, bo konkurencja ma. A kiedy pytamy, co ta apka ma właściwie robić i kto będzie z niej korzystał, okazuje się, że opisany problem da się rozwiązać na trzy różne sposoby, z których dwa są tańsze i szybsze niż to, co klient sobie wyobraził. Nie dlatego, że klient się nie zna. Po prostu hasła „PWA", „aplikacja webowa" i „apka mobilna" wrzuca się do jednego worka, a to są różne rzeczy z różnymi kosztami.

Ten tekst jest po to, żeby ten worek rozpakować. Nie technicznie, tylko decyzyjnie. Chcę, żebyś po przeczytaniu wiedział, o co pytać, kiedy natywna apka faktycznie ma sens, a kiedy przepłacasz za obecność w sklepie, której Twoi klienci i tak nie zauważą. Bez żargonu, na tyle na ile się da.

Zacznijmy od najczęstszego zamieszania, bo jedno i drugie „otwiera się w przeglądarce", więc łatwo je pomylić. Strona internetowa to przede wszystkim prezentacja treści. Wizytówka, oferta, blog, opis firmy. Wchodzisz, czytasz, ewentualnie wypełniasz formularz kontaktowy i wychodzisz. Strona rzadko cokolwiek „liczy" ani nie pamięta, kim jesteś.

Aplikacja webowa to zupełnie inne zwierzę, choć adres w przeglądarce wygląda podobnie. To interaktywne narzędzie z logiką, danymi i kontami użytkowników. Panel klienta, wewnętrzny system do obsługi zamówień, kalkulator, kokpit z raportami, platforma do rezerwacji. Logujesz się, coś robisz, dane się zapisują, aplikacja reaguje na to, co klikasz. Strona pokazuje, aplikacja webowa działa.

Ta różnica ma realne przełożenie na pieniądze, bo strona to głównie treść i wygląd, a aplikacja webowa to logika, baza danych i bezpieczeństwo kont. Dlatego kiedy ktoś mówi „chcę stronę, gdzie klient się zaloguje i zobaczy status swojego zlecenia", to już nie jest strona. To aplikacja webowa, tylko nazwana po staremu.

Tu robi się ciekawie, bo PWA (Progressive Web App) to właśnie ten element układanki, o którym najwięcej osób słyszało, a najmniej wie, co to znaczy. Najprościej: PWA to aplikacja webowa, która dostała kilka cech aplikacji natywnej. Można ją zainstalować na telefonie albo na pulpicie, pojawia się ikona jak przy normalnej apce, w rozsądnym zakresie działa offline, potrafi wysyłać powiadomienia push. A pod spodem to nadal jedna baza kodu, ta sama, która działa w przeglądarce.

Praktyczna konsekwencja jest taka, że użytkownik dostaje coś, co wygląda i zachowuje się jak apka, ale Ty nie przechodzisz przez cały cyrk ze sklepami. Nie ma weryfikacji w App Store, nie ma osobnej wersji na iOS i osobnej na Androida, nie ma czekania na akceptację aktualizacji. Poprawkę wypychasz i użytkownik ma ją od razu, przy następnym otwarciu.

PWA nie jest magicznym rozwiązaniem na wszystko. Dostęp do niektórych funkcji sprzętu telefonu bywa ograniczony, a na iOS część rzeczy działa skromniej niż na Androidzie. Ale dla dużej części zastosowań biznesowych to po prostu wystarcza, i to jest sedno, które chcę tu przemycić.

Aplikacja natywna, czyli ta klasyczna „apka ze sklepu", to osobne oprogramowanie zbudowane pod iOS i pod Androida. Instalujesz ją z App Store albo Google Play, ma pełny dostęp do sprzętu, czyli kamery, GPS, bluetootha, czujników, i daje najlepszą wydajność, jaką da się wycisnąć z telefonu. Jeśli budujesz coś, co mocno obciąża grafikę albo musi non stop rozmawiać z podzespołami urządzenia, natywna jest właściwym wyborem.

Cena tej mocy jest jednak konkretna. W praktyce często robisz dwie aplikacje, jedną na iOS i jedną na Androida, albo sięgasz po framework cross-platform, który jedno i drugie łączy, ale i tak wymaga swojej roboty. Do tego dochodzi publikacja w sklepach, utrzymanie tam obecności i to, że każda aktualizacja przechodzi przez proces akceptacji, zanim trafi do ludzi. To wolniej i drożej niż wypchnięcie zmiany w aplikacji webowej.

Jest jeszcze jeden powód, dla którego natywna bywa uzasadniona, i nie ma nic wspólnego z technologią. Czasem sam fakt bycia w App Store czy Google Play to kanał pozyskiwania klientów. Ludzie szukają w sklepie, przeglądają, instalują. Jeśli Twoi klienci realnie tak Cię znajdą, obecność w sklepie jest wartością sama w sobie. Jeśli nie, płacisz za półkę, po którą nikt nie sięga.

Przejdźmy do konkretów, bo tu zwykle zapada decyzja. PWA albo aplikacja webowa wystarcza w zaskakująco wielu sytuacjach. Panel klienta lub pracownika w firmie B2B, katalog produktów, menu w gastronomii otwierane z kodu QR przy stoliku, wewnętrzne narzędzie dla zespołu, platforma rezerwacyjna. Wspólny mianownik jest taki, że nie potrzebujesz głębokiego dostępu do sprzętu telefonu ani obecności w sklepie jako sposobu na dotarcie do ludzi. W takich przypadkach natywna apka to zwykle nadmiarowy koszt.

Natywna zaczyna mieć sens, gdy pojawia się któryś z konkretnych powodów. Intensywna grafika albo gra. Głęboka integracja ze sprzętem, na przykład ciągłe czytanie z czujników czy skanowanie w specyficzny sposób. Praca offline-first w terenie, gdzie aplikacja musi w pełni działać bez zasięgu przez długi czas i dopiero potem synchronizować dane. No i wspomniana sytuacja, gdy App Store lub Google Play jest realnym kanałem sprzedaży, a nie tylko miejscem, gdzie apka „powinna być".

Jak to poukładać w głowie. Zacznij od pracy offline i dostępu do sprzętu, bo to najczęściej przesądza sprawę. Jeśli aplikacja musi działać godzinami bez internetu albo sięgać głęboko do podzespołów, celuj w natywną. Jeśli nie, zapytaj, czy sklep to Twój kanał sprzedaży. Jeśli też nie, to prawie na pewno PWA albo aplikacja webowa zrobi robotę taniej.

Teraz część, na którą wszyscy czekają, i jednocześnie ta, gdzie najłatwiej o rozczarowanie, jeśli oczekujesz jednej liczby. Nie podam Ci widełek, bo byłyby zmyślone i do niczego. Podam za to zasadę, która się nie zmienia. Web i PWA są zwykle tańsze i szybsze we wdrożeniu, bo to jedna baza kodu i brak procesów sklepowych. Natywna jest droższa, bo najczęściej oznacza dwie platformy albo framework cross-platform, plus publikację i utrzymanie w sklepach.

Ważniejsze jest jednak to, że o cenie nie decyduje sama „technologia". Decyduje zakres, czyli ile ta aplikacja ma faktycznie robić. Decydują integracje, bo podpięcie do systemu ERP, płatności czy zewnętrznego API potrafi być większą robotą niż cały interfejs. Decyduje UX, czyli jak dopracowane ma być doświadczenie użytkownika. Dwie aplikacje „webowe" mogą różnić się kosztem wielokrotnie, bo jedna to prosty panel, a druga to rozbudowany system z rozliczeniami i uprawnieniami.

Dlatego kiedy ktoś pyta nas na starcie „ile kosztuje aplikacja", uczciwa odpowiedź brzmi: zależy, co ma robić. To nie jest wykręcanie się od odpowiedzi. To sygnał, że najpierw trzeba zrozumieć problem, a dopiero potem można rozmawiać o pieniądzach, które nie będą wróżeniem z fusów.

Jeśli miałbyś zapamiętać z tego tekstu jedno zdanie, niech to będzie to: technologię dobiera się do problemu, a nie odwrotnie. U nas w aveneo rozmowa nigdy nie zaczyna się od „robimy PWA czy natywną". Zaczyna się od trzech pytań. Co ta aplikacja ma robić. Dla kogo. I gdzie będzie używana, w biurze przy komputerze, w terenie bez zasięgu, czy na telefonie klienta z ulicy. Dopiero z tych odpowiedzi wypada „web", „PWA" albo „natywna", a nie na odwrót.

Ta kolejność chroni budżet lepiej niż jakakolwiek tabelka porównawcza. Bo kiedy zaczynasz od technologii, łatwo dać się złapać na modne hasło albo na to, że ktoś ze znajomych „ma apkę w sklepie". A kiedy zaczynasz od problemu, często okazuje się, że rozwiązanie jest prostsze i tańsze, niż się bałeś. Widzieliśmy to nieraz i to jest chyba najmilsza część tej pracy, powiedzieć komuś, że nie musi wydawać tyle, ile myślał.

Jeśli masz w głowie pomysł i nie wiesz, czy to zadanie dla strony, aplikacji webowej, PWA czy natywnej apki, po prostu się odezwij. Wystarczy krótka rozmowa, żeby wstępnie ustawić kierunek, a jak temat dojrzeje, przygotujemy konkretną wycenę pod Twój zakres. Bez zobowiązań i bez wciskania Ci droższego rozwiązania, jeśli tańsze załatwia sprawę.