Budowa MVP

Bezpłatna konsultacja Projekty

Pierwsza wersja produktu postawiona na produkcji - z logowaniem, danymi, obsługą błędów i pomiarem tego, co robią pierwsi użytkownicy. Nie prezentacja dla zarządu, tylko adres, pod który wysyłasz ludzi.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Trzy momenty, w których MVP jest tańsze niż dalsze planowanie

Nie wiesz, czy to już moment na MVP, czy jeszcze na interaktywny projekt? Umów konsultację - powiemy wprost, którą z tych dwóch rzeczy warto kupić najpierw.

  • „Prototyp jest zaakceptowany i nie ma czego przepisywać”

    Klikalna wersja produktu przeszła przez decydentów i użytkowników, a kolejnym krokiem nie jest nowy projekt, tylko podłączenie danych i kont. Zamiast startować od nowa, dokładamy do istniejącego kodu warstwę, której prototyp nie potrzebował.

  • „Pomysł ma budżet i termin, ale nie ma ani jednego użytkownika”

    Decyzja o dużym wdrożeniu ma zapaść na podstawie dokumentu i szacunków, których nikt nie zweryfikował w realnym użyciu. Wersja, którą da się dać dwudziestu osobom, rozstrzyga w kilka tygodni spory ciągnące się na spotkaniach od kwartału.

  • „Narzędzie wewnętrzne przerosło arkusz albo platformę no-code”

    Rozwiązanie sklejone na szybko obsługuje już cudze dane, kilka ról i procesy, od których zależy czyjaś codzienna praca. To moment na przeniesienie go na własny kod - zanim ograniczenie platformy zablokuje funkcję, której nie da się odłożyć.

Dla kogo

Dla kogo budujemy pierwszą wersję produktu

  • Founderzy przed rozmowami o finansowaniu albo tuż po nich

    Prezentacja obroniła pomysł, ale kolejne pytania dotyczą już tego, czy ktokolwiek tego używa i jak się zachowuje. Budujemy wersję, którą można rozdać pierwszym użytkownikom i pokazać w rozmowie jako działający produkt, a nie jako zestaw slajdów o produkcie przyszłym.

  • Zespoły produktowe wchodzące w nowy obszar obok głównego produktu

    Nowy moduł albo osobna linia produktowa musi zostać sprawdzona, ale wciągnięcie jej do głównego repozytorium zablokowałoby roadmapę na kwartał. Stawiamy ją obok, na własnym wdrożeniu, i dopiero potwierdzone rozwiązanie wraca do rozmowy o włączeniu do produktu głównego.

  • Firmy z narzędziem wewnętrznym, które wyrosło z prowizorki

    Arkusz, formularz i kilka automatyzacji obsługują dziś proces, od którego zależy praca całego działu, a każda zmiana wymaga jednej konkretnej osoby. Przenosimy ten proces na własną aplikację z kontami i historią zmian, zaczynając od czynności wykonywanej najczęściej.

  • Działy IT i software house'y bez wolnych rąk na dodatkowy produkt

    Kompetencje są w środku, ale cały zespół jest przypisany do zobowiązań wobec obecnych klientów, a nowy pomysł czeka w kolejce od miesięcy. Prowadzimy budowę obok Waszego zespołu, w Waszych konwencjach i Waszym repozytorium, żeby przejęcie produktu po starcie nie oznaczało poznawania obcego kodu.

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 podejście

  • Dokańczamy prototyp, zamiast go przepisywać

    W typowym układzie projekt powstaje w narzędziu graficznym, a potem drugi zespół odtwarza go w kodzie - i to odtwarzanie jest osobnym, pełnym etapem. Nasz interaktywny projekt od początku jest kodem, więc MVP zaczyna się od dołożenia backendu do rzeczy, która już działa i została zaakceptowana.

  • Tempo bierze się z usuniętego przekazania, nie z gotowej biblioteki

    Częsta obietnica szybszego MVP opiera się na składaniu ekranów z gotowych zestawów komponentów - tempo rośnie, ale interfejs wygląda jak setka innych produktów zbudowanych z tego samego zestawu. My skracamy drogę w miejscu, w którym naprawdę ucieka czas, czyli na styku projektu i implementacji, a wygląd zostaje Wasz.

  • Sufit rozwiązania nazywamy przed pierwszą linijką kodu

    Najdroższe MVP to takie, które zadziałało, zdobyło użytkowników i po pół roku okazało się nie do rozwinięcia bez przepisania całości. Dlatego zanim wybierzemy stos, spisujemy, przy jakiej liczbie użytkowników, jakiej integracji i jakim wymogu wobec danych obecne rozwiązanie przestanie wystarczać.

  • Lista odrzuconych funkcji jest częścią dostawy

    Zakres MVP tnie się raz, a potem broni przez kilkanaście tygodni, zwykle wobec osób, których przy tamtej rozmowie nie było. Zapisana decyzja z uzasadnieniem zamyka ten spór w minutę i sprawia, że odłożona funkcja wraca w zaplanowanym momencie, a nie w środku prac nad główną ścieżką.

Proces

6–14 tygodni od cięcia zakresu do pierwszych kont na produkcji

  1. Tydzień 1

    Cięcie zakresu

    Ustalamy, jaką jedną decyzję ma rozstrzygnąć ta wersja i którą ścieżką użytkownik do niej dochodzi. Wszystko, co tej ścieżki nie dotyka, ląduje na liście odłożonych - razem z warunkiem, po którym wróci do rozmowy.

  2. Tydzień 1–2

    Sufit techniczny i wybór stosu

    Zanim powstanie pierwsza linijka, nazywamy ograniczenia wybranego rozwiązania - liczbę użytkowników, integracje, wymagania wobec danych osobowych. Wybór stosu zapada pod planowaną wersję po MVP, nie pod samo MVP, bo to drugie zawsze da się dowieźć czymkolwiek.

  3. Tydzień 2–6

    Główna ścieżka w kodzie

    Budujemy przejście od wejścia do momentu, w którym użytkownik dostaje wartość, i wypuszczamy je na środowisko testowe od razu. Kolejne tygodnie zamykamy działającym wydaniem do klikania, więc postęp ogląda się w produkcie, a nie na liście zadań.

  4. Tydzień 4–10

    Konta, dane i integracje

    Rejestracja, logowanie, role i uprawnienia, trwały zapis danych oraz połączenia z systemami, bez których produkt nie ma sensu - płatnościami, pocztą, CRM-em albo API po Waszej stronie. Tu też ustalamy, jakie dane naprawdę musimy zbierać, a jakich lepiej nie mieć.

  5. Tydzień 8–14

    Twarde brzegi i wejście na produkcję

    Stany błędu, puste widoki, zachowanie przy zerwanym połączeniu, obsługa klawiaturą i czytnikiem ekranu, wydajność na słabszym telefonie. Potem domena, kopie zapasowe, monitoring i wpuszczenie pierwszych kont - najczęściej partiami, a nie wszystkich naraz.

Zakres

Trzy rzeczy na wyjściu. Produkt, decyzja o zakresie i pierwszy pomiar

  • Zakres MVP - z listą tego, co nie wchodzi

    Funkcje rozłożone na te, bez których nie da się przejść głównej ścieżki, i te, które poczekają na wersję po walidacji. Lista odrzuconych jest zapisana razem z powodem odrzucenia, więc pół roku później nikt nie odtwarza tej rozmowy od nowa.

  • Produkt na produkcji - konta, dane, wdrożenie

    Działająca aplikacja pod własną domeną - rejestracja i logowanie, role użytkowników, trwałe dane, stany błędu i pustych widoków, wersja mobilna. Do tego środowisko testowe obok produkcyjnego i wdrożenia wypuszczane z repozytorium, a nie ręcznie.

  • Pomiar pierwszych użytkowników i backlog kolejnej wersji

    Zdarzenia w analityce wpięte w te kroki ścieżki, które faktycznie coś rozstrzygają, plus kanał zbierania uwag od pierwszych kont. Po miesiącu dostajecie zestawienie miejsc, w których ludzie odpadają, i backlog ułożony pod te miejsca.

Warsztat

Co stosujemy

Rzeczy, których w pierwszej wersji nie odpuszczamy, bo dokładane później kosztują wielokrotnie więcej niż zrobione od razu - dostępność, ochrona danych i powtarzalne wdrożenia.

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
  • TypeScript na froncie i backendzie
  • Uwierzytelnianie, role i uprawnienia od pierwszego wydania
  • WCAG 2.2 AA na głównej ścieżce
  • Środowisko testowe obok produkcyjnego
  • Wdrożenia z repozytorium, z możliwością cofnięcia
  • RODO - minimalizacja danych i jawne zgody

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 budujemy od pierwszej wersji

Wybór projektów z tych typów produktów, przy których najczęściej stawiamy pierwszą działającą wersję - aplikacji webowych, paneli i narzędzi wewnętrznych. Część wdrożeń objęta jest poufnością, więc pokazujemy je na konsultacji.

Projekty

Efekty

Co dostajecie, w jakim terminie i po czym to sprawdzicie

  • 6–14 tygodni

    Od cięcia zakresu do wersji, z której korzystają prawdziwi użytkownicy - sześć tygodni przy jednej ścieżce na gotowym interaktywnym projekcie

  • 1 baza kodu

    Prototyp i wersja produkcyjna to ten sam projekt w Waszym repozytorium - nie ma etapu przepisywania makiet na kod

  • WCAG 2.2 AA

    Publiczny standard dostępności W3C, wobec którego sprawdzamy główną ścieżkę, zanim wpuścimy na nią pierwsze konta

  • 30 dni

    Okno po starcie, w którym poprawiamy błędy z realnego użycia i zamykamy pierwszy pomiar zachowania użytkowników

Termin i zakres pochodzą z harmonogramu opisanego wyżej na tej stronie, a WCAG 2.2 AA to publiczny standard W3C. Nie podajemy uśrednionych wyników rund inwestycyjnych ani liczby użytkowników zdobytych przez klientów - te dane należą do nich i pokazujemy je imiennie na konsultacji, za ich zgodą.

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

Czas i zakres

Ile trwa budowa i od czego zależy wycena

6–14 tygodni

Sześć tygodni to jedna główna ścieżka budowana na gotowym, zaakceptowanym interaktywnym projekcie, z jedną rolą użytkownika i bez rozbudowanych integracji. Czternaście tygodni i dalej to produkt z kilkoma rolami, płatnościami i wymianą danych z systemami po Waszej stronie - wtedy dzielimy prace na wydania, żeby pierwsi użytkownicy dostali coś do ręki wcześniej.

  • Liczba ścieżek i ról użytkowników w pierwszej wersji

  • Punkt wyjścia - gotowy interaktywny projekt albo start od zera

  • Zakres integracji z systemami, płatnościami i logowaniem zewnętrznym

  • Wymagania wobec danych osobowych i obowiązki wynikające z branży

  • To, czy produkt po starcie przejmuje Wasz zespół, czy prowadzimy go dalej

Pytania

Pytania, które padają najczęściej

Ile kosztuje budowa MVP?

Wyceniamy indywidualnie, bo dwa MVP o tej samej nazwie potrafią różnić się kilkukrotnie zakresem. Na kwotę wpływa liczba ścieżek i ról użytkowników w pierwszej wersji, punkt wyjścia (gotowy interaktywny projekt albo start od zera), zakres integracji - płatności, logowanie zewnętrzne, wymiana danych z Waszymi systemami - wymagania wobec danych osobowych oraz to, czy po starcie produkt przejmuje Wasz zespół, czy prowadzimy go dalej. Konkretną propozycję z rozpisanym zakresem dostajesz w 48 godzin od briefu.

Czym budowa MVP różni się od interaktywnego projektu?

Interaktywny projekt to działający, klikalny produkt bez warstwy serwerowej - świetny do decyzji i rozmów, ale dane znikają po odświeżeniu i nikt nie założy tam konta. MVP dokłada to, czego prototyp nie potrzebował - logowanie, trwały zapis danych, uprawnienia, integracje i wdrożenie na produkcję. Jeśli jesteście przed pierwszą wersją, zwykle taniej wychodzi zacząć od interaktywnego projektu i dopiero jego dokończyć, bo wtedy MVP nie zaczyna się od przepisywania.

Czy MVP da się zbudować na no-code?

Czasem tak i wtedy sami to proponujemy - jeśli produkt ma jedną rolę, prosty model danych i służy głównie do sprawdzenia zainteresowania, wdrożenie no-code bywa szybsze i tańsze. Sufit pojawia się przy wielu rolach, nietypowych uprawnieniach, większych wolumenach danych i integracjach po Waszej stronie. Dlatego ten sufit nazywamy przed wyborem narzędzia - przejście z platformy na własny kod po fakcie kosztuje więcej niż zbudowanie od razu tego drugiego.

Mamy już projekt w Figmie. Co się wtedy zmienia?

Pracujemy na tym, co jest - makiety skracają etap ustalania ścieżek i wyglądu. Zmienia się natomiast to, że projekt graficzny trzeba przełożyć na kod, więc znika oszczędność wynikająca z dokańczania istniejącego prototypu. Zaczynamy od przeglądu makiet pod kątem stanów, których zwykle w nich nie ma - błędów, pustych list, długich treści, wersji mobilnej i obsługi klawiaturą. Te braki uzupełniamy w kodzie, a nie zawracamy projektu do Figmy.

Czyje jest repozytorium i co dzieje się po starcie?

Kod od pierwszego dnia stoi w repozytorium należącym do Was, razem z konfiguracją wdrożeń i dokumentacją uruchomienia projektu na nowej maszynie. Przez trzydzieści dni po starcie poprawiamy błędy wychodzące z realnego użycia i zamykamy pierwszy pomiar zachowania użytkowników. Potem albo przekazujemy produkt Waszemu zespołowi wraz z backlogiem kolejnej wersji, albo prowadzimy go dalej - to decyzja, którą można podjąć po starcie, nie przed nim.

Co jeśli MVP pokaże, że pomysł nie działa?

To jest wynik, po który się buduje pierwszą wersję, i najtańszy moment, żeby go poznać. Zwykle nie jest zero-jedynkowy - częściej okazuje się, że ludzie wchodzą, ale odpadają w jednym konkretnym kroku, albo używają produktu inaczej, niż zakładał zakres. Dlatego pomiar wpinamy w te miejsca ścieżki, które coś rozstrzygają. Na koniec dostajecie zestawienie, gdzie ludzie odpadają, i rekomendację - poprawiać ścieżkę, zmienić grupę odbiorców czy zatrzymać prace przed większym wdrożeniem.

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ę