Wdrożenie aplikacji webowej

Bezpłatna konsultacja Projekty

Projekt w Figmie zamieniamy w działającą aplikację w przeglądarce - front w React i TypeScript, podpięty do Waszego API, z rolami, uprawnieniami i stanami brzegowymi obsłużonymi na ekranie, nie w komentarzu do makiety.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Trzy momenty, w których warto oddać front na zewnątrz

Nie wiesz, czy Wam potrzebny front w kodzie, czy wystarczy platforma bez programowania? Zobacz wdrożenie no-code albo umów rozmowę - powiemy wprost, kiedy kod jest przerostem formy.

  • „Projekt utknął między Figmą a backlogiem”

    Makiety są odebrane i zatwierdzone, ale zespół inżynieryjny ma zajęte kwartały i front wchodzi do planu dopiero za dwa wydania. Przejmujemy warstwę przeglądarkową, Wasi programiści zostają przy API i logice biznesowej, której nikt z zewnątrz i tak nie przejmie lepiej.

  • „Panel operacyjny urósł ekranami, których nikt nie projektował”

    Narzędzie wewnętrzne powstawało funkcja po funkcji, każda dokładana przez innego programistę pod presją zgłoszenia. Dziś obsługa jednego zamówienia wymaga trzech zakładek i wiedzy plemiennej. Projektujemy i wdrażamy warstwę front na nowo, moduł po module, na tym samym API.

  • „Backend jest gotowy, frontu nie ma kto napisać”

    Macie API, bazę i zespół, który je utrzymuje, ale nikogo, kto zbuduje interfejs powyżej poziomu surowej tabeli. Wchodzimy z parą projektant plus frontend developer i domykamy warstwę widoczną dla użytkownika, bez rekrutacji na etat.

Dla kogo

Dla kogo wdrażamy aplikacje webowe

  • Firmy SaaS, w których produkt trzyma się na jednym inżynierze

    Backend rozwija się szybciej, niż front nadąża go pokazać, a każda nowa funkcja ląduje w interfejsie jako kolejna zakładka doklejona przez osobę zajętą czym innym. Przejmujemy warstwę przeglądarkową i porządkujemy ją w bibliotekę widoków, żeby dokładanie funkcji przestało oznaczać dokładanie chaosu.

  • Zespoły operacyjne pracujące na arkuszach i narzędziach wewnętrznych

    Codzienna praca dzieje się w kilku arkuszach, mailu i systemie, do którego nikt nie ma pełnej dokumentacji, a błąd wychodzi dopiero u klienta. Składamy z tego jeden panel w przeglądarce, zaczynając od procesu, który kosztuje zespół najwięcej przełączeń między narzędziami.

  • Producenci systemów branżowych wchodzących do przeglądarki

    System działa od lat jako aplikacja instalowana na stanowisku, a klienci pytają o dostęp z laptopa i o pracę wielu osób jednocześnie. Budujemy warstwę webową na istniejącej logice, moduł po module, tak żeby stara i nowa wersja mogły przez jakiś czas działać obok siebie.

  • Software house'y potrzebujące frontu na podwykonawstwo

    Projekt jest sprzedany, backend macie obsadzony, a warstwa przeglądarkowa wypada z terminu, bo brakuje rąk albo kompetencji projektowych. Pracujemy pod Waszą marką, w Waszym repozytorium i Waszym rytmie wydań, a relacja z klientem zostaje po Waszej stronie.

Wydruki czterech układów interfejsu na stole: pulpit, ekran telefonu, formularz i tabela, jeden blok zakreślony markerem

Nasza różnica

Czym różni się nasze wdrożenie

  • Kontrakt danych spisany przed pierwszym ekranem

    Zanim powstanie widok, ustalamy z Waszym backendem, jakie pola przychodzą, co może być puste, jak wygląda błąd i skąd front wie o uprawnieniach użytkownika. To tydzień pracy, który zdejmuje z projektu najdroższą kategorię poprawek - przerabianie gotowych ekranów, bo dane wyglądają inaczej, niż zakładała makieta.

  • Projektant i developer to u nas jedna para, nie dwa etapy

    Ta sama para prowadzi projekt od makiety do wydania, więc decyzja o układzie tabeli zapada z wiedzą o tym, ile rekordów naprawdę wraca z API. Nie ma przekazania między działami, na którym gubi się połowa intencji projektu.

  • Stany puste i błędy powstają razem z widokiem, nie po nim

    Każdy ekran dostaje komplet stanów - ładowanie, brak danych, brak uprawnień, zerwane połączenie, zbyt długa lista - zaprojektowanych wtedy, gdy projektowany jest scenariusz podstawowy. To one decydują o tym, jak aplikacja czuje się w codziennej pracy, a w większości wdrożeń dopisuje się je pod koniec, w pośpiechu.

  • Repozytorium jest Wasze od pierwszego commita

    Pracujemy w Waszym repozytorium, na Waszych zasadach przeglądu kodu, z konwencjami spisanymi w projekcie. Koniec współpracy nie jest wtedy przekazaniem paczki, tylko zwykłym wyjściem z projektu, który i tak przez cały czas był po Waszej stronie.

Proces

6-14 tygodni od kontraktu danych do wydania. Modułami, nie jednym skokiem

  1. Tydzień 1

    Kick-off techniczny i kontrakt danych

    Przegląd tego, co już istnieje: API, model danych, role użytkowników, ograniczenia infrastruktury. Spisujemy kontrakt między frontem a backendem - jakie pola, jakie stany, jakie kody błędów - i dzielimy zakres na moduły z kolejnością wydań.

  2. Tydzień 1–3

    Szkielet aplikacji i biblioteka widoków

    Uruchomienie projektu w Waszym repozytorium - routing, układ nawigacji, sesja, obsługa uprawnień. Do tego pierwszy zestaw komponentów, na których stanie reszta aplikacji: tabela, formularz, modal, powiadomienie, stan pusty.

  3. Tydzień 3–9

    Moduły i integracje

    Kolejne moduły wchodzą po jednym, każdy od razu podpięty do prawdziwych danych i pokazywany na środowisku testowym. Zamiast demonstracji na końcu projektu dostajecie działający fragment aplikacji co dwa tygodnie i możecie skorygować kierunek, zanim urośnie.

  4. Tydzień 8–12

    Uprawnienia, stany brzegowe, wydajność

    Przejście przez role - co widzi administrator, operator i użytkownik zewnętrzny - oraz przez sytuacje, które w makiecie nie istnieją: brak danych, zerwane połączenie, długa lista, konflikt zapisu. Testy end-to-end najważniejszych ścieżek trafiają do pipelineu.

  5. Tydzień 12–14

    Wydanie i przekazanie

    Konfiguracja środowiska produkcyjnego, monitoring błędów, wydanie. Sesja przekazania z Waszym zespołem - architektura, konwencje, gdzie dopisać nowy moduł - plus dokumentacja komponentów i trzydziestodniowe wsparcie.

Zakres

Trzy rzeczy. Działający front, spięte dane, repozytorium u Was

  • Front aplikacji w kodzie

    Ekrany aplikacji zbudowane w React i TypeScript - tabele z filtrowaniem i paginacją, formularze wielokrokowe z walidacją, widoki szczegółu, wyszukiwanie. Nie pojedyncze strony, tylko biblioteka widoków, z której składa się kolejne moduły.

  • Integracje i warstwa danych

    Podpięcie do Waszego API (REST albo GraphQL), logowanie i sesja, role oraz widoczność funkcji per uprawnienie, obsługa błędów i ponowień. Gdy API dopiero powstaje, spisujemy kontrakt i pracujemy na atrapie odpowiedzi, żeby front nie czekał na backend.

  • Repozytorium, środowiska i dokumentacja

    Kod od pierwszego dnia leży w Waszym repozytorium, nie w naszym. Do tego środowisko testowe i produkcyjne, pipeline wydania, testy end-to-end kluczowych ścieżek i dokumentacja komponentów. Trzydzieści dni wsparcia po wydaniu.

Warsztat

Co stosujemy

Stack dobieramy pod to, co już utrzymujecie, a nie pod to, co my lubimy najbardziej. Poniżej domyślny zestaw, od którego zaczynamy rozmowę.

Blat warsztatowy z góry: dwa wydruki układu interfejsu, lupa powiększająca jeden blok, stalowa linijka i wzornik szarości od bieli do czerni, jedna linia podkreślona pomarańczowym markerem
  • React i TypeScript (Next.js albo Vite)
  • REST albo GraphQL, kontrakt spisany przed kodem
  • Logowanie OAuth 2.0 i SSO, role po stronie widoku
  • WCAG 2.2 AA i pełna obsługa klawiatury
  • Testy end-to-end w Playwright, wpięte w CI
  • Docker, CI/CD, środowisko testowe i produkcyjne

Następny krok

Porozmawiajmy o Waszym projekcie

Powiedzcie, co macie do zrobienia. Wracamy z zakresem i wyceną.

Bezpłatna konsultacja Projekty

Realizacje

Realizacje z produktów, które wdrażamy

Wybór projektów z tych typów produktów, przy których najczęściej wchodzimy z wdrożeniem - aplikacji webowych, paneli operacyjnych i systemów wewnętrznych. Część wdrożeń stoi za logowaniem albo idzie pod marką zleceniodawcy, więc pokazujemy je na konsultacji.

Projekty

Efekty

Co dostajecie, w jakim terminie i po czym to sprawdzicie

  • 6–14 tygodni

    Od kontraktu danych do wydania - sześć tygodni przy jednym module na gotowym API, czternaście przy aplikacji wielorolowej z integracjami

  • Co 2 tygodnie

    Rytm, w jakim kolejny działający moduł ląduje na środowisku testowym, więc postęp ogląda się w przeglądarce, a nie w statusie zadania

  • WCAG 2.2 AA

    Publiczny standard dostępności W3C, wobec którego sprawdzamy formularze, tabele i nawigację klawiaturą przed wydaniem

  • 0 dni

    Tyle trwa u nas przekazanie kodu, bo repozytorium jest Wasze od pierwszego commita, a my pracujemy w nim jako współautorzy

Terminy i rytm wydań wynikają z harmonogramu opisanego wyżej na tej stronie, WCAG 2.2 AA to publiczny standard W3C. Nie podajemy uśrednionych wyników wdrożeń - aplikacje klientów stoją za logowaniem, więc pokazujemy je imiennie na konsultacji.

Opinie klientów

Co mówią nasi klienci

  • „Praca z zespołem Wzór była naprawdę świetnym doświadczeniem! Zawsze szybko odpowiadali na nasze pytania i elastycznie podchodzili do naszych uwag. Mają mnóstwo kreatywnych pomysłów, a jednocześnie są bardzo rzetelni i terminowi. Efekt końcowy w pełni spełnił nasze oczekiwania, zdecydowanie polecamy każdemu, kto szuka profesjonalistów z pasją.”
    Maja Wieloch-Silecka Dyrektor operacyjny, Bosfor Group
  • „Nasi Klienci oczekują od nas szybkiego, skutecznego działania w bardzo szerokim zakresie. Od stworzenia brandu, przez budowę strony internetowej wraz ze sklepem po przeprowadzenie skutecznej kampanii sprzedażowej. Temat niełatwy, ale do zrobienia jeśli ma się zgrany zespół i firmy, z którymi wyzwania bierze się z marszu. Dla nas jakość, odpowiedzialność i zaangażowanie są kluczowe, a współpraca z Agencją UX Wzór zapewnia nam to w 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Współpraca z Agencją UX Wzór rozpoczęła się od naszej strony internetowej. Bardzo spodobał się nam sposób ich pracy. Dlatego podjęliśmy decyzję o podzlecaniu projektów realizowanych dla naszych Klientów w formie White Label. Bardzo spodobał nam się ich flow pracy, przekazywanie projektów naszemu zespołowi, ich dokumentacja czy praca na design systemie. Teraz możemy podejmować większe ryzyko.”
    Mateusz Swół Chief Operating Officer, Sellace

Zespół

Kto prowadzi wdrożenie

Wdrożenie prowadzi para - projektant odpowiedzialny za widoki i stany oraz frontend developer, który implementuje je w Waszym repozytorium. Ta sama para zostaje przy projekcie do wydania i przekazania.

  • Aleksandra Bondar

    Aleksandra Bondar

    Senior UX/UI Designer

  • Patryk Korycki

    Patryk Korycki

    CEO, Analityk Biznesowy

  • Tadeusz Wadas

    Tadeusz Wadas

    Senior UX/UI Designer

Czas i zakres

Ile trwa wdrożenie i od czego zależy wycena

6–14 tygodni

Sześć tygodni to jeden moduł na istniejącym, udokumentowanym API - na przykład panel administracyjny nad gotowym backendem. Czternaście tygodni i więcej to aplikacja wielorolowa z kilkoma integracjami i migracją użytkowników ze starego systemu; wtedy dzielimy prace na wydania, żeby pierwszy działający moduł trafił do Was wcześniej.

  • Liczba modułów i unikatowych widoków w aplikacji

  • Dojrzałość API - gotowe i udokumentowane czy powstające równolegle

  • Liczba ról użytkowników i zakres uprawnień do obsłużenia

  • Integracje z systemami zewnętrznymi, płatnościami i logowaniem

  • Punkt wyjścia - gotowy projekt w Figmie albo projektowanie od zera

  • To, czy razem z wdrożeniem idzie migracja danych i użytkowników

Pytania

Pytania, które padają najczęściej

Ile kosztuje wdrożenie aplikacji webowej?

Wyceniamy indywidualnie, bo dwie aplikacje o tej samej nazwie potrafią różnić się kosztem kilkukrotnie. Na wycenę wpływa liczba modułów i unikatowych widoków, dojrzałość API (gotowe i udokumentowane czy powstające równolegle z frontem), liczba ról i zakres uprawnień, integracje z systemami zewnętrznymi oraz to, czy zaczynamy od gotowego projektu w Figmie, czy projektujemy od zera. Po krótkiej rozmowie i wglądzie w dokumentację API odsyłamy konkretną propozycję w 48 godzin.

Czym to się różni od wdrożenia no-code?

Zakresem odpowiedzialności aplikacji. Wdrożenie no-code dotyczy stron marketingowych i lead-gen - treść jest tam głównym materiałem, a redakcja edytuje ją sama w Webflow czy WordPressie. Tutaj materiałem są dane i procesy - użytkownik loguje się, ma rolę, filtruje tabelę na kilkadziesiąt tysięcy rekordów i zapisuje coś, co musi trafić do systemu po drugiej stronie. Tego nie da się złożyć na platformie bez kodu w sposób, który przetrwa rok rozwoju.

Czy piszecie też backend?

Nie w pełnym zakresie i mówimy to wprost - Wzór jest agencją UX z zapleczem developerskim, nie software house'em z własnym działem backendu. Bierzemy na siebie warstwę przeglądarkową i integracje: podpięcie do Waszego API, logowanie, sesję, uprawnienia po stronie widoku, obsługę błędów. Gdy backendu jeszcze nie ma, pomagamy zdefiniować kontrakt danych i wskazujemy partnera albo pracujemy z Waszym zespołem inżynieryjnym.

Co, jeśli API dopiero powstaje?

To najczęstszy scenariusz i nie jest przeszkodą. Zaczynamy od spisania kontraktu - jakie pola przychodzą, co może być puste, jak wygląda błąd, skąd front wie o uprawnieniach - i budujemy widoki na atrapie odpowiedzi. Front i backend idą wtedy równolegle, a spięcie jest kwestią podmiany adresu, nie przepisywania ekranów. Warunek jest jeden: kontrakt musi być ustalony razem, nie zgadywany przez nas.

W jakiej technologii wdrażacie?

Domyślnie React i TypeScript, w Next.js albo na czystym Vite, ze stylowaniem w Tailwindzie. Nie jest to jednak dogmat - jeśli utrzymujecie już aplikacje w Vue albo Angularze i macie zespół, który po nas przejmie kod, wdrażamy w Waszym stacku. Gorszym wyborem jest technologia, której nikt u Was nie umie utrzymać, niż ta, która nie jest naszą pierwszą preferencją.

Czyje jest repozytorium i kod po zakończeniu współpracy?

Wasze, i to od pierwszego commita, a nie od momentu przekazania. Pracujemy w Waszym repozytorium, na Waszych zasadach przeglądu kodu, z konwencjami spisanymi w projekcie. Dzięki temu koniec współpracy nie jest wydarzeniem - nie ma paczki do przekazania, migracji ani tygodnia na przepinanie dostępów. Zostaje udokumentowany kod, testy i konfiguracja środowisk.

Czy przejmiecie aplikację, którą pisał ktoś inny?

Tak, po przeglądzie kodu. Zaczynamy od kilku dni na ocenę stanu - architektura, zależności, testy, sposób obsługi stanu i uprawnień - i mówimy uczciwie, czy warto rozwijać to, co jest, czy taniej wyjdzie budowanie nowej warstwy obok starej. Częściej niż wymiana całości sprawdza się drugi wariant, w którym nowe moduły wchodzą pojedynczo, a stare ekrany gasną po kolei.

Pracujecie w modelu white-label dla software house'ów?

Tak, to jeden z naszych stałych modeli. Wchodzimy jako Wasz zespół frontendowy - w Waszym repozytorium, rytmie wydań i pod Waszą marką - a relacja z klientem końcowym zostaje w całości po Waszej stronie. Szczegóły: /uslugi/white-label/.

Powiązane usługi

Powiązane usługi

Umów bezpłatną konsultację z ekspertem, aby omówić Twój projekt i otrzymać odpowiedzi na nurtujące Cię pytania.

- Patryk Korycki, CEO

Zaplanuj spotkanie
Umów bezpłatną konsultację