Aplikacje webowe i SaaS

Jakie aplikacje buduję dla firm

Każda z nich to narzędzie otwierane w przeglądarce, które pracuje na Twoich danych: ma konta, uprawnienia, własną bazę i logikę wynikającą z procesu firmy.

Różnica między stroną a aplikacją nie leży w wyglądzie, tylko w tym, co dzieje się po zalogowaniu. Strona przedstawia ofertę, aplikacja prowadzi pracę: przyjmuje dane, pilnuje statusów, liczy, przypomina i zostawia ślad tego, kto co zmienił.

Dlatego zaczynam nie od ekranów, tylko od procesu. Najpierw ustalamy, kto będzie z narzędzia korzystał i jaką decyzję ma w nim podjąć, a dopiero potem, co faktycznie pojawi się na ekranie.

Przykład z produkcji to platforma kursów online z quizem, koszykiem, płatnościami BLIK i kartą przez Stripe, fakturami w Fakturowni, strefą kursanta i panelem właściciela, którą zbudowałem od zera. Na jej stronie opisuję zakres, technologię i to, co system robi, gdy powiadomienie z bramki płatności nie dotrze.

• Panel administracyjnyJedno miejsce do zarządzania treścią, cennikiem, zamówieniami lub użytkownikami. Sprawdza się tam, gdzie zespół edytuje dziś te same dane w kilku plikach naraz.
• Portal klienta i B2BKlient loguje się i widzi swoje zamówienia, dokumenty, statusy i limity. W handlu B2B dochodzą indywidualne cenniki i zamówienia powtarzalne, których nie obsłuży zwykły sklep.
• Lekki CRM lub system zgłoszeńZamiast rozbudowanego pakietu powstaje wąskie narzędzie pod jeden proces sprzedaży albo serwisu, z polami i etapami nazwanymi tak, jak nazywa je zespół.
• System rezerwacji i grafikówKalendarz zasobów, dostępność, potwierdzenia mailem i reguły, których nie da się ustawić w gotowym kalendarzu, na przykład zależności między usługą, sprzętem i osobą. Porównanie opcji: system rezerwacji online: gotowy program czy własny.
• Obieg dokumentów i akceptacjiWniosek, faktura kosztowa albo umowa przechodzi przez ustalone osoby, a system pilnuje kolejności, terminów i historii decyzji.
• Produkt SaaS z subskrypcjąNarzędzie sprzedawane w abonamencie: rejestracja, plany, limity, płatności cykliczne i panel rozliczeń. Tutaj najwięcej pracy leży poza głównym ekranem produktu.

Dedykowane oprogramowanie, gotowy SaaS czy no-code

Nie każdy problem wymaga pisania programu od zera. Warto to rozstrzygnąć przed wyceną, bo najdroższy jest projekt, który odtwarza gotowe narzędzie.

Gotowy SaaS wygrywa wtedy, gdy Twój proces przypomina rynkowy standard: fakturowanie, księgowość, poczta, prosty CRM. Płacisz abonament, dostajesz aktualizacje i wsparcie, a w zamian dopasowujesz sposób pracy do narzędzia. To uczciwa wymiana, dopóki nie zaczynasz obchodzić programu arkuszami i notatkami.

No-code, czyli Airtable, Bubble i podobne platformy, jest dobry na start i na sprawdzenie pomysłu w kilka tygodni. Pułapka pojawia się przy skali i przy wyjściu: płacisz za kolejne progi rekordów, użytkowników albo zużycia, a dane wyeksportujesz, lecz działającej aplikacji nie przeniesiesz na własny serwer.

Własny system proponuję, gdy proces jest przewagą firmy, gdy dane muszą zostać pod Twoją kontrolą albo gdy przy rosnącym zespole abonament liczony za osobę przestaje się spinać. Najzdrowszy bywa układ mieszany: rzeczy standardowe zostają w gotowych narzędziach, a piszę tylko to, co naprawdę Twoje.

Cenniki dostawców i przepisy się zmieniają, więc przed decyzją sprawdź je u źródła.

Dedykowana aplikacja, gotowy SaaS i no-code: co realnie różni te trzy drogi. Ceny i limity Airtable oraz Bubble według stron producentów.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

MVP: co wchodzi do pierwszej wersji, a co poczeka

MVP to nie jest tańsza ani niedokończona wersja produktu. To najkrótsza droga do sprawdzenia jednego założenia biznesowego na prawdziwych danych i prawdziwych użytkownikach.

Dobre MVP ma jedną ścieżkę zrobioną porządnie od początku do końca zamiast dziesięciu zaczętych. Jeśli narzędzie ma przyjmować zgłoszenia, to zgłoszenie musi dać się dodać, przypisać, rozliczyć i zamknąć, nawet gdy reszta ekranów jeszcze nie istnieje.

Spokojnie poczekają natomiast rozbudowane raporty, konfigurator uprawnień dla dziesięciu ról, wielojęzyczność, tryb ciemny oraz integracje, o które nikt jeszcze nie pytał. Wracamy do nich wtedy, gdy wiadomo, czy i jak ludzie korzystają z pierwszej wersji.

Od MVP proponuję zacząć także wtedy, gdy budżet pozwala na więcej. Lista priorytetów i tak zmieni się po pierwszych tygodniach pracy na żywym narzędziu, więc lepiej, żeby zmieniała się na małym zakresie. Widełki kosztu, to, czego nie wolno wyciąć, i odpowiedź, czy pierwsza wersja musi być aplikacją mobilną, zebrałem w przewodniku ile kosztuje MVP.

• Jedna kompletna ścieżkaNajważniejsze zadanie użytkownika da się wykonać do końca, bez ręcznego poprawiania rekordów w bazie po drodze.
• Konta i minimum rólZwykle wystarczą dwie role: osoba pracująca w narzędziu i administrator. Uprawnienia rozbudowuje się później, gdy widać realne wyjątki.
• Dane, których nie dołoży się późniejStruktura bazy i identyfikatory rekordów. Zmiana modelu danych po starcie zwykle kosztuje więcej niż nowy ekran, bo pociąga za sobą migrację rekordów, które już istnieją.
• Plan wyjściaEksport do pliku i dostęp do bazy. Dzięki temu nawet nieudany eksperyment zostawia dane, z których da się korzystać dalej.
• Prosty pomiarKilka liczb mówiących, czy narzędzie jest używane: liczba zgłoszeń, czas obsługi, liczba aktywnych kont w tygodniu.

Co trzeba zbudować poza ekranami, o których myślisz na starcie

Na pierwszej rozmowie mówimy o widokach i funkcjach. Praca, która decyduje o spokoju po wdrożeniu, leży gdzie indziej i lepiej wycenić ją od razu, niż dokładać awaryjnie.

• Konta, role i zapraszanieLogowanie, reset hasła, dezaktywacja pracownika, który odchodzi. Uprawnienia sprawdzam po stronie serwera, bo ukrycie przycisku w interfejsie niczego nie chroni.
• Panel administracyjnyMiejsce, w którym sam poprawisz dane, cennik czy status bez dzwonienia do mnie. Kto wytnie go z zakresu, ten każdą literówkę w cenniku zamieni w zlecenie dla programisty.
• Logi i historia zmianZapis, kto i kiedy zmienił rekord. Bez tego reklamacja kończy się słowem przeciwko słowu, a błąd w danych jest nie do odtworzenia.
• Kopie zapasowe i odtwarzanieKopia ma wartość dopiero wtedy, gdy raz odtworzyliśmy ją na środowisku testowym. Ustalamy, jak często powstaje i ile dni wstecz obejmuje.
• PowiadomieniaMail, powiadomienie w aplikacji albo wiadomość do zespołu przy zmianie statusu. Od razu ustalamy, kto może je wyłączyć, żeby narzędzie nie zamieniło się w hałas.
• RODO w praktyceZakres zbieranych danych, czas przechowywania, obsługa usunięcia konta oraz umowa powierzenia przetwarzania (art. 28 RODO) z każdym dostawcą, u którego te dane realnie leżą, z hostingiem włącznie.
• Faktury i KSeFJeśli system wystawia faktury VAT, musi je wysyłać do Krajowego Systemu e-Faktur, obowiązkowego od 2026 r. Terminy dla poszczególnych firm, wyjątki do końca 2026 r. i sposób połączenia opisuję w przewodniku KSeF: integracja przez API. Często prościej podłączyć system fakturowy, który już to obsługuje, niż pisać własną wysyłkę.
• Środowisko testoweOsobna kopia systemu do sprawdzania zmian. Bez niej każda poprawka jest testowana na żywym ruchu i na danych klientów.

Jak pracuję etapami i co widzisz po drodze

Pracujesz bezpośrednio ze mną, więc ustalenia nie przechodzą przez dział projektowy ani opiekuna klienta. Każdy etap kończy się czymś, co możesz otworzyć, przeczytać albo kliknąć.

1. Rozmowa i zakresPytam o cel, o to, kto będzie na co dzień pracował w systemie, i o to, co dziś przeszkadza. Wychodzę z tego z listą funkcji podzieloną na pierwszą wersję i dalsze etapy.
2. Warsztat i model danychRozrysowujemy proces krok po kroku, razem z wyjątkami, o których zwykle nikt nie wspomina na początku. Na tej podstawie powstaje model danych i to on najmocniej wpływa na późniejszy koszt zmian.
3. Projekt najważniejszych widokówProjektuję ekrany, od których zależy cała reszta: listę, formularz i widok szczegółów. Oglądasz je, zanim powstanie kod.
4. Kolejne działające wersjeDostajesz link do wersji testowej i sprawdzasz ją na swoim sprzęcie oraz na telefonie. Uwagi zbieram w jednym miejscu, żeby było widać, co jest poprawką, a co nowym zakresem.
5. Testy na prawdziwych danychPrzechodzimy uzgodnione scenariusze na próbce Twoich danych, łącznie z sytuacjami błędnymi: zdublowany rekord, brak uprawnień, przerwana płatność.
6. Wdrożenie i przekazanieUruchomienie pod docelowym adresem, przeniesienie danych, krótkie szkolenie zespołu oraz przekazanie dostępów i dokumentacji.

Technologie: czego używam i dlaczego akurat tego

Wybieram narzędzia, które sam utrzymam i które ktoś inny będzie umiał przejąć. Egzotyczny zestaw technologii jest ryzykiem dla Ciebie, nie dla mnie.

Interfejs buduję w Angularze albo w React z Next.js. Angular biorę do rozbudowanych paneli z dużą liczbą formularzy i stanów, bo ma jeden przewidywalny sposób robienia rzeczy i jawny kalendarz wydań. Według angular.dev od wersji 22 wersja główna wychodzi co 12 miesięcy (wcześniej co 6) i ma zwykle 24 miesiące wsparcia, z czego ostatni rok to już tylko poprawki krytyczne i bezpieczeństwa. React z Next.js wybieram tam, gdzie liczy się też część publiczna, treści i indeksowanie, a panel jest jej uzupełnieniem.

Logikę piszę w TypeScript po obu stronach, bo ten sam opis danych obowiązuje w formularzu i przy zapisie do bazy, więc literówkę w nazwie pola wyłapuje kompilator, zanim kod trafi na serwer.

Dane trzymam zwykle w PostgreSQL, z prozaicznego powodu: to baza relacyjna o przewidywalnym cyklu życia. Według postgresql.org każda wersja główna ma pięć lat wsparcia, a poprawki wychodzą co najmniej raz na trzy miesiące. Jako usługę zarządzaną oferują ją między innymi Azure (Azure Database for PostgreSQL), AWS (Amazon RDS) i Google Cloud (Cloud SQL), więc przy zmianie dostawcy nie trzeba zmieniać bazy. Płatności i subskrypcje podpinam przez Stripe.

Nie wszystko musi być napisane od zera. Jeśli część procesu obsłuży n8n, arkusz albo gotowa usługa, mówię to wprost i wyceniam integrację zamiast kolejnego modułu do utrzymania.

Własność kodu, przekazanie i opieka po wdrożeniu

Narzędzie ma działać także wtedy, gdy nasza współpraca się skończy. Dlatego przekazanie planuję od początku, a nie na ostatniej rozmowie.

Zasadę zapisujemy w umowie: prawa majątkowe do kodu i projektu graficznego przechodzą na Ciebie po rozliczeniu etapu. Repozytorium zakładamy na Twoim koncie albo przenoszę je do Ciebie przy zamknięciu prac, razem z pełną historią zmian. Osobno przekazuję listę bibliotek i czcionek innych autorów, bo te zachowują własne licencje.

Konta u dostawców zakładam na Twoją firmę: domena, hosting, baza, Stripe, usługa wysyłki maili. To nudny szczegół, który decyduje o tym, czy w razie rozstania trzeba cokolwiek odzyskiwać.

Przy przekazaniu dostajesz krótką dokumentację: jak uruchomić projekt, gdzie leżą dane, jak powstaje kopia zapasowa i co zrobić, gdy coś przestanie działać. Piszę ją po polsku, dla osoby technicznej, która wejdzie w projekt po mnie.

Utrzymanie ustalamy osobno, bo oprogramowanie żyje: biblioteki dostają poprawki bezpieczeństwa, dostawcy zmieniają swoje API, a firma zmienia proces. Opieka może obejmować aktualizacje, monitorowanie błędów i pulę godzin na zmiany. Jeśli wolisz, żeby rozwijał ją Twój zespół, przygotowuję projekt tak, aby dało się go przejąć.

Utrzymanie wyceniam jako opiekę po wdrożeniu: widełki to 300–⁠900 zł netto miesięcznie, a to, że chodzi o aplikację, a nie o stronę, jest jednym z czynników, które podnoszą kwotę. Opieka nie jest warunkiem wykonania projektu. Co wchodzi w zakres i od czego zależy kwota.

Od czego zależy budżet i czas realizacji

Wycenę przygotowuję po rozmowie, bo ten sam brief potrafi opisywać bardzo różne projekty: „portal klienta z zamówieniami” to raz lista zamówień z jednego systemu, a raz indywidualne cenniki, limity kupieckie i synchronizacja z ERP. Poniżej to, co realnie przesuwa koszt w jedną albo w drugą stronę.

W moim cenniku aplikacja webowa lub MVP kosztuje od 20 000 zł netto za projekt. Dolna granica obejmuje warsztat zakresu, projekt interfejsu, kod od ekranu po bazę, konta z rolami, panel administracyjny, kopie zapasowe, logi i wdrożenie na serwer. Górnej granicy nie podaję, bo wyznaczają ją role, płatności, integracje i wymagania formalne opisane niżej.

Do budżetu warto policzyć koszty, które zostają po wdrożeniu: hosting i baza, domena, wysyłka maili, ewentualne licencje oraz prowizje od płatności. Oficjalny cennik Stripe dla Polski (stripe.com/pl/pricing) podaje 1,5% plus 1 zł od standardowej karty z Europejskiego Obszaru Gospodarczego, 1,9% plus 1 zł od karty premium, 1,6% plus 1 zł od BLIK i 1,9% plus 1 zł od Przelewy24. Wypłaty i faktury opisuję w przewodniku prowizja Stripe w Polsce.

Po ustaleniu zakresu dostajesz plan etapów z kolejnością prac, a gdy coś zaczyna się przesuwać, mówię o tym w tym samym tygodniu, a nie na końcu projektu. Terminy i kwoty, które dla pierwszej wersji podają w swoich cennikach polskie firmy programistyczne, zestawiłem ze źródłami w przewodniku o kosztach MVP.

Jeśli budżet nie domyka się od razu, dzielimy zakres. Zwykle da się uruchomić wersję obsługującą jeden proces, a resztę dołożyć wtedy, gdy narzędzie zacznie zarabiać albo oszczędzać czas zespołu.

• Liczba ról i wyjątkówDwie role to dwie ścieżki. Pięć ról z osobnymi regułami dla klienta zewnętrznego to kilkanaście kombinacji do zaprojektowania, zbudowania i sprawdzenia.
• IntegracjeKażdy zewnętrzny system to osobna praca: uwierzytelnianie, limity, obsługa błędów i powtórzonych zdarzeń. Koszt zależy tu od jakości cudzej dokumentacji.
• Migracja danychPrzeniesienie historii z arkuszy lub starego systemu bywa droższe niż ekran, który ją wyświetla, bo dane trzeba wyczyścić i pogodzić ze sobą.
• Wymagania formalnePrzetwarzanie danych wrażliwych, dostępność według WCAG, wymogi branżowe albo audyt u klienta końcowego oznaczają więcej testów i więcej dokumentacji.
• Tempo decyzji po Twojej stronieGdy etap czeka na treści, dostęp do systemu albo akceptację jednej osoby, stoi tak samo, jakby w kodzie był błąd. Dlatego każda taka zależność dostaje w planie termin i osobę odpowiedzialną po Twojej stronie.