uncrn: szybka ścieżka MVP, czyli kiedy pomysł nie potrzebuje projektu za 5 milionów

MVP, uncrn, discovery, software house, wytwarzanie oprogramowania • 17.07.2026 • 7 minut

Nie każdy pomysł zasługuje na projekt za 5 milionów


W aveneo budujemy oprogramowanie od 2008 roku i przez ten czas nauczyliśmy się jednego, co brzmi trochę wbrew interesowi software house'u: nie każdy pomysł zasługuje na wielki projekt. Część rzeczy, które trafiają do nas jako „duży system", to tak naprawdę hipoteza, której nikt jeszcze nie sprawdził na żywym użytkowniku. A hipotezę można zweryfikować taniej i szybciej, niż się wydaje.

Zdarza się rozmowa, która wygląda mniej więcej tak. Ktoś przychodzi z pomysłem, który nosi w głowie od miesięcy, i pyta o wycenę porządnego systemu. My robimy analizę, przygotowujemy zakres, podajemy budżet, a po drugiej stronie zapada cisza. Nie dlatego, że pomysł jest zły. Dlatego, że człowiek chciał najpierw zobaczyć, czy to w ogóle działa, a dostał kwartał planowania i fakturę, która wymaga decyzji na poziomie zarządu.

To nie jest krytyka pełnego procesu. Dla wielu projektów pełne discovery i solidna wycena to jedyna słuszna droga i za chwilę o tym napiszę. Chodzi o coś innego. Chodzi o to, że mamy w aveneo dwie różne odpowiedzi na dwa różne pytania, a przez lata udawaliśmy, że mamy tylko jedną. Ten tekst jest o tej drugiej, którą nazwaliśmy uncrn.

Dwie drogi: głębokie discovery kontra szybkie MVP


Pierwsza droga to klasyka, którą robimy od kilkuset wdrożeń w fintechu, healthtechu, B2B i enterprise. Zaczynamy od discovery: warsztaty, mapowanie procesów, analiza integracji, wymagania niefunkcjonalne, ryzyka, potem specyfikacja i wycena projektu. To podejście ma sens, gdy z góry wiadomo, co ma powstać, gdy stawka jest wysoka, a błąd architektoniczny na starcie kosztuje później krocie. Płacisz za pewność. I dobrze, bo są sytuacje, w których pewność jest warta każdych pieniędzy.

Druga droga zakłada, że na początku nie wiesz jeszcze wszystkiego, i to jest w porządku. Zamiast miesiącami opisywać system, który dopiero powstaje w głowie, budujesz jego najmniejszą działającą wersję i uczysz się na niej. Klikalny prototyp, potem MVP, potem, jeśli pomysł się broni, produkt. Decyzje o kierunku podejmujesz na podstawie czegoś, co widzisz i klikasz, a nie na podstawie slajdów. To jest sedno uncrn.

Sama nazwa to zresztą mały żart, który dobrze oddaje filozofię. UNICORN minus zbędne litery daje UNCRN. Projekt minus zbędne równa się cel dowieziony. Nie chodzi o to, żeby robić mniej ambitnie, tylko żeby nie dokładać do startu rzeczy, które na tym etapie nic nie wnoszą. Bo, powiem szczerze, większość projektów IT nie tonie od braku pomysłów. Tonie od nadmiaru.

Co naprawdę spowalnia klasyczny projekt


Kiedy patrzę, gdzie w klasycznym projekcie ucieka czas, rzadko winny jest sam kod. Zwykle winne jest wszystko dookoła kodu. Wycena, która sama w sobie jest kilkutygodniowym przedsięwzięciem, bo żeby rzetelnie wycenić, trzeba rzetelnie przeanalizować, a żeby przeanalizować, trzeba się kilka razy spotkać. Zanim ktokolwiek napisze pierwszą linijkę, minął miesiąc, a na koncie jest dokument, nie działający ekran.

Potem jest specyfikacja. Brief na czterdzieści stron, który opisuje funkcje, jakich użytkownik jeszcze nie widział, więc opisuje je trochę na wyczucie. Część z nich okaże się niepotrzebna, część trzeba będzie zmienić po pierwszym kontakcie z rzeczywistością, ale najpierw wszystkie zostaną opisane, wycenione i zatwierdzone. To praca, która wygląda na postęp, a często jest tylko dobrze udokumentowanym zgadywaniem.

Na końcu dochodzą komitety i akceptacje. Każda decyzja potrzebuje spotkania, każde spotkanie potrzebuje terminu, a terminy się ustawiają w kolejce. To nie jest niczyja złośliwość, tak po prostu działają większe organizacje. Problem w tym, że dla kogoś, kto chce tylko sprawdzić, czy pomysł ma sens, ten cały aparat jest jak jazda na zakupy ciężarówką. Dowieziesz, ale zapłacisz za paliwo, którego nie potrzebowałeś.

Jak wygląda szybka ścieżka w praktyce


Najlepiej pokazać to na pierwszym tygodniu. W poniedziałek jest płatność, bo w uncrn rozliczasz się z góry, o czym za moment. We wtorek robimy trzydziestominutową rozmowę, na której zbieramy to, co naprawdę potrzebne, i to discovery jest wliczone w godziny, nie fakturowane osobno. Środa i czwartek to budowa. W piątek masz pierwszy działający ekran. Nie makietę w Figmie, tylko coś, co się otwiera i reaguje. Zaczynamy w dwadzieścia cztery godziny, bez briefu na czterdzieści stron i bez serii spotkań na rozgrzewkę.

Po naszej stronie nie siedzi zespół juniorów uczący się na twoim projekcie. Pracuje dedykowany senior z co najmniej pięcioletnim stażem, wsparty AI co-pilotem oraz naszym własnym SDK i komponentami zbudowanymi przez lata w aveneo. AI przyspiesza ręce, nie zastępuje głowy. Architekturę, review każdej linii, bezpieczeństwo i wdrożenie robi człowiek. To nie jest samoobsługowe no-code, to usługa człowieka, któremu narzędzia dają tempo. W praktyce jedna godzina uncrn odpowiada mniej więcej trzem do pięciu godzinom klasycznej pracy.

Rozliczenie działa jak doładowanie telefonu na kartę. Jedna stawka, sześćset złotych netto za godzinę, obejmuje wszystko: rozmowy, architekturę, kod, testy, wdrożenie, dokumentację. Nie ma osobnej pozycji za zarządzanie projektem. Makieta to około dziesięciu godzin, mniej więcej sześć tysięcy złotych i jakiś tydzień. MVP to około trzydziestu godzin, w okolicach osiemnastu tysięcy i dwa do trzech tygodni. Produkt to około sześćdziesięciu godzin, około trzydziestu sześciu tysięcy i cztery do sześciu tygodni. Większe pakiety mają bonus godzin, każdy etap wyceniamy przed pracą, a akceptacja to jedno kliknięcie. Godziny zamiast kwartałów.

Co dostajesz i czego nie musisz się bać


Pierwsza obawa przy takim tempie brzmi zwykle tak: skoro robicie szybko, to pewnie na jakimś swoim zamkniętym silniku, z którego potem nie da się wyjść. Odwrotnie. Celowo używamy popularnego, sprawdzonego stacku, TypeScript, React, Node, Electron, mobile, fullstack, do tego AI i ML tam, gdzie mają sens. Żadnych autorskich wynalazków, na których zawiśniesz. Chodzi o to, żeby dowolny programista mógł przejąć kod, gdybyśmy z jakiegoś powodu przestali sobie pasować. Brak vendor lock-in nie jest hasłem marketingowym, jest decyzją technologiczną.

Dostajesz sto procent praw majątkowych do kodu, repozytorium Git i dokumentację. To jest twoje od pierwszego commita, nie po zakończeniu współpracy, nie po jakimś okresie karencji. Do tego masz panel z saldem godzin i logiem prac na żywo, więc widzisz, na co idzie każda godzina, którą kupiłeś. Nic nie dzieje się w czarnej skrzynce, na którą czekasz do końca miesiąca.

Jest jeszcze jedna rzecz, która ludzi uspokaja najbardziej. Projekt można wstrzymać w każdej chwili, a niewykorzystane godziny nie przepadają. Jeśli po makiecie stwierdzisz, że pomysł jednak nie ten, zatrzymujesz się i nie tracisz salda. To zdejmuje z decyzji o starcie sporo ciężaru, bo nie podpisujesz się pod kwartałem zobowiązań, tylko kupujesz tyle, ile chcesz teraz sprawdzić.

Kiedy szybkie MVP nie wystarczy i trzeba pełny proces


Teraz uczciwie, bo bez tego cały ten tekst byłby ulotką, a nie rozmową. Szybka ścieżka nie jest odpowiedzią na wszystko i są projekty, w których zaczynanie od zwinnego MVP byłoby błędem. Systemy krytyczne, w których awaria oznacza realne straty albo zagrożenie, potrzebują pełnej analizy, redundancji i twardego testowania od projektu, nie w drugim podejściu. Tu pewność bije tempo.

Podobnie jest ze złożonymi integracjami. Jeśli twój produkt od pierwszego dnia musi rozmawiać z kilkoma systemami dziedzinowymi, ERP, urządzeniami na produkcji, zewnętrznymi API o kapryśnych regułach, to sama mapa tych połączeń jest projektem analitycznym. Zbudowanie ekranu w piątek nie pomoże, jeśli prawdziwa trudność leży w tym, co dzieje się między systemami. Wtedy discovery nie jest nadmiarem, jest fundamentem.

To samo dotyczy twardych wymagań regulacyjnych i bezpieczeństwa oraz dużej skali od dnia zero. Jeśli od startu obsługujesz wrażliwe dane pod rygorem prawa, albo z góry wiesz, że wchodzisz z ruchem, który wymaga przemyślanej architektury i infrastruktury, to skrót się zemści. W takich sytuacjach w aveneo świadomie zawracamy klienta na pełną ścieżkę, z discovery, analizą i wyceną projektu. To wciąż to samo aveneo, po prostu inne narzędzie do innego zadania. A najczęściej dobra kolejność jest taka, że uncrn sprawdza, czy w ogóle warto, a jeśli warto i robi się poważnie, przechodzimy w tryb dużego systemu.

Od pomysłu do pierwszego ekranu


Klasyczny software house w trzy tygodnie da ci wycenę. My w uncrn w trzy tygodnie oddajemy działające MVP. To nie jest przechwałka wymierzona w kogokolwiek, to opis dwóch różnych obietnic. Jedna mówi „powiemy ci dokładnie, ile to kosztuje i jak zbudować, żeby uniknąć błędów". Druga mówi „pokażemy ci to działające, zanim zdążysz się rozmyślić". Obie są uczciwe, tylko odpowiadają na inne pytania.

Jeśli twoje pytanie brzmi „mam pomysł od miesięcy, czas wreszcie zrobić z tego aplikację", albo „wyrośliśmy z Excela i portale zaczynają zjadać marżę", albo „zarząd nie kupi kolejnych slajdów, muszę pokazać konkret", to szybka ścieżka jest dla ciebie. Wspólny mianownik jest zawsze ten sam: trzeba coś szybko zwalidować albo pokazać działający konkret inwestorowi czy zarządowi, zanim minie okno na decyzję.

uncrn to nasza, aveneo, szybka ścieżka, ten sam zespół i to samo doświadczenie z kilkuset wdrożeń, tylko poukładane pod tempo. Fakturę i tak wystawia aveneo, więc nie ryzykujesz przypadkowym dostawcą. Jeśli nosisz w głowie coś, co chciałbyś wreszcie zobaczyć na ekranie zamiast w prezentacji, odezwij się. Zaczynamy w dwadzieścia cztery godziny, a pierwszy działający ekran jest bliżej, niż myślisz.

O autorze

Milena jest odpowiedzialna nie tylko za opiekę nad kluczowymi klientami firmy, ale przede wszystkim za nawiązywanie nowych relacji biznesowych naszego software house. Z zaangażowaniem dba również o potrzeby wewnętrzne, zapewniając niezakłócony proces biznesowy. Dzięki jej pracy aveneo jest silnym i stabilnym software house.

Milena
Business manager & developer
Jesteś gotowy, żeby porozmawiać o swoim projekcie?