Discovery produktu przed budową aplikacji

Discovery to faza przed budową, w której ustala się problem, użytkowników, oczekiwany efekt, granice zakresu, ryzyka i założenia techniczne. Wynikiem powinien być dokument wystarczający do porównania wariantów i przygotowania wyceny — w zakresie dopasowanym do wielkości projektu.

Discovery nie gwarantuje niższego kosztu projektu, ale zmniejsza niepewność: ujawnia sprzeczne oczekiwania, brak danych, trudną integrację albo ryzyko prawne, zanim staną się zależnością wielu gotowych funkcji.

Po co to jest, jeśli już wiem, co chcę zbudować

Bo opis pomysłu może być różnie rozumiany przez osobę zamawiającą, użytkownika i wykonawcę. Trzy rozjazdy, które warto sprawdzić przed pierwszą linią kodu:

• Rozjazd zakresu. „Panel administracyjny” znaczy trzy ekrany albo trzydzieści. Bez uzgodnienia, która wersja jest w wycenie, spór jest kwestią czasu.
• Rozjazd problemu. Klient chce aplikację do zarządzania zleceniami, a realnym problemem jest to, że zlecenia przychodzą w pięciu kanałach i nikt ich nie zbiera. Aplikacja nie rozwiąże problemu, którego nie dotyka.
• Rozjazd użytkownika. Kupujący i używający to często dwie różne osoby o różnych potrzebach. Aplikacja zaprojektowana pod kupującego bywa nieużywana przez zespół.

Co się dzieje na discovery

1. Cele biznesowe, nie lista funkcji

Pierwsze pytanie nie brzmi „co ma robić aplikacja”, a „co ma się zmienić w firmie, gdy to zadziała”. Odpowiedź daje kryterium, według którego potem odcinamy funkcje: jeśli coś nie służy tej zmianie, wypada z pierwszej wersji.

Dobre odpowiedzi są mierzalne: skrócić obsługę zlecenia, przestać przepisywać dane między systemami, dać klientowi wgląd bez telefonu do biura.

2. Użytkownicy i ich zadania

Kto będzie z tego korzystał, jak często, na czym (biurko czy telefon) i co konkretnie próbuje osiągnąć. Bez tego powstaje aplikacja logiczna dla projektanta i niewygodna dla użytkownika.

Najbardziej użyteczne pytanie w tej części: jak to jest robione dzisiaj? Nawet jeśli odpowiedzią jest arkusz i trzy maile — to jest opis procesu, który trzeba obsłużyć.

3. Proces „jak jest” i „jak ma być”

Mapa dzisiejszego przebiegu z zaznaczonymi miejscami, gdzie coś się gubi, i wersja docelowa. Kluczowe pytanie, które zadajemy przy każdym kroku: „a co robisz, gdy dane nie pasują?” Odpowiedzi na to pytanie to prawdziwy proces — i to one przesądzają o koszcie.

4. Model danych

Na discovery ustalamy główne pojęcia w dziedzinie i ich relacje. Nie projektujemy każdej tabeli „na zapas”, lecz sprawdzamy, czy zakres nie opiera się na sprzecznych definicjach. Późniejsza zmiana podstawowych relacji może wymagać migracji danych i aktualizacji wielu funkcji.

5. Ograniczenia i integracje

Systemy, z którymi trzeba się spiąć, wymogi prawne, dane osobowe, terminy zewnętrzne i budżet. Takie ograniczenie może istotnie zmienić wycenę — na przykład gdy system nie udostępnia potrzebnego interfejsu albo umowa zabrania określonego sposobu przetwarzania danych.

6. Zakres pierwszej wersji

Rozdzielenie „musi być, żeby to w ogóle działało” od „byłoby dobrze”, z uzasadnieniem każdej pozycji. Dla produktu z jedną kluczową ścieżką punktem odniesienia może być zakres usługi MVP w 4–6 tygodni.

7. Ryzyka nazwane wprost

Lista rzeczy, które mogą pójść nie tak, z oceną skutku. Projekt bez wypisanych ryzyk nie jest bezpieczniejszy — po prostu odkryjesz je później i drożej.

Co powinno z tego wyjść

Konkretny dokument, nie notatki z rozmowy. U nas to:

• opis problemu i celów mierzalnych,
• użytkownicy i ich zadania,
• proces docelowy,
• model danych i architektura rozwiązania,
• zakres pierwszej wersji plus lista rzeczy świadomie odłożonych,
• harmonogram etapami i wycena,
• ryzyka z planem reakcji.

Ten dokument jest Twój i możesz go zrealizować u nas albo gdziekolwiek indziej. Jeśli budowę zamawiasz u nas, kwotę discovery odliczamy od wyceny projektu. Co dzieje się na kolejnych etapach, opisujemy w jak zbudować aplikację od zera.

Ile to kosztuje i trwa

Nasze widełki na sierpień 2026 r.: warsztat discovery z dokumentem kierunkowym 3 000–8 000 zł netto, pełny projekt i planowanie rozwiązania z architekturą, roadmapą i estymatami 8 000–25 000 zł netto. Czas zależy od liczby interesariuszy, integracji i dostępności materiałów; zwykle mieści się od jednego warsztatu do około dwóch tygodni.

Wycena projektu opisanego jednym akapitem zawiera więcej założeń i ryzyka po obu stronach. Rozpisany zakres pozwala wskazać, co jest w cenie, jakie dane musi dostarczyć klient i co uruchamia ponowną wycenę. Discovery może obniżyć bufor niepewności, ale może też ujawnić wymaganie, które podniesie uczciwą cenę.

Kiedy discovery nie jest potrzebne

Uczciwie, bo nie chcemy sprzedawać etapu bez potrzeby:

• Gdy zakres jest naprawdę mały i jednoznaczny. Jedna integracja, jeden ekran, jeden przepływ — wtedy discovery to nadmiarowa ceremonia.
• Gdy masz gotową, dobrą specyfikację. Zdarza się, zwłaszcza gdy po Twojej stronie jest ktoś techniczny. Wtedy wystarczy przegląd.
• Gdy problemem jest walidacja pomysłu, a nie jego zakres. Wtedy najpierw sprawdź, czy ktokolwiek tego chce — choćby ręcznie, bez aplikacji. Discovery ma sens, gdy wiadomo, że problem jest realny.

Jak przygotować się po swojej stronie

Cztery rzeczy, które przyspieszają warsztat i obniżają koszt:

1. Zbierz realne przykłady — konkretne zlecenia, dokumenty, maile, arkusze, których faktycznie używacie.
2. Zaproś osobę, która wykonuje pracę, nie tylko tę, która ją zamawia.
3. Wypisz, czego dzisiaj nie da się zrobić, choć powinno.
4. Ustal, kto podejmuje decyzje o zakresie. Brak dostępnej osoby decyzyjnej jest częstym źródłem przestojów i sprzecznych ustaleń.

Najczęstsze pytania

Czy discovery można zrobić zdalnie?

Tak i tak zwykle je robimy. Warsztat online 2–3 godziny plus praca po naszej stronie, potem runda pytań uzupełniających.

Czy musimy zamówić u was budowę po discovery?

Nie. Dokument jest Twój i do niczego nie zobowiązuje. Jeśli idziemy dalej, kwotę odliczamy od projektu zgodnie z warunkami oferty.

Czym to się różni od audytu AI?

Audyt AI odpowiada na pytanie „gdzie w naszej firmie AI się opłaci”. Discovery odpowiada na „co dokładnie zbudować i jak”. Bywa, że audyt jest krokiem przed discovery.

---

Prowadzimy własne projekty potokiem discovery → brief → plan → wdrożenie i tym samym potokiem prowadziliśmy przebudowę tej witryny — więc możemy pokazać, jak wygląda nasz brief, a nie tylko o nim opowiedzieć. Zobacz projektowanie i planowanie albo opisz pomysł.