Aplikacje webowe na zamówienie

Aplikacja webowa na zamówienie to system zbudowany wokół konkretnego procesu w firmie: obsługi zleceń, pracy z klientami, raportowania albo sprzedaży. Działa w przeglądarce, więc użytkownicy nie muszą niczego instalować, a zespół wdraża zmiany w jednym miejscu. W Odysse prowadzimy takie projekty od pierwszej rozmowy o celach po utrzymanie działającego systemu.

01Kiedy aplikacja webowa, a kiedy gotowe narzędzie

Nie każdy problem wymaga dedykowanego oprogramowania. Jeśli proces jest typowy, a gotowe narzędzie SaaS pokrywa go w całości, zwykle taniej i szybciej jest z niego skorzystać. Aplikacja na zamówienie ma sens, gdy:

• proces jest źródłem przewagi firmy i nie mieści się w szablonie gotowego narzędzia,
• dane są rozproszone w kilku systemach i trzeba je połączyć w jednym miejscu,
• koszt licencji i obejść w gotowych narzędziach rośnie razem z zespołem,
• aplikacja ma być produktem, który firma sprzedaje swoim klientom.

Typowe aplikacje webowe, które budujemy, to panele klienta, systemy obsługi zleceń, narzędzia wewnętrzne dla zespołów, platformy łączące wielu użytkowników i API udostępniające dane innym systemom.

Na etapie analizy mówimy wprost, jeśli naszym zdaniem lepszym wyborem jest gotowe rozwiązanie albo jego integracja z tym, czego firma już używa. Czasem najlepszym projektem jest mały moduł, który spina istniejące narzędzia, a nie nowy system od zera.

02Jak wygląda projekt

Pracujemy w siedmiu etapach: odkrycie, strategia, design, rozwój, testy, wdrożenie i skalowanie. Każde przekazanie jest udokumentowane i wersjonowane, więc w każdej chwili wiadomo, co jest gotowe i co dalej.

Projekt zaczyna się od rozmowy o celach biznesowych, użytkownikach i ograniczeniach. Jeśli aplikacja już istnieje, robimy audyt techniczny. Z tego powstaje zakres pierwszej wersji i kierunek architektury. Potem projektujemy interfejs i przepływy, a prototypy sprawdzamy, zanim zaczniemy pisać kod produkcyjny.

Rozwój prowadzimy iteracyjnie, na działającym środowisku. Zamiast czekać miesiącami na jedno duże oddanie, widzisz kolejne działające funkcje i możesz je sprawdzić na bieżąco. Dzięki temu zmiana priorytetów w trakcie projektu nie oznacza wyrzucania pracy do kosza.

Po stronie firmy potrzebujemy osoby, która zna proces i podejmuje decyzje produktowe. Z nią ustalamy priorytety, pokazujemy postępy po każdej iteracji i wspólnie decydujemy, co trafia do kolejnej wersji.

Przed wdrożeniem aplikacja przechodzi testy automatyczne, testy obciążeniowe i przegląd bezpieczeństwa. Wdrożenie odbywa się przez potoki CI/CD, z monitoringiem i kontrolowanym udostępnianiem nowej wersji.

03Technologie i architektura

Technologię dobieramy do problemu, a nie odwrotnie. Najczęściej pracujemy w takim zestawie:

• Frontend: React i Next.js z TypeScriptem. Next.js pozwala łączyć renderowanie po stronie serwera ze statycznymi stronami, co pomaga w szybkości i widoczności w wyszukiwarce.
• Backend: Node.js albo Laravel, zależnie od projektu i zespołu, który będzie go rozwijał.
• Dane: PostgreSQL albo MySQL, z modelem danych zaprojektowanym pod realne zapytania aplikacji.
• API: REST albo GraphQL. Wybieramy na podstawie tego, jak aplikacja korzysta z danych, a nie mody.
• Interfejs: Tailwind CSS i system komponentów, dzięki któremu kolejne widoki są spójne.

Przykłady z naszego portfolio: Data Flower to narzędzie do zgłaszania i śledzenia błędów zbudowane w React, TypeScript i Node.js. 4rom to platforma społecznościowa na Laravelu i Livewire. 3D Parser API to API do integracji modeli 3D z innymi aplikacjami.

Architekturę projektujemy tak, żeby aplikacja mogła rosnąć: moduły z jasnymi granicami, API opisane i wersjonowane, konfiguracja środowisk w repozytorium. Dzięki temu kolejny zespół albo kolejny etap projektu nie zaczyna od zgadywania, jak system działa.

Bezpieczeństwo jest częścią architektury, a nie dodatkiem na koniec. Uwierzytelnianie i uprawnienia projektujemy na początku, a integracje z systemami zewnętrznymi budujemy tak, żeby błąd po stronie jednego dostawcy nie zatrzymywał całej aplikacji: z ponawianiem prób i logowaniem błędów.

04Utrzymanie po wdrożeniu

Wdrożenie to początek życia aplikacji, a nie koniec projektu. Po starcie zajmujemy się aktualizacjami zależności, poprawkami bezpieczeństwa, monitoringiem i wydajnością. Śledzimy, jak użytkownicy korzystają z aplikacji, i na tej podstawie planujemy kolejne funkcje. Kod, konfiguracja i dokumentacja są wersjonowane w repozytorium, więc każda zmiana jest widoczna i odwracalna.

Koszt utrzymania warto uwzględnić w budżecie od początku. O tym, co najczęściej umyka przy planowaniu, piszemy w artykule o kosztach aplikacji webowej. Jeśli masz już aplikację, którą ktoś inny zbudował, możemy przejąć jej rozwój: zaczynamy wtedy od audytu kodu i infrastruktury, a potem ustalamy plan zmian.

Chcesz sprawdzić, czy aplikacja webowa na zamówienie to dobry kierunek dla Twojej firmy? Opisz nam proces, który chcesz usprawnić, a zaproponujemy, od czego zacząć.