Aplikacje webowe w Next.js
SaaS, dashboardy, narzędzia wewnętrzne. Budujemy aplikacje szybkie dziś i utrzymywalne za trzy lata. Edge computing standardowo, bez beta.
- Stack
Next.js + TypeScript
App Router, React Server Components, strict mode, zero any. Stack dla aplikacji, która ma żyć latami — każda decyzja architektoniczna udokumentowana w repo.
- Mobile
Mobile first
Responsive od pierwszej decyzji projektowej. Nie „dorabiamy mobile na końcu” — każdy commit testowany na iPhone i Pixel zanim trafi na produkcję.
- Edge
Edge computing
Vercel, Cloudflare Workers, globalna latencja poniżej 100 ms. Aplikacja działa tak samo szybko z Warszawy jak z San Francisco.
- CMS
Headless CMS
Sanity, Payload — content jako dane, nie HTML. Twój zespół aktualizuje treść bez angażowania dewelopera. API-first.
Aplikacje, których chcielibyśmy używać. Architektura skalowalna — bo kod, który piszemy dziś, ktoś (często my) utrzymuje za trzy lata.
Jak to wygląda
- Zakres
Ekrany, role i to, co odpada
Rozmawiasz z osobą, która potem pisze ten kod. Rozpisujemy ekrany, role użytkowników i to, co aplikacja ma robić w pierwszej wersji. Najwięcej czasu zajmuje lista funkcji odłożonych na później — to ona pilnuje terminu. Wychodzisz z zakresem na piśmie, nie z prezentacją.
- Prototyp
Najtrudniejszy widok na początku
Logowanie, uprawnienia i najtrudniejszy widok powstają jako pierwsze — to one potrafią wywrócić termin, więc sprawdzamy je, póki jest czas. Wersja testowa rośnie na osobnym środowisku, otwierasz ją na telefonie i pokazujesz zespołowi. Uwagi zbieramy na konkretnym ekranie, nie w mailu z listą punktów.
- Produkcja
Wydania etapami, potem opieka
Wypuszczamy etapami — najpierw to, co ma działać od pierwszego dnia, reszta wchodzi kolejnymi wydaniami. Do tego krótka instrukcja, co gdzie leży i jak uruchomić projekt lokalnie. Kolejna wersja jest planowana, nie doklejana: mówimy, co dokładamy, w jakiej kolejności i co to zmienia w tym, co już działa.
Decyzje z wdrożonych stron
Znicz zapala się bez konta
Na pamietajmnie.pl profil pamięci otwiera się z kodu QR na nagrobku. Pod nagłówkiem stoi rząd akcji z licznikami — zapal znicz, dodaj wspomnienie — i żadna nie prowadzi do logowania; w belce profilu nie ma przycisku „Zaloguj się”. Konto przed pierwszym kliknięciem zamknęłoby jedyny kanał, którym ten produkt się rozchodzi.
Przycisk „Zarezerwuj” bez modułu rezerwacji
Na porzadnie24.pl przyciski mówią „Zarezerwuj sprzątanie”, ale rezerwacja idzie paskiem przyklejonym do dołu ekranu telefonu: WhatsApp i Zadzwoń. Formularz jest jeden, z dwoma wymaganymi polami. Kalendarza online nie ma, bo wolny slot to obietnica terminu — jedna osoba w trasie nie potwierdzi go na czas, a system pokazywałby godziny, których nikt nie pilnuje.
Pasujemy, gdy
- Budujesz SaaS lub produkt webowy
- Performance jest realnym KPI
- Aplikacja ma żyć 3+ lata
Prawdopodobnie nie my, gdy
- Potrzebujesz wtyczki do WordPressa
- Chcesz „dorobić” feature w dwa dni
- Nie ma po stronie product ownera
Częste pytania
- Czym różni się aplikacja webowa od strony internetowej?
- Strona odpowiada na pytania i kończy się kontaktem. Aplikacja pamięta stan — konta, uprawnienia, dane, które ktoś wprowadza i do których wraca. Prosty test: jeśli użytkownik się loguje i zostawia u ciebie coś, czego nie chce stracić, to aplikacja. Wtedy najważniejszą decyzją nie jest wygląd, tylko to, co dzieje się z danymi rok później.
- Czy zintegrujecie aplikację z systemem, którego już używamy?
- To zależy od jednej rzeczy: czy ten system ma API i dokumentację. Jeśli ma — wpinamy się na żywo i dane lecą w obie strony. Jeśli wypuszcza je tylko eksportem, robimy import plików, zamiast obiecywać synchronizację, której nikt nie utrzyma. Jeśli nie ma ani jednego, mówimy to przed startem, nie w połowie wdrożenia.
- Czy potrzebuję aplikacji ze sklepu, żeby działała na telefonie?
- W większości przypadków nie. Aplikacja webowa otwiera się w przeglądarce, działa na telefonie i można ją przypiąć do ekranu głównego — bez sklepu, bez recenzji, bez czekania na akceptację przy każdej poprawce. Wersja natywna ma sens, gdy potrzebujesz powiadomień push, pracy offline albo sprzętu telefonu. Wtedy mówimy to wprost: to drugi projekt, nie dodatek.
- Aplikację zaczął inny wykonawca — przejmiecie projekt?
- Najpierw czytamy kod, potem odpowiadamy. Jeśli to Next.js albo React z historią w gicie i buildem, który przechodzi — przejmujemy i mówimy, co poprawiamy w pierwszej kolejności. Jeśli repozytorium nie istnieje, a pliki wgrywano FTP-em, powiemy wprost: łatanie zajmie więcej czasu niż napisanie tego od nowa. Ocenę pokazujemy na konkretnych plikach.