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 lepiej sprawdza się narzędzie dopasowane do tego, jak firma naprawdę pracuje, niż zmienianie firmy pod oprogramowanie.
Kiedy własna aplikacja ma sens, a kiedy jest przerostem formy
Aplikacja na zamówienie to jedna z droższych inwestycji w informatyce firmy, dlatego mówimy wprost, kiedy się nie opłaca. Jeśli proces obsłuży gotowy program w abonamencie, a przeszkadza Ci w nim tylko wygląd, 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ą, żeby sprawdzić etap zlecenia, bo nie mają jak zrobić tego sami.
W każdej z tych sytuacji człowiek robi ręcznie to, co mogłoby robić narzędzie. Ta praca wraca codziennie, a przy przepisywaniu danych łatwo o pomyłki.
Co najczęściej budujemy
Piszemy narzędzia biznesowe, które obsługują konkretny proces w firmie i z których pracownicy albo klienci korzystają na co dzień. 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. Tę drogę sprawdzamy najpierw, bo zwykle jest tańsza i szybsza.
Aplikacja webowa czy mobilna: co wybrać
Zwykle zalecamy start od aplikacji webowej. Działa w przeglądarce na każdym urządzeniu, bez instalowania i bez czekania na akceptację w sklepie z aplikacjami. Aktualizacja trafia do wszystkich użytkowników naraz.
Aplikacja natywna na iOS i Android ma sens wtedy, gdy potrzebuje rzeczy, których przeglądarka nie daje: pracy bez internetu w terenie, powiadomień push, stałego dostępu do skanera kodów albo obecności w sklepie z aplikacjami. Bez tych potrzeb aplikacja natywna głównie podnosi koszt budowy i utrzymania.
Trzecia droga to aplikacja instalowalna z przeglądarki (PWA). Ma ikonę na ekranie telefonu, potrafi pracować offline i powstaje z tego samego kodu co wersja webowa. Bywa rozsądnym kompromisem między aplikacją webową a natywną.
| Rozwiązanie | Kiedy wybrać |
|---|---|
| Aplikacja webowa | Praca przy komputerze, dostęp z wielu miejsc |
| Instalowalna z przeglądarki (PWA) | Praca w terenie, potrzebny tryb offline i ikona na telefonie |
| Natywna iOS i Android | Kamera, GPS w tle, powiadomienia push, wymóg obecności w sklepie z aplikacjami |
Analiza przed kodowaniem: od niej zależy wycena
Drogie w oprogramowaniu są zwłaszcza funkcje, z których użytkownicy potem nie korzystają. 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. Dokument zostaje u Ciebie niezależnie od tego, czy zdecydujesz się na dalszą współpracę. Możesz z nim pójść do innej firmy i porównać oferty na tej samej podstawie.
Zdarza się, że analiza kończy się rekomendacją, żeby aplikacji nie pisać, bo problem okazuje się organizacyjny, a nie informatyczny. Wtedy to piszemy w dokumencie.
Koszt i harmonogram znasz przed podpisaniem umowy, a nie dopiero w trakcie prac.
Praca w krótkich odcinkach, z działającą wersją co dwa tygodnie
Pracujemy w dwutygodniowych odcinkach i po każdym pokazujemy działający fragment na środowisku testowym. Nie ma więc sytuacji, w której przez pół roku nie widzisz nic, a na końcu okazuje się, że połowa działa inaczej, niż sobie wyobrażałeś.
Ma to dwie zalety. Po pierwsze widzisz postęp i możesz reagować, dopóki zmiana jest tania: poprawka po dwóch tygodniach kosztuje znacznie mniej niż przebudowa gotowego systemu. Po drugie kolejność prac ustalamy razem, więc najważniejsze funkcje powstają pierwsze i można z nich korzystać, zanim projekt się skończy.
Środowisko testowe jest oddzielone od produkcyjnego przez cały projekt i po uruchomieniu. Każdą późniejszą zmianę sprawdzamy na nim, zanim trafi do użytkowników.
Na czym to piszemy i dlaczego akurat na tym
Backend piszemy w Pythonie (FastAPI) albo PHP (Laravel), zależnie 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. Więcej o tym przy bazach danych MSSQL.
Frontend budujemy możliwie lekko. Nie każda aplikacja potrzebuje ciężkiego frameworka: prosty panel bez zbędnych bibliotek działa szybciej i taniej się go utrzymuje. React albo Vue stosujemy przy złożonych interfejsach z dużą liczbą stanów.
Wybieramy popularne technologie, żeby projekt mógł w przyszłości przejąć inny zespół.
Kod źródłowy zostaje u Ciebie
Po zakończeniu projektu przekazujemy pełny kod źródłowy wraz z dokumentacją i dostępami do wszystkich środowisk. Nie pobieramy opłat licencyjnych za używanie aplikacji i nie stosujemy blokad, przez które zmiana wykonawcy oznaczałaby pisanie systemu od nowa.
Warto to sprawdzić w każdej ofercie. Aplikacja udostępniana w abonamencie, która przestaje działać po zakończeniu płatności, bywa uczciwym układem, jeśli umowa jasno to opisuje. Problem pojawia się, gdy takiego zapisu brakuje. Sygnały ostrzegawcze w ofercie:
- 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
Po wdrożeniu aplikacja nadal się zmienia. Zmieniają się przepisy, systemy, z którymi się integruje, i sposób pracy w firmie. Dlatego 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. Utrzymanie możesz przejąć samodzielnie albo zlecić innej firmie, bo po zakończeniu projektu kod, dokumentacja i dostępy są po Twojej stronie. Przy opiece u nas drobne poprawki idą szybciej, bo znamy projekt od środka.
Szybka i konkretna robota. Chłopaki wiedzą, co robią.
Od czego zależy koszt aplikacji
Podanie ceny bez analizy byłoby zgadywaniem. Koszt zależy od liczby funkcji i ról użytkowników, integracji z innymi systemami oraz wymagań co do pracy offline i aplikacji natywnej. Każdy projekt wyceniamy indywidualnie, po analizie. Poniżej typowe rodzaje projektów. Pierwsza działająca wersja zwykle obejmuje mniejszy zakres niż docelowy system.
| Rodzaj projektu | Przykład |
|---|---|
| Narzędzie jednozadaniowe | Kalkulator, konfigurator, formularz z logiką |
| Panel wewnętrzny | Obieg zleceń, rezerwacje, prosty CRM |
| System z integracjami | Portal B2B, panel klienta spięty z ERP |
| Aplikacja mobilna natywna | iOS i Android z backendem |
Rozliczamy się etapami, powiązanymi z odbiorem kolejnych fragmentów. Nie pobieramy całej kwoty z góry, więc nie płacisz za coś, czego jeszcze nie widziałeś w działaniu.
Współpraca
Jak wygląda współpraca krok po kroku
Rozmowa i wstępna ocena
Opisujesz proces, a my mówimy, czy da się go obsłużyć taniej gotowym narzędziem.
Analiza i dokument
Rozmowy z osobami wykonującymi pracę, lista funkcji, szkice ekranów, wycena.
Projekt interfejsu
Klikalny prototyp, na którym sprawdzamy układ ekranów przed kodowaniem.
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
Najczęstsze pytania
Zależy od zakresu: proste narzędzie powstaje szybciej niż panel wewnętrzny, a system z integracjami trwa najdłużej. Dokładny harmonogram ustalamy po analizie. 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ą w codziennej pracy.
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. Integrujemy aplikacje między innymi z Subiektem i systemami Insoft. Zakres zależy od tego, jakie możliwości wymiany danych ma konkretny system. Szczegóły opisujemy przy integracjach z ERP.
Na naszym serwerze, na Twoim albo w chmurze, do wyboru. Przy danych wrażliwych częściej wybiera się serwer w Polsce, a przy dużych wahaniach obciążenia chmurę.
Pomagamy przygotować aplikację od strony technicznej: szyfrowanie, kontrola dostępu, logi, usuwanie danych na żądanie. Dokumentację prawną przygotowujesz po swojej stronie, zwykle z inspektorem ochrony danych, a my dostarczamy mu opis techniczny.
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 opisem lokalnego rynku i tego, jak pracujemy z firmami z tego miasta.
Opisz proces, który dziś zabiera najwięcej czasu
Napisz krótko, co w firmie robi się ręcznie. W 24 godziny odpowiemy, czy da się to załatwić gotowym narzędziem, a jeśli nie, od czego zależy koszt własnego.