Tworzenie aplikacji webowych

Kiedy warto zbudować własną aplikację webową

Firmy trafiają do nas najczęściej w jednym z trzech momentów. Pierwszy: proces, który do tej pory dawało się obsłużyć arkuszem i skrzynką mailową, zaczyna się sypać. Dane leżą w kilku miejscach naraz, nikt nie wie, która wersja pliku jest aktualna, a każda nowa osoba w zespole potrzebuje tygodnia, żeby się w tym połapać.

Drugi moment to gotowe oprogramowanie, które prawie pasuje. Płacisz abonament za dwadzieścia funkcji, korzystasz z trzech, a tej jednej, na której naprawdę Ci zależy, nie da się dodać. Wtedy własna aplikacja przestaje być fanaberią i staje się zwykłym rachunkiem: ile kosztuje licencja przez trzy lata w porównaniu z narzędziem dopasowanym dokładnie do Twojego procesu.

Trzeci to nowy produkt. Masz pomysł, masz pierwszych zainteresowanych klientów i potrzebujesz wersji, którą można im pokazać, sprzedać i rozwijać na podstawie tego, co powiedzą. Tak powstał Rentastic - nasz system dla wypożyczalni samochodów, który rozwijaliśmy od pierwszej makiety w dialogu z realnymi użytkownikami.

Jak wygląda praca nad projektem

Zaczynamy od rozmowy o procesie, a nie o technologii. Chcemy zrozumieć, kto będzie korzystał z aplikacji, jakie decyzje musi w niej podejmować i co dziś zabiera najwięcej czasu. Z tej rozmowy powstaje krótki dokument: lista funkcji podzielona na te, które muszą znaleźć się w pierwszej wersji, i te, które spokojnie mogą poczekać.

Potem projektujemy ekrany. Zanim napiszemy pierwszą linię kodu, widzisz klikalny układ aplikacji i możesz powiedzieć, że coś jest nie tak - na tym etapie zmiana kosztuje godzinę, a nie tydzień. Dopiero zaakceptowany projekt idzie do implementacji.

Wdrażamy przyrostowo. Regularnie dostajesz działającą wersję pod osobnym adresem, którą można kliknąć i przetestować na swoich danych. Dzięki temu nie zdarza się sytuacja, w której dopiero na końcu okazuje się, że zbudowaliśmy coś innego, niż miałeś w głowie.

Po uruchomieniu zostajemy. Aplikacja, której nikt nie aktualizuje, po roku staje się problemem bezpieczeństwa, dlatego domyślnie proponujemy opiekę: aktualizacje bibliotek, monitoring błędów, kopie zapasowe i ustalony czas reakcji na zgłoszenia.

• -Warsztat i ustalenie zakresu pierwszej wersji
• -Projekt interfejsu do akceptacji przed kodowaniem
• -Regularne wydania na środowisku testowym
• -Wdrożenie produkcyjne i przekazanie wszystkich dostępów
• -Opieka powdrożeniowa i dalszy rozwój

Technologie, na których budujemy

Warstwę widoczną dla użytkownika piszemy w React i Next.js z TypeScriptem. Next.js renderuje strony po stronie serwera, co ma dwie praktyczne konsekwencje: użytkownik widzi treść od razu, zanim doładuje się cały JavaScript, a Google indeksuje pełną zawartość strony zamiast pustej skorupy. Dla aplikacji, które mają być również znajdowane w wyszukiwarce, to różnica między widocznością a jej brakiem.

TypeScript wybieramy świadomie. Kosztuje trochę więcej czasu na starcie i oddaje go przy każdej kolejnej zmianie - sporą część błędów, które w zwykłym JavaScripcie wychodzą dopiero u użytkownika, kompilator wyłapuje, zanim kod opuści nasze maszyny.

Po stronie serwera pracujemy z Node.js i Pythonem, dane trzymamy najczęściej w PostgreSQL. Wdrażamy na Cloudflare, Vercel lub AWS - wybór zależy od tego, gdzie są Twoi użytkownicy, jaki ruch przewidujesz i jakie masz wymagania co do miejsca przechowywania danych.

• -Next.js, React, TypeScript, Tailwind CSS
• -Node.js i Python po stronie serwera
• -PostgreSQL, Redis, obiektowe magazyny plików
• -Cloudflare, Vercel, AWS
• -GitHub Actions i automatyczne wdrożenia

Wydajność i dostępność nie są dodatkiem

Szybkość ładowania mierzymy, a nie deklarujemy. Każdy projekt sprawdzamy w Lighthouse i pilnujemy Core Web Vitals: czasu wyświetlenia największego elementu, stabilności układu podczas ładowania i czasu reakcji na pierwsze kliknięcie. To parametry, które Google bierze pod uwagę przy ustalaniu pozycji, ale przede wszystkim decydują o tym, czy ktoś w ogóle zostanie na stronie.

Podobnie traktujemy dostępność. Odpowiedni kontrast, pełna obsługa klawiaturą, poprawna semantyka znaczników i opisy alternatywne obrazów są u nas standardem, bo kosztują niewiele, gdy robi się je od początku, i bardzo dużo, gdy trzeba je dokładać po fakcie. Przy okazji to ta sama praca, która sprawia, że aplikację rozumieją roboty wyszukiwarek.

Ile to kosztuje i ile trwa

Nie publikujemy cennika w tabelce, bo narzędzie dla trzech osób i system dla stu użytkowników to dwa różne projekty. Każdy projekt wyceniamy indywidualnie, a szczegóły ustalamy w rozmowie - zarówno koszt, jak i czas realizacji zależą od zakresu i mogą się różnić. Jeżeli w trakcie pojawia się nowy pomysł, wyceniamy go osobno, zamiast po cichu przesuwać termin.

Harmonogram ustalamy razem z wyceną, kiedy znamy już zakres. Prosty panel albo portal powstaje wyraźnie szybciej niż rozbudowany system z rolami, płatnościami i integracjami, ale konkretny termin podajemy dopiero wtedy, gdy wiemy, co dokładnie budujemy. Rozliczamy się etapami - płacisz za kolejne działające fragmenty, a nie za obietnicę.

Gdzie pracujemy

Mamy siedzibę w Rybniku i chętnie spotykamy się z klientami z całego Śląska: z Żor, Jastrzębia-Zdroju, Raciborza, Wodzisławia Śląskiego, Gliwic i Katowic. Większość pracy prowadzimy jednak zdalnie, więc lokalizacja Twojej firmy nie ogranicza współpracy - obsługujemy klientów z całej Polski. Spotykamy się na miejscu, kiedy to naprawdę pomaga, i na wideorozmowie, kiedy jest to po prostu szybsze.