Aplikacje webowe i mobilne dla firm — przewodnik po budowie, decyzja po decyzji

Ten dział jest dla osób, które zamawiają aplikację, a nie ją programują. Właściciela firmy, kierownika działu, osoby, której przypadło „ogarnięcie systemu”, bo proces przestał się mieścić w arkuszu i skrzynce mailowej. Nie tłumaczymy tu języków programowania ani architektury. Tłumaczymy decyzje, które musicie podjąć, żeby aplikacja powstała, zmieściła się w budżecie i była używana.

Tych decyzji jest pięć i zapadają w określonej kolejności. Każda zawęża następne: zakres pierwszej wersji zależy od tego, co w ogóle ma powstać, wycena — od zakresu, harmonogram — od wyceny i tego, kto co robi, a droga do użytkownika — od wszystkiego wcześniej. Dlatego dział jest ułożony według tej kolejności, a nie według tematów.

Jeśli Wasze pytanie brzmi raczej „czy to się opłaca”, „gotowe narzędzie czy własne” albo „jaki system do CRM, rezerwacji czy magazynu”, zacznijcie od działu aplikacje dla firm — tam są pytania biznesowe. Tu są pytania o budowę.

Pięć decyzji w kolejności

Poniższa mapa zbiera cały dział na jednym obrazie: przy każdej decyzji pytanie, z którym firmy do nas przychodzą, to, co ta decyzja przesądza, i tekst, który na nie odpowiada. Nie trzeba czytać wszystkiego po kolei — ale jeśli jesteście na początku, ta kolejność oszczędzi Wam powrotów.

„Nie wiemy, czy to ma być aplikacja, czy wystarczy strona”

To pierwsze pytanie i najczęściej pomijane. Strona internetowa opisuje firmę i proces: kim jesteście, co oferujecie, jak się skontaktować. Aplikacja ten proces obsługuje: przyjmuje zamówienie, pokazuje status zlecenia, zapisuje zgłoszenie, łączy dane z kilku miejsc. Jeśli to, czego potrzebujecie, da się zrobić formularzem kontaktowym i dobrze opisaną ofertą, aplikacja będzie kosztem bez powodu. Jeśli klienci albo pracownicy mają coś w niej robić — logować się, zmieniać, sprawdzać, zatwierdzać — strona przestaje wystarczać.

Granica nie zawsze jest oczywista, bo dzisiejsze strony potrafią więcej niż kiedyś, a proste aplikacje bywają tańsze, niż się wydaje. Czym dokładnie jest aplikacja webowa, jakie są jej rodzaje — portal klienta, panel wewnętrzny, aplikacja sprzedażowa — i po czym poznać, że Wasza firma już jej potrzebuje, rozpisujemy na przykładach aplikacji, które zbudowaliśmy dla siebie.

Ta decyzja przesądza, czy w ogóle budujecie system. Warto podjąć ją świadomie, zanim ktokolwiek zacznie wyceniać funkcje.

„Mamy więcej pomysłów niż budżetu”

Kiedy już wiadomo, że aplikacja ma powstać, pojawia się lista funkcji — zwykle dłuższa, niż pozwala budżet. Najczęstsza reakcja to „zacznijmy od MVP”, która w praktyce oznacza te same funkcje, zrobione taniej. To droga do produktu, który niczego nie sprawdził.

MVP, czyli minimum viable product, to coś innego: najmniejsza wersja, która odpowiada na jedno pytanie biznesowe — na przykład, czy klienci będą składać zamówienia sami, zamiast dzwonić. Zakres wyznacza to pytanie, a nie kwota, a najtrudniejsza część pracy to spisanie, czego nie budujecie. Jak wyciąć zakres metodą MoSCoW, czym MVP różni się od proof of concept i prototypu i jaką miarą sprawdzić wynik, pokazujemy na zakresie własnego CRM i historii naszego modułu rezerwacji.

Ta decyzja przesądza budżet i termin pierwszej wersji — i to, czy po jej uruchomieniu będziecie wiedzieć więcej niż przed.

„Dostaliśmy trzy wyceny i każda jest inna”

Trzy oferty na tę samą aplikację różniące się kilka razy to sytuacja typowa, nie wyjątkowa. Różnica rzadko wynika ze stawki za godzinę. Zwykle wynika z tego, co każdy z wykonawców zrozumiał jako zakres, ile godzin na niego przewidział i co wliczył w cenę — testy, projekt, publikację, utrzymanie.

Na pytanie, ile kosztuje stworzenie aplikacji, nie ma jednej liczby rynkowej, bo w Polsce nikt nie publikuje cennika wytworzenia oprogramowania. Jest za to rachunek, który można odtworzyć samemu: skąd bierze się stawka, jak czytać zakres w ofercie i co kosztuje aplikacja po uruchomieniu. Rozpisujemy go krok po kroku, razem z medianami z naszego raportu i ich ograniczeniami.

Ta decyzja przesądza wybór wykonawcy — i to, czy porównujecie oferty, czy tylko kwoty na ich końcu.

„Chcemy wiedzieć, jak to przebiega i co robimy my”

Projekt aplikacji trwa miesiącami, ale zamawiający nie musi być obecny na każdym spotkaniu. Musi być obecny w trzech momentach: przy briefie, kiedy ustala się, co ma powstać; przy prototypie, kiedy zmiana zdania jest najtańsza w całym projekcie; i przy odbiorze, czyli testach akceptacyjnych, których nie da się oddelegować wykonawcy.

Jak stworzyć aplikację dla firmy z wykonawcą — od briefu na jednej stronie, przez sześć etapów projektu, po wybór software house'u — opisujemy razem z tym, ile to trwa według reguł, którymi sami planujemy projekty, i na co idzie ten czas. Programowanie to w naszych założeniach mniej niż połowa projektu.

Ta decyzja przesądza harmonogram i Waszą rolę w nim — i to, czy dowiecie się o nieporozumieniu po dwóch tygodniach, czy po dwóch miesiącach.

„Czy aplikacja musi być w sklepie?”

Wiele firm zakłada, że „aplikacja na telefon” oznacza App Store i Google Play. Tymczasem część potrzeb obsługuje PWA — strona, którą można zainstalować na telefonie, działa bez zasięgu i wysyła powiadomienia, bez sklepu, bez przeglądu każdej wersji i bez opłat za konta.

Granice PWA wyznacza jednak przeglądarka telefonu, a nie wykonawca, i na iPhonie są węższe niż na Androidzie: instalacja jest ręczna, powiadomienia działają dopiero po dodaniu do ekranu, a części funkcji sprzętowych nie ma wcale. Czym jest aplikacja PWA, co potrafi na każdym z systemów i kiedy zastąpi aplikację ze sklepu, pokazujemy na macierzy sprawdzonej u źródła.

Ta decyzja przesądza drogę do użytkownika — i to, czy drugą połowę projektu ustawiają Apple i Google.

„Potrzebujemy aplikacji w App Store i Google Play”

Jeśli sklep jest Wam potrzebny — bo klienci tam szukają, bo potrzebujecie funkcji telefonu albo płatności w aplikacji — budowa to tylko połowa pracy. Drugą połowę wyznaczają sklepy: konto firmy z numerem DUNS, test przed publikacją, przegląd każdej wersji i wymagania, które zmieniają się co roku.

Jak stworzyć aplikację na telefon dla firmy — od wyboru platformy, przez aplikacje natywne i wieloplatformowe, po drogę do sklepu z terminami podawanymi przez Apple i Google — opisujemy razem z tym, co pokazują nasze dane o telefonach gości: w ruchu firmowym iPhone'ów jest więcej, niż wynika ze statystyk ogólnych.

Ta decyzja przesądza, od której platformy zaczynacie i ile czasu trzeba doliczyć do terminu, zanim aplikacja trafi do użytkowników.

Pytania biznesowe mają osobny dział

Ten dział zakłada, że wiecie, co chcecie zbudować, i pytacie, jak. Jeśli wcześniej trzeba rozstrzygnąć, czy własne oprogramowanie w ogóle się opłaca, zajrzyjcie do działu aplikacje dla firm. Tam są teksty o tym, kiedy gotowe oprogramowanie wystarczy, a kiedy dedykowane się zwraca, o platformach low code i no code oraz o systemach, od których firmy najczęściej zaczynają: CRM dla małej firmy, system ERP i system rezerwacji online.

Narzędzia i dane

Ceny są w raportach, a nie w artykułach — żeby aktualizować je w jednym miejscu. Raport kosztów aplikacji webowych i raport kosztów aplikacji mobilnych zbierają mediany z ofert i cenników polskiego rynku, razem z metodologią i jej ograniczeniami. Kalkulator kosztu aplikacji webowej pokazuje różnicę między pierwszą wersją a pełnym produktem dla Waszego zakresu, a quiz „strona, aplikacja webowa czy mobilna” prowadzi przez pierwszą decyzję z tej mapy w kilku pytaniach.

Gdy aplikacja ma rozmawiać z innymi systemami — KSeF, GUS, bank, sklep czy kurier — pierwszym pojęciem, które trzeba rozumieć, jest API: czym jest, czym różni się od webhooka i jak zabezpieczyć integrację.

Kiedy szukacie wykonawcy

Jeśli decyzje są podjęte i szukacie firmy, która aplikację zbuduje, opisujemy, jak pracujemy przy aplikacjach webowych, aplikacjach mobilnych i MVP dla startupów.