Vibe coding: co to jest i co zrobić, gdy aplikacja już działa, ale wymaga dopracowania?

Vibe coding radykalnie skraca drogę od pomysłu do działającej aplikacji. Gdy prototyp zaczyna jednak obsługiwać realnych użytkowników, zdobywać klientów i stawać się częścią biznesu, pojawia się nowy zestaw pytań: o UX, spójność UI, mobile, architekturę, bezpieczeństwo i możliwość dalszego rozwoju. Ten artykuł pokazuje, jak świadomie przejść z etapu „działa” do etapu „to jest dobry produkt”.

W skrócie: czym jest vibe coding i co dalej?

Vibe coding pozwala budować oprogramowanie z bardzo dużym udziałem AI, często poprzez opisywanie oczekiwanego rezultatu w języku naturalnym.

• Vibe coding pozwala budować oprogramowanie z bardzo dużym udziałem AI, często poprzez opisywanie oczekiwanego rezultatu w języku naturalnym.
• Jest świetnym narzędziem do prototypowania, testowania pomysłów, internal tools i szybkiego dochodzenia do pierwszej działającej wersji.
• Moment problematyczny nie zaczyna się dlatego, że produkt „powstał z AI”, tylko wtedy, gdy rosną wobec niego wymagania: pojawiają się użytkownicy, płatności, dane, integracje, skala i oczekiwanie dalszego rozwoju.
• Nie każdą aplikację trzeba przepisywać od nowa. Najpierw warto przeprowadzić audyt i zdecydować, czy potrzebne są poprawki UX/UI, refactoring wybranych elementów, czy rzeczywiście rebuild.
• Profesjonalny development nie oznacza rezygnacji z AI. Oznacza dołożenie do szybkości także odpowiedzialności za architekturę, testy, bezpieczeństwo, doświadczenie użytkownika i utrzymanie produktu.

Spis treści

• 1. Co to jest vibe coding?
• 2. Dlaczego vibe coding jest tak atrakcyjny?
• 3. Kiedy zmienia się etap produktu?
• 4. Najczęstsze problemy: od hierarchii informacji po mobile
• 4. UX to tylko jedna warstwa: co z technologią?
• 5. Czy aplikację stworzoną przez vibe coding trzeba przepisać od początku?
• 6. Poprawa, refactoring czy rebuild?
• 7. Jak wygląda audyt aplikacji po vibe codingu?
• 8. Co powinien otrzymać właściciel produktu po audycie?
• 9. Checklista: czy to już moment na kolejny krok?
• 10. Vibe coding a profesjonalny development z AI
• 11. Vibe coding może być początkiem bardzo dobrego produktu

• 12. FAQ: vibe coding i rozwój aplikacji

Co to jest vibe coding?

Vibe coding to sposób tworzenia oprogramowania, w którym znaczną część pracy nad kodem przejmuje generatywna sztuczna inteligencja, a człowiek opisuje przede wszystkim oczekiwany efekt. W najbardziej charakterystycznej wersji użytkownik nie koncentruje się na ręcznym pisaniu i analizowaniu każdej linii kodu. Promptuje, uruchamia rezultat, sprawdza, czy działa, i kolejnymi poleceniami prowadzi produkt w oczekiwanym kierunku.

Określenie spopularyzował Andrej Karpathy 6 lutego 2025 roku. W swoim pierwotnym opisie mówił wręcz o „zapomnieniu, że kod istnieje”: akceptowaniu zmian generowanych przez model i skupieniu się na tym, czy aplikacja robi to, czego od niej oczekujemy.

To rozróżnienie jest ważne, ponieważ vibe coding nie jest synonimem całego programowania z pomocą AI. Simon Willison zwraca uwagę, że jeśli developer czyta wygenerowany kod, testuje go, rozumie i bierze za niego odpowiedzialność, mówimy po prostu o profesjonalnym developmentcie wspieranym przez AI. To podejście dobrze porządkuje dyskusję i pozwala uniknąć dwóch równie nietrafionych skrajności: przekonania, że AI samodzielnie rozwiązuje każdy problem produktowy, oraz tezy, że kod wygenerowany przez AI z definicji nie nadaje się do dalszego wykorzystania.

W praktyce rynkowej termin stał się oczywiście szerszy. Używa się go również wobec aplikacji budowanych w narzędziach takich jak Lovable czy Bolt, a także wobec pracy z agentami codingowymi w środowiskach takich jak Cursor. W tym artykule interesuje nas przede wszystkim wspólny mianownik: możliwość niezwykle szybkiego stworzenia działającej aplikacji bez przechodzenia od początku przez klasyczny proces product designu i developmentu.

Dlaczego vibe coding jest tak atrakcyjny?

Największą zmianą nie jest samo generowanie kodu. Jest nią skrócenie dystansu pomiędzy pomysłem a czymś, co można zobaczyć, kliknąć i pokazać drugiej osobie. Founder nie musi zaczynać od wielotygodniowego projektu. Marketer może przygotować proste narzędzie wewnętrzne. Product manager może w krótkim czasie przetestować hipotezę, która wcześniej musiałaby czekać na miejsce w backlogu zespołu developerskiego.

To szczególnie wartościowe we wczesnym etapie produktu, kiedy nie wiemy jeszcze, czy rozwiązujemy właściwy problem. Szybki prototyp pozwala zweryfikować założenia, przeprowadzić pierwsze rozmowy z użytkownikami, zebrać feedback, pokazać ideę inwestorowi albo przekonać się, że koncepcję trzeba zmienić, zanim poniesiemy większe koszty.

Warto też zauważyć, że współczesne narzędzia coraz mniej przypominają zamknięte generatory jednorazowych prototypów. Lovable umożliwia synchronizację projektu z GitHubem, dzięki czemu kod może być dalej rozwijany w zwykłym repozytorium i przejęty przez developerów. Cursor Agent potrafi analizować istniejący codebase, modyfikować wiele plików, uruchamiać komendy, refaktorować kod, naprawiać błędy i tworzyć testy. Sam ekosystem zmierza więc w stronę płynniejszego przejścia pomiędzy szybkim budowaniem a profesjonalnym engineeringiem.

Źródła funkcjonalności narzędzi: Lovable — GitHub integration oraz Cursor — Agent mode.

Vibe coding nie jest problemem, który trzeba „odkręcić”, tylko sposobem szybkiego dotarcia do punktu, w którym trzeba zmienić kryteria oceny produktu.

Kiedy zmienia się etap produktu?

Na początku najważniejsze pytanie brzmi zwykle: „czy jestem w stanie to zbudować?”. Po kilku dniach lub tygodniach może się okazać, że odpowiedź brzmi: tak. Mamy logowanie, dashboard, formularze, integrację z API, bazę danych i kilka najważniejszych funkcji. Produkt działa.

To właśnie wtedy bardzo łatwo wpaść w pułapkę dalszego rozwijania go wyłącznie poprzez dokładanie kolejnych funkcji. Tymczasem wymagania wobec aplikacji zaczynają się zmieniać. Korzystają z niej osoby, które nie znają założeń autora. Pojawiają się płatności. Produkt zaczyna przechowywać istotne dane. Trzeba obsłużyć sytuacje, których nikt nie uwzględnił w pierwszych promptach. Kolejna funkcja wpływa na trzy wcześniejsze, a drobna poprawka powoduje regresję w innym miejscu.

Nie oznacza to, że wcześniejszy sposób pracy był błędny. Oznacza jedynie, że prototyp zaczyna pełnić inną rolę. W pierwszym etapie optymalizowaliśmy proces pod szybkość poznania odpowiedzi. W kolejnym musimy również zadbać o użyteczność, spójność, bezpieczeństwo, przewidywalność i możliwość dalszego utrzymania.

Między „działa” a „to jest dobry produkt” istnieje realna luka

Można mieć poprawnie działający formularz rejestracji i jednocześnie słaby onboarding. Można posiadać wszystkie potrzebne funkcje, ale nie zbudować czytelnej architektury informacji. Można wygenerować atrakcyjne ekrany, które osobno wyglądają dobrze, ale razem nie tworzą konsekwentnego systemu. Można też mieć kod, który obsługuje pierwszych użytkowników, ale każda następna zmiana staje się coraz bardziej ryzykowna.

To nie jest wyjątkowa cecha aplikacji tworzonych z AI. Podobne problemy występowały od zawsze w produktach budowanych szybko, bez wystarczającego czasu na analizę i porządkowanie całości. Vibe coding po prostu zwiększył skalę zjawiska, ponieważ znacznie więcej osób może dziś bardzo szybko dojść do pierwszej działającej wersji produktu.

Dlatego kolejnym krokiem nie powinno być automatycznie „przepisać wszystko” ani „dodawać funkcje dalej”. Najpierw trzeba zobaczyć produkt jako całość i ustalić, gdzie rzeczywiście znajduje się ograniczenie.

Najczęstsze problemy: od hierarchii informacji po mobile

W pracy nad takimi produktami kilka kategorii problemów powtarza się wyjątkowo często. Nie są to wyłącznie błędy techniczne. W wielu przypadkach aplikacja wykonuje dokładnie to, co miała wykonywać, ale nie została jeszcze „wyreżyserowana” jako kompletne doświadczenie użytkownika.

1. Wszystko jest ważne, więc nic nie jest najważniejsze

Kolejne elementy pojawiają się dlatego, że były potrzebne: filtr, dodatkowy przycisk, wykres, status, ustawienie, nowa sekcja menu. Każdy z nich ma uzasadnienie. Problem polega na tym, że po kilku iteracjach użytkownik otrzymuje ekran, na którym wiele elementów walczy o jego uwagę z podobną intensywnością.

Dobry interfejs nie jest katalogiem wszystkich możliwości systemu. Powinien pomagać podejmować decyzje. Użytkownik w większości miejsc powinien rozumieć, gdzie się znajduje, jakie ma możliwości oraz która akcja jest najbardziej naturalnym kolejnym krokiem. Uporządkowanie hierarchii informacji często daje większy efekt niż dodanie kolejnej funkcji.

2. Jest główna funkcja, ale nie ma pełnej ścieżki użytkownika

Promptowanie sprzyja myśleniu funkcjami: dodaj rejestrację, zbuduj wyszukiwarkę, daj możliwość eksportu, dodaj płatność. Użytkownik nie doświadcza jednak produktu jako listy funkcji. Przechodzi przez sekwencję decyzji, ekranów, komunikatów i momentów niepewności.

Dlatego warto sprawdzić nie tylko, czy określona akcja jest możliwa, ale co dzieje się przed nią i po niej. Czy użytkownik wie, dlaczego powinien ją wykonać? Czy rozumie rezultat? Co może zrobić, jeśli nie jest jeszcze gotowy na główną akcję? Czy istnieje sensowna ścieżka poboczna, czy trafia w ślepy zaułek?

3. Happy path działa. A co z całą resztą?

Pierwsza wersja produktu naturalnie koncentruje się na scenariuszu sukcesu: użytkownik wpisuje poprawne dane, API odpowiada, płatność przechodzi, lista zawiera rekordy, połączenie jest stabilne. Tymczasem produkt produkcyjny musi poradzić sobie również wtedy, kiedy świat nie współpracuje.

Empty states, loading states, komunikaty błędów, ostrzeżenia, potwierdzenia, możliwość cofnięcia operacji czy wznowienia przerwanego procesu nie są dodatkami kosmetycznymi. Są częścią doświadczenia. Pusta tabela bez wskazówki „co zrobić, aby pojawiły się tu dane” może być równie dużym problemem jak źle działający przycisk. Techniczny komunikat błędu może natomiast odebrać użytkownikowi pewność, czy jego dane i wykonana operacja są bezpieczne.

4. Ekrany są poprawne osobno, ale produkt nie składa się w system

Generatywne narzędzia potrafią szybko tworzyć estetyczne komponenty. Z czasem te same problemy bywają jednak rozwiązywane na kilka sposobów. Podobne przyciski mają inne znaczenie, modal zachowuje się inaczej niż poprzedni, te same statusy otrzymują różne kolory, a kolejne formularze zaczynają mieć odmienną logikę walidacji.

Użytkownik prawdopodobnie nie nazwie tego „brakiem design systemu”. Po prostu będzie musiał za każdym razem na nowo odczytywać zasady interfejsu. Dla zespołu developerskiego oznacza to z kolei coraz więcej wariantów podobnych komponentów i wyższy koszt dalszych zmian.

Dojrzewanie produktu nie zawsze wymaga pełnego redesignu. Często lepszym ruchem jest inwentaryzacja istniejących komponentów, ustalenie wspólnych wzorców i konsekwentne uporządkowanie najważniejszych ekranów.

5. Mobile jest responsywny technicznie, ale nie produktowo

Aplikacja może poprawnie zmniejszać szerokość kolumn i nadal być bardzo trudna w obsłudze na telefonie. Rozbudowana tabela, pięć równorzędnych działań, wielopoziomowe menu czy ekran zaprojektowany pod pracę na dużym monitorze nie stają się automatycznie dobrym mobile UX tylko dlatego, że mieszczą się w viewportcie.

Na mniejszym ekranie często trzeba zmienić priorytety, kolejność informacji, sposób nawigacji i sam model wykonania operacji. Dlatego wersję mobilną warto przechodzić jako osobny scenariusz użytkowy, a nie wyłącznie jako test responsive designu.

6. Produkt rośnie szybciej niż jego fundament

Najbardziej kosztowne problemy często nie są jeszcze widoczne na interfejsie. Kolejne funkcje można dodawać, ale każda zmiana wymaga coraz większej ostrożności. Fragmenty logiki się powielają, zależności stają się trudne do przewidzenia, brakuje testów, a naprawa jednego problemu ujawnia następny.

To moment, w którym warto sprawdzić nie tylko UX, ale również sposób zbudowania aplikacji. Nie dlatego, że kod napisała sztuczna inteligencja. Dlatego, że produkt zaczyna być na tyle istotny, aby koszt jego utrzymania, bezpieczeństwo i możliwość rozwoju stały się częścią decyzji biznesowej.

UX to tylko jedna warstwa: co z technologią?

Jeżeli aplikacja ma zdobywać kolejnych użytkowników, obsługiwać płatności, przetwarzać ważne dane, integrować się z systemami klientów albo stać się kluczowym elementem biznesu, sama analiza interfejsu nie wystarczy. Trzeba również zajrzeć pod powierzchnię.

Zakres analizy zależy od produktu, ale zwykle warto odpowiedzieć na kilka pytań. Czy struktura projektu pozwala bezpiecznie rozwijać kolejne funkcje? Czy podobne rozwiązania nie zostały wielokrotnie zaimplementowane niezależnie? Jak wygląda autoryzacja i zarządzanie dostępem? Czy kluczowe procesy są objęte testami? Jak aplikacja obsługuje błędy oraz awarie integracji? Czy konfiguracja środowisk, logowanie zdarzeń i monitoring pozwalają później zdiagnozować problem? Czy developer przejmujący projekt będzie potrafił stosunkowo szybko zrozumieć jego logikę?

Nie chodzi o znalezienie jak największej liczby „przewinień”. Chodzi o ocenę ryzyka względem kolejnego etapu. Prototyp prezentowany pięciu osobom ma inne wymagania niż system, na którym ma opierać się proces sprzedażowy lub obsługa setek klientów. Ta sama implementacja może być zupełnie wystarczająca w jednym kontekście i niewystarczająca w drugim.

Czy aplikację stworzoną przez vibe coding trzeba przepisać od początku?

Nie. Sam fakt, że produkt został stworzony w Lovable, Bolcie, Cursorze albo z bardzo dużym udziałem generatywnego AI, nie jest jeszcze argumentem za rebuildem. Najpierw trzeba sprawdzić, co faktycznie jest ograniczeniem.

Część problemów może być rozwiązana poprzez uporządkowanie informacji i ścieżek użytkownika. Inne wymagają przebudowania komponentów UI albo konkretnych fragmentów logiki. W jeszcze innych przypadkach sensownym krokiem będzie refactoring techniczny. Dopiero jeśli obecny fundament realnie uniemożliwia osiągnięcie celów biznesowych albo koszt jego utrzymywania jest większy niż świadoma przebudowa, pojawia się uzasadnienie dla rebuild.

Poprawa, refactoring czy rebuild?

Te pojęcia często wrzuca się do jednego worka, chociaż oznaczają zupełnie inny poziom ingerencji w produkt. Dobra diagnoza pozwala dobrać najmniejszą zmianę, która rzeczywiście rozwiązuje problem.

W praktyce najlepsza decyzja często jest hybrydowa. Możemy zachować sporą część istniejącego produktu, przeprojektować dwa kluczowe procesy, uporządkować design system i jednocześnie zrefaktorować obszar kodu, który generuje najwięcej problemów. Właśnie dlatego audyt powinien poprzedzać decyzję o pełnej przebudowie, a nie służyć jedynie do jej uzasadnienia.

Jak wygląda audyt aplikacji po vibe codingu?

W Wise People patrzymy na taki produkt z kilku perspektyw jednocześnie, bo zgłoszenie „aplikacja działa, ale coś jest nie tak” rzadko daje się sprowadzić do jednego problemu. Najpierw trzeba zrozumieć, czym produkt ma być w kolejnym etapie, a dopiero potem ocenić, co mu w tym przeszkadza.

1. Kontekst biznesowy i rola produktu

Zaczynamy od celu. Czy produkt ma dopiero walidować model biznesowy? Czy zdobywa pierwszych klientów? Czy ma wejść do sprzedaży B2B? Czy będzie narzędziem wewnętrznym? Czy planowana jest integracja z infrastrukturą dużej organizacji? Ten kontekst decyduje o tym, jak rygorystycznie należy oceniać poszczególne ryzyka.

2. Główne i poboczne ścieżki użytkownika

Przechodzimy produkt tak, jak robi to użytkownik: od pierwszego kontaktu i onboardingu przez najważniejsze zadania po sytuacje wyjątkowe. Nie analizujemy wyłącznie poszczególnych ekranów. Sprawdzamy, czy cała sekwencja prowadzi użytkownika do celu, czy kolejne decyzje są czytelne i czy produkt daje sensowne wyjście wtedy, gdy użytkownik nie zachowuje się zgodnie z idealnym scenariuszem.

3. UX i architektura informacji

Oceniamy hierarchię treści, nawigację, formularze, komunikaty, etykiety, onboarding i sposób prezentowania dostępnych akcji. Szukamy miejsc wymagających niepotrzebnego wysiłku poznawczego, powodujących zawahanie albo zmuszających użytkownika do zgadywania, co wydarzy się po wykonaniu operacji.

4. Spójność UI i możliwość dalszego rozwoju designu

Inwentaryzujemy najważniejsze wzorce i komponenty. Sprawdzamy, czy podobne elementy zachowują się podobnie, czy hierarchia wizualna jest konsekwentna oraz czy produkt posiada bazę, którą da się rozwijać bez powstawania kolejnych wyjątków. W zależności od sytuacji efektem może być lista poprawek albo zalecenie uporządkowania / stworzenia design systemu.

5. Mobile, dostępność i stany systemu

Kluczowe procesy przechodzimy również na urządzeniach mobilnych. Sprawdzamy empty states, loading states, błędy, potwierdzenia, działania destrukcyjne, przerwane procesy oraz podstawowe kwestie dostępności. To właśnie te obszary często odróżniają demo, które dobrze wygląda na prezentacji, od produktu dającego użytkownikowi poczucie kontroli.

6. Analiza technologiczna

Jeśli aplikacja ma być dalej rozwijana, do audytu może zostać dołączona analiza developerska: struktura projektu, jakość kluczowych fragmentów kodu, architektura, integracje, bezpieczeństwo, testy, wydajność oraz miejsca mogące utrudnić skalowanie lub utrzymanie. Zakres dobieramy do realnego ryzyka i planów, a nie do potrzeby stworzenia jak najdłuższego raportu.

Co powinien otrzymać właściciel produktu po audycie?

Najmniej użytecznym rezultatem byłby dokument z setką obserwacji, w którym każda uwaga wygląda równie ważnie. Audyt ma przede wszystkim ułatwić decyzję i dalsze działanie.

Dlatego rekomendacje warto uporządkować według wpływu na użytkownika, biznes oraz ryzyka technologicznego. Powinno być jasne, które problemy blokują podstawowy proces, które obniżają konwersję lub zrozumienie produktu, które zwiększają koszt kolejnych zmian, a które są kosmetyczne i mogą spokojnie poczekać.

Praktyczny rezultat powinien zawierać:

• listę zidentyfikowanych problemów wraz z kontekstem, a nie wyłącznie screenshotem i komentarzem;
• priorytet oraz uzasadnienie, dlaczego dany problem jest istotny;
• rekomendowany sposób rozwiązania z opisem przewidywanych pozytywnych efektów;
• rozdzielenie tematów UX/UI od problemów wymagających ingerencji developerskiej;
• wskazanie elementów, które można bezpiecznie zostawić bez zmian;
• decyzję, gdzie wystarczy poprawa, gdzie potrzebny jest refactoring, a gdzie warto rozważyć większą przebudowę;
• roadmapę pozwalającą realizować poprawki etapami — przez zespół klienta albo wspólnie z Wise People.

To ważne również biznesowo. Celem nie powinno być maksymalizowanie zakresu prac, ale znalezienie takiej kombinacji zmian, która pozwala produktowi wejść na kolejny poziom bez wyrzucania wartości już wytworzonej w pierwszym etapie.

Checklista: czy to już moment na kolejny krok?

Nie istnieje jedna liczba użytkowników albo ekranów, po której aplikacja przestaje być prototypem. Można natomiast rozpoznać zmianę etapu po objawach. Jeśli na kilka poniższych pytań odpowiadasz „tak”, warto zatrzymać dalsze dokładanie funkcji i spojrzeć na produkt całościowo.

☐  Czy z aplikacji regularnie korzystają już osoby, które nie uczestniczyły w jej tworzeniu?
☐  Czy użytkownicy pytają, gdzie znaleźć funkcje, które z Twojej perspektywy są „oczywiste”?
☐  Czy pojawiły się płatności, ważne dane klientów albo procesy biznesowe zależne od działania aplikacji?
☐  Czy kolejne ekrany i funkcje zaczynają wyglądać lub zachowywać się inaczej niż wcześniejsze?
☐  Czy wersja mobilna „działa”, ale w praktyce korzystanie z niej jest wyraźnie mniej wygodne?
☐  Czy poprawka w jednym miejscu coraz częściej powoduje problem w innym?
☐  Czy planujesz zwiększyć skalę, dodać integracje albo wejść z produktem do klientów B2B?
☐  Czy trudno Ci ocenić, które problemy naprawdę wymagają przebudowy, a które można rozwiązać niewielkim kosztem?
☐  Czy produkt ma już wartość, której nie chcesz stracić, ale jednocześnie czujesz, że dalsze „promptowanie do przodu” nie jest wystarczającą strategią?

Moment przejścia z prototypu do produktu nie oznacza końca szybkiego budowania. Oznacza, że do szybkości trzeba dołożyć priorytety, standardy i odpowiedzialność za całość doświadczenia.

Vibe coding a profesjonalny development z AI

Zaangażowanie designerów i developerów nie oznacza powrotu do świata, w którym każdą linijkę kodu trzeba pisać ręcznie. Profesjonalne zespoły również intensywnie korzystają z AI — do analizy codebase, prototypowania, refaktoryzacji, tworzenia testów, dokumentacji, code review czy szukania przyczyn błędów.

Różnica leży w procesie. Kod wygenerowany przez model staje się elementem określonej architektury, jest przeglądany, testowany i utrzymywany. Zespół wie, dlaczego wybrano dane rozwiązanie, jakie są jego ograniczenia i co wydarzy się, kiedy produkt zacznie się zmieniać. W przypadku UX podobną rolę pełni product designer: nie chodzi o ręczne rysowanie każdego ekranu zamiast AI, ale o świadome projektowanie hierarchii, scenariuszy, zasad i całego doświadczenia.

Właśnie dlatego najbardziej dojrzały model nie polega na wyborze „AI albo eksperci”. Polega na wykorzystaniu AI tam, gdzie daje największą przewagę szybkości, oraz ludzkiej odpowiedzialności tam, gdzie potrzebny jest kontekst, ocena ryzyka, projektowanie systemowe i decyzje wpływające na wiele kolejnych etapów produktu.

Vibe coding może być początkiem bardzo dobrego produktu

Największa wartość nowych narzędzi polega na tym, że więcej pomysłów może zostać sprawdzonych szybciej i mniejszym kosztem. Founder może zbudować pierwszą wersję bez kompletowania pełnego zespołu. Firma może uruchomić internal tool, który wcześniej nigdy nie dostałby budżetu. Product manager może zweryfikować hipotezę w działającym interfejsie zamiast w prezentacji.

Nie ma więc powodu, aby traktować szybko stworzoną aplikację jak błąd, który później trzeba „naprawić”. Trzeba jedynie rozpoznać moment, w którym zmieniła się jej rola. Jeśli produkt ma zdobywać klientów, wspierać pracowników, przechowywać ważne dane i być rozwijany przez kolejne lata, musi spełnić więcej wymagań niż pierwszego dnia.

W takim momencie warto przejść główne i poboczne ścieżki użytkownika, sprawdzić UX, uporządkować UI, przyjrzeć się mobile, dostępności i technologii, a następnie zdecydować, co można pozostawić, co poprawić, co zrefaktorować i czy cokolwiek rzeczywiście wymaga przebudowy od podstaw.