Oprogramowanie
Aplikacje webowe
i mobilne na zamówienie
Są procesy, których nie da się zamknąć w arkuszu kalkulacyjnym ani w gotowym programie z półki. Wtedy taniej wychodzi napisać narzędzie dopasowane do tego, jak firma naprawdę pracuje — zamiast zmieniać firmę pod oprogramowanie.
Kiedy własna aplikacja ma sens, a kiedy jest przerostem formy
Aplikacja na zamówienie to jedna z droższych rzeczy, jakie firma może zamówić w informatyce, więc uczciwie mówimy, kiedy nie warto. Jeśli proces obsłuży gotowy program dostępny w abonamencie, a jedyną przeszkodą jest to, że wygląda brzydko — nie ma powodu pisać czegoś od zera.
Punkt, w którym własne narzędzie zaczyna się opłacać, jest zwykle dobrze widoczny. Ktoś w firmie codziennie przepisuje dane z jednego systemu do drugiego. Zamówienia przychodzą mailem i ktoś ręcznie wprowadza je do magazynu. Handlowcy trzymają swoje wersje cennika w plikach na pulpicie. Klienci dzwonią z pytaniem, na jakim etapie jest ich zlecenie, bo nie mają jak tego sprawdzić sami.
Każda z tych sytuacji ma wspólny mianownik: pracę, którą wykonuje człowiek, bo nie ma narzędzia. Godzina dziennie u dwóch osób to około pięciuset godzin rocznie. Przy takim rachunku aplikacja zwraca się w pierwszym roku, a przy okazji znikają błędy, które przy ręcznym przepisywaniu są nieuniknione.
Co najczęściej budujemy
Nie zajmujemy się wszystkim. Piszemy narzędzia biznesowe: takie, które obsługują konkretny proces, mają użytkowników z nazwiskami i muszą działać w poniedziałek rano. Nie robimy gier ani projektów badawczych.
- Panele klienta — podgląd zleceń, dokumentów, historii i płatności
- Systemy rezerwacji terminów, sal, sprzętu i usług
- Konfiguratory produktu z automatyczną wyceną i ofertą w PDF
- Wewnętrzne systemy obiegu dokumentów i akceptacji
- Aplikacje magazynowe współpracujące z kolektorami danych
- Portale B2B z indywidualnymi cennikami i limitami kupieckimi
- Kalkulatory i narzędzia sprzedażowe osadzane na stronie
- Integracje spinające systemy, które same ze sobą nie rozmawiają
Część z tych rzeczy da się zrobić jako rozszerzenie istniejącej strony albo sklepu — zobacz sklepy internetowe oraz integracje z ERP. Zawsze sprawdzamy tę drogę jako pierwszą, bo jest tańsza i szybsza.
Aplikacja webowa czy mobilna — co wybrać
To pytanie pada na pierwszej rozmowie i prawie zawsze odpowiedź brzmi: zacznij od webowej. Aplikacja webowa działa w przeglądarce, na każdym urządzeniu, bez instalowania czegokolwiek i bez czekania na akceptację w sklepie z aplikacjami. Aktualizacja jest natychmiastowa dla wszystkich użytkowników naraz.
Aplikacja mobilna instalowana ze sklepu ma sens wtedy, gdy potrzebuje rzeczy, których przeglądarka nie daje: pracy bez internetu, powiadomień push, dostępu do skanera kodów w trybie ciągłym albo pracy w terenie na słabym zasięgu. Jeśli żadnej z tych rzeczy nie potrzebujesz, aplikacja natywna to podwojony koszt utrzymania bez realnej korzyści.
Trzecia droga to aplikacja instalowalna z przeglądarki. Wygląda i działa jak mobilna, ma ikonę na ekranie telefonu i potrafi pracować offline, a powstaje z tego samego kodu co wersja webowa. W większości projektów, które robimy, to najrozsądniejszy kompromis.
| Rozwiązanie | Kiedy wybrać | Koszt względny |
|---|---|---|
| Aplikacja webowa | Praca przy komputerze, dostęp z wielu miejsc | podstawowy |
| Instalowalna z przeglądarki | Praca w terenie, potrzebne offline i ikona | +10–20% |
| Natywna iOS i Android | Kamera, GPS w tle, push, wymóg obecności w sklepie | +80–150% |
Analiza przed kodowaniem, czyli najtańszy etap projektu
Największe pieniądze w oprogramowaniu traci się nie na kodowaniu, tylko na budowaniu czegoś, czego nikt potem nie używa. Dlatego zaczynamy od tygodnia albo dwóch rozmów i obserwacji: kto wykonuje dany proces, w jakiej kolejności, gdzie sięga po dane i co robi, gdy coś idzie nie tak.
Z tych rozmów powstaje dokument z listą funkcji, opisem ról użytkowników i szkicami ekranów. Dopiero na jego podstawie wyceniamy prace i ustalamy harmonogram. Ten dokument jest Twój niezależnie od tego, czy zdecydujesz się na dalszą współpracę — możesz go zanieść do innej firmy i porównać oferty na tej samej podstawie.
Zdarza się, że analiza kończy się rekomendacją, żeby aplikacji nie pisać. Dwa razy w ostatnich latach okazało się, że proces do naprawienia był organizacyjny, a nie informatyczny. Powiedzieliśmy to wprost i było to uczciwsze niż sprzedanie projektu.
Wycena po analizie różni się od wyceny „na oko" zwykle o kilkadziesiąt procent — w obie strony. Lepiej poznać tę liczbę przed podpisaniem umowy niż w połowie prac.
Praca w krótkich odcinkach, z działającą wersją co dwa tygodnie
Nie robimy projektów, w których klient przez pół roku nie widzi nic, a potem dostaje gotową całość i okazuje się, że połowa działa inaczej, niż sobie wyobrażał. Pracujemy w dwutygodniowych odcinkach, po każdym pokazujemy działający fragment na środowisku testowym.
Ma to dwie zalety. Po pierwsze widzisz postęp i możesz reagować, dopóki zmiana jest tania — poprawka po dwóch tygodniach kosztuje ułamek tego, co przebudowa gotowego systemu. Po drugie kolejność prac ustalamy razem, więc najważniejsze funkcje powstają pierwsze i można ich używać, zanim projekt się skończy.
Środowisko testowe jest osobne od produkcyjnego przez cały czas trwania projektu, także po uruchomieniu. Dzięki temu każda późniejsza zmiana jest sprawdzana przed wypuszczeniem do użytkowników.
Na czym to piszemy i dlaczego akurat na tym
Backend piszemy w Pythonie albo PHP, w zależności od tego, z czym system ma się integrować i co klient już u siebie utrzymuje. Bazy danych to najczęściej PostgreSQL albo MySQL, a w projektach związanych z systemami magazynowymi także Microsoft SQL Server — zobacz bazy danych MSSQL.
Frontend budujemy tak lekko, jak się da. Nie każda aplikacja potrzebuje ciężkiego frameworka: panel z dwudziestoma ekranami działa szybciej i utrzymuje się taniej, gdy nie ciągnie za sobą dwóch megabajtów kodu. Cięższe narzędzia wprowadzamy tam, gdzie faktycznie są potrzebne — przy złożonych interfejsach z dużą liczbą stanów.
Zasada jest jedna: wybieramy technologie na tyle popularne, żeby za trzy lata dało się znaleźć kogokolwiek, kto to zrozumie. Egzotyczny wybór bywa przyjemniejszy w pracy, ale to klient zostaje z konsekwencjami.
Kod jest Twój — i to nie jest oczywistość
Po zakończeniu projektu przekazujemy pełny kod źródłowy wraz z dokumentacją i dostępami do wszystkich środowisk. Nie ma opłat licencyjnych za używanie własnej aplikacji i nie ma sytuacji, w której zmiana wykonawcy oznacza pisanie systemu od nowa.
Warto to sprawdzać w każdej ofercie, bo praktyka bywa różna. Część firm oddaje aplikację w modelu abonamentowym: płacisz co miesiąc, a gdy przestaniesz płacić, system się wyłącza. To bywa uczciwy układ, jeśli jest jasno opisany — problem zaczyna się wtedy, gdy nie jest.
- Umowa bez zapisu o przekazaniu kodu źródłowego
- Hosting wyłącznie u wykonawcy, bez możliwości przeniesienia
- Brak dokumentacji technicznej po zakończeniu prac
- Konta w usługach zewnętrznych założone na wykonawcę
- Opłata za każdą zmianę treści, także jednozdaniową
Co się dzieje po uruchomieniu
Aplikacja nie jest meblem — po wdrożeniu żyje dalej. Zmieniają się przepisy, systemy, z którymi się integruje, i sposób pracy w firmie. Dlatego po uruchomieniu proponujemy stałą opiekę: aktualizacje bezpieczeństwa, monitoring dostępności, kopie zapasowe i określoną pulę godzin na drobne zmiany.
Opieka nie jest obowiązkowa i nie blokuje niczego. Możesz przejąć utrzymanie samodzielnie albo zlecić je komukolwiek innemu — kod, dokumentacja i dostępy są po Twojej stronie od pierwszego dnia. W praktyce większość klientów zostaje, bo znamy projekt i drobna poprawka zajmuje nam pół godziny zamiast dnia.
Fachowe podejście do tematu i wykonanie zlecenia w umówionym terminie. Wszystko dopięte na ostatni guzik.
Ile kosztuje aplikacja na zamówienie
Podanie ceny bez analizy byłoby zgadywaniem, ale możemy pokazać rzędy wielkości, w których mieszczą się projekty realizowane dla małych i średnich firm. Poniższe kwoty dotyczą pierwszej działającej wersji, nie docelowego systemu ze wszystkimi pomysłami z listy życzeń.
| Rodzaj projektu | Przykład | Orientacyjny budżet |
|---|---|---|
| Narzędzie jednozadaniowe | Kalkulator, konfigurator, formularz z logiką | od ok. 6 000 zł |
| Panel wewnętrzny | Obieg zleceń, rezerwacje, prosty CRM | ok. 15 000 – 40 000 zł |
| System z integracjami | Portal B2B, panel klienta spięty z ERP | ok. 40 000 – 120 000 zł |
| Aplikacja mobilna natywna | iOS + Android z backendem | wycena indywidualna |
Rozliczamy się etapami, powiązanymi z odbiorem kolejnych fragmentów. Nie bierzemy całej kwoty z góry i nie zostawiamy sytuacji, w której płacisz za coś, czego jeszcze nie widziałeś działającego.
Współpraca
Jak to wygląda krok po kroku
Rozmowa i wstępna ocena
Opowiadasz o procesie, my mówimy, czy da się to zrobić taniej gotowym narzędziem.
Analiza i dokument
Rozmowy z osobami wykonującymi pracę, lista funkcji, szkice ekranów, wycena.
Projekt interfejsu
Klikalny prototyp — sprawdzamy układ, zanim powstanie choćby linijka kodu.
Budowa w odcinkach
Co dwa tygodnie działający fragment na środowisku testowym do obejrzenia.
Testy i szkolenie
Testy z udziałem przyszłych użytkowników, poprawki, szkolenie i instrukcja.
Uruchomienie i opieka
Wdrożenie produkcyjne, monitoring, przekazanie kodu i dostępów.
Pytania
Zanim zapytasz
Proste narzędzie 4–8 tygodni, panel wewnętrzny 3–4 miesiące, rozbudowany system z integracjami pół roku i więcej. Pierwszą użyteczną wersję staramy się oddać możliwie wcześnie, żeby dało się z niej korzystać w trakcie dalszych prac.
Tak i zwykle to zalecamy. Pierwsza wersja obejmuje jeden proces, a resztę dokładamy na podstawie tego, czego użytkownicy faktycznie potrzebują — a nie tego, co wydawało się potrzebne na etapie planowania.
Dostajesz kod źródłowy, dokumentację i wszystkie dostępy, więc przejęcie projektu przez inną firmę jest wykonalne. Nie stosujemy licencji ani blokad uzależniających klienta od nas.
Zwykle tak. Robimy integracje z Subiektem, Comarch Optima, systemami Insoft i innymi — zobacz integracje z ERP. Zakres zależy od tego, jakie możliwości wymiany danych ma konkretny system.
Na naszym serwerze, na Twoim albo w chmurze — do wyboru. Przy danych wrażliwych częściej wybiera się serwer w Polsce; przy dużych wahaniach obciążenia chmurę.
Pomagamy przygotować aplikację od strony technicznej: szyfrowanie, kontrola dostępu, logi, usuwanie danych na żądanie. Dokumentację prawną przygotowuje Twój inspektor ochrony danych — my dostarczamy opis techniczny, którego potrzebuje.
Powiązane usługi
Co jeszcze może się przydać
Twoje miasto
Aplikacje webowe w Twoim mieście
Dla każdego z tych miast mamy osobną stronę z lokalnym rynkiem, cenami i przykładami — a nie ten sam tekst z podmienioną nazwą.
Opowiedz o procesie, który zjada Wam czas
Wystarczy krótki opis tego, co dziś robi się ręcznie. Odpowiemy, czy da się to załatwić gotowym narzędziem, a jeśli nie — ile mniej więcej kosztowałoby własne.