Masz listę kilkunastu funkcji i obawę, że z taką listą pierwsza wersja nigdy nie powstanie. Rozwiązaniem jest MVP aplikacji (z angielskiego minimum viable product, czyli minimalna wersja produktu): najmniejsza wersja, w której jedna osoba może załatwić jedną sprawę od początku do końca. Nie jest to wersja "na próbę" ani wersja gorsza z założenia. To wersja, która ma tylko to, co potrzebne, żeby sprawdzić, czy ktoś chce z niej korzystać.
Dla osoby, która buduje aplikację z AI bez umiejętności programowania, MVP ma jeszcze jedną zaletę: zmniejsza liczbę miejsc, w których coś może się zepsuć. Każda dodatkowa funkcja to kolejne ekrany, dane i błędy do naprawienia. Poniżej metoda cięcia pomysłu do pierwszej wersji oraz rozpisany przykład krok po kroku.
Czym MVP różni się od prototypu i pełnej wersji
Te trzy pojęcia ludzie często mieszają, a różnica ma znaczenie praktyczne.
Prototyp to makieta albo klikalny szkic. Wygląda jak aplikacja, ale nic nie robi naprawdę: przycisk "Zarezerwuj" prowadzi do ekranu z potwierdzeniem, a żadnych danych nie zapisuje. Służy do pokazania pomysłu i zebrania uwag, zanim cokolwiek zbudujesz.
MVP to działająca aplikacja o małym zakresie. Rezerwacja naprawdę się zapisuje, Ty ją widzisz, klient dostaje potwierdzenie. Brakuje wielu dodatków, ale rdzeń działa i ktoś może z niego korzystać w prawdziwej sprawie.
Pełna wersja to aplikacja z całą listą funkcji: płatności, przypomnienia, raporty, ustawienia dla każdego użytkownika. Powstaje po kolejnych miesiącach, najlepiej na podstawie tego, co pokazało MVP, a nie tego, co wymyśliłeś na początku.
Prototyp odpowiada na pytanie "czy to ma sens, gdy zobaczę to na ekranie". MVP odpowiada na pytanie "czy ktoś tego użyje". Pełna wersja pojawia się dopiero, gdy odpowiedź na drugie pytanie brzmi tak.
Dlaczego pierwsza wersja powinna być mniejsza, niż chcesz
Są trzy powody, wszystkie praktyczne.
Pierwszy: czas. Ile funkcji, tyle miejsc na błędy, a przy budowie z AI każda z nich oznacza kolejne rozmowy i poprawki. O tym, jak łatwo wpaść w pętlę poprawek, piszę w tekście aplikacja z AI nie działa: najczęstsze problemy.
Drugi: wiedza. Dopóki nikt nie użył aplikacji, nie wiesz, które funkcje są ważne. Lista w głowie to hipoteza. Użytkownicy zwykle proszą o coś innego, niż zakładałeś.
Trzeci: motywacja. Projekt, który po tygodniu pokazuje coś działającego, ma szansę zostać dokończony. Projekt, który po miesiącu ma dziesięć połowicznie zrobionych funkcji, często ląduje w szufladzie.
Metoda cięcia w pięciu krokach
W programie Własna Apka ten fragment nazywamy cięciem do pierwszej wersji. Poniżej wersja, którą możesz zrobić sam, z kartką albo arkuszem.
Krok 1: Wypisz wszystko
Zapisz każdą funkcję, która przyjdzie Ci do głowy, bez oceniania. Im szybciej, tym lepiej. Nie układaj ich jeszcze w kolejności.
Krok 2: Opisz jedną ścieżkę użytkownika
Wybierz jedną osobę i jedną sprawę, którą ma załatwić, od pierwszego kliknięcia do końca. Zapisz kroki po kolei, w formie: "wchodzi na stronę, wybiera X, podaje Y, dostaje Z". To jest kręgosłup aplikacji. Wszystko, co na tej ścieżce nie leży, jest kandydatem do wycięcia.
Krok 3: Zadaj każdej funkcji jedno pytanie
Dla każdej funkcji z listy zapytaj: "czy bez tego ta jedna ścieżka przestaje działać?". Jeśli odpowiedź brzmi nie, funkcja idzie na listę "później". Pytanie jest celowo bezlitosne. Wiele rzeczy, które wydają się ważne (logowanie przez Google, motyw ciemny, eksport do PDF), przy takim sprawdzeniu odpada.
Krok 4: Zastąp automatyzację pracą ręczną
To krok, który najbardziej skraca pierwszą wersję. Wiele funkcji da się na początku wykonywać samemu, bez kodu. Na przykład: zamiast automatycznych przypomnień SMS wysyłasz je ręcznie z telefonu. Zamiast płatności online przyjmujesz przelew albo gotówkę. Zamiast statystyk zaglądasz do listy i liczysz sam. Przy kilku pierwszych użytkownikach to wystarcza, a Ty dowiadujesz się, czy w ogóle warto tę automatyzację budować.
Krok 5: Ustal, po czym poznasz, że wersja jest gotowa
Zapisz jedno zdanie: "wersja jest gotowa, gdy [konkretna osoba] może [konkretna czynność] bez mojej pomocy". Bez takiego zdania MVP rośnie w nieskończoność, bo zawsze da się dodać "jeszcze jedną drobnostkę". W programie to zdanie piszemy wspólnie na spotkaniu 1:1, na Twoim projekcie.
Przykład krok po kroku: rezerwacje dla gabinetu
To przykład hipotetyczny, służy tylko do pokazania metody. Nie opisuje prawdziwego klienta.
Wyobraź sobie osobę, która prowadzi mały gabinet (fizjoterapia, kosmetyka, masaż, to bez znaczenia) i chce, żeby klienci sami umawiali wizyty, zamiast dzwonić albo pisać na komunikatorze.
Krok 1: lista wszystkiego
Na kartce pojawia się piętnaście pomysłów:
- kalendarz z wolnymi terminami,
- formularz rezerwacji (imię, telefon, rodzaj usługi),
- lista rezerwacji dla właściciela,
- potwierdzenie rezerwacji mailem,
- przypomnienie SMS dzień przed wizytą,
- konta klientów z historią wizyt,
- płatność online z góry,
- odwoływanie i przekładanie wizyt przez klienta,
- kilku pracowników z osobnymi kalendarzami,
- cennik i opisy usług,
- opinie klientów po wizycie,
- kody rabatowe,
- statystyki (ilu klientów, jakie usługi),
- eksport do arkusza,
- aplikacja na telefon.
Krok 2: jedna ścieżka
Wybieramy jedną osobę: nowego klienta, który chce umówić jedną wizytę. Ścieżka wygląda tak: wchodzi na stronę, wybiera usługę, wybiera wolny termin, podaje imię i telefon, wysyła. Właściciel widzi nową rezerwację na swojej liście.
Krok 3: pytanie do każdej funkcji
Przechodzimy listę z pytaniem "czy bez tego ta ścieżka przestaje działać?".
- Kalendarz z wolnymi terminami (1): zostaje. Bez niego klient nie wybierze terminu.
- Formularz rezerwacji (2): zostaje. To sama czynność.
- Lista rezerwacji dla właściciela (3): zostaje. Bez niej rezerwacja nigdzie nie trafia.
- Cennik i opisy usług (10): zostaje w wersji minimalnej, jako lista usług do wybrania w formularzu.
- Pozostałe odpadają z pierwszej wersji, bo ścieżka działa także bez nich.
Z piętnastu pomysłów zostają cztery. Pozostałe jedenaście ląduje na liście "później".
Krok 4: ręcznie zamiast automatycznie
Co z funkcjami, które odpadły, ale i tak są potrzebne w praktyce?
- Potwierdzenie mailem (4): na początku właściciel sam odpisuje albo dzwoni do klienta po otrzymaniu rezerwacji. Przy kilku rezerwacjach tygodniowo to chwila.
- Przypomnienie SMS (5): właściciel wysyła je sam z telefonu, patrząc na listę.
- Płatność (7): klient płaci na miejscu.
- Odwołanie wizyty (8): klient dzwoni lub pisze, właściciel usuwa wpis z listy.
- Kilku pracowników (9): jeśli gabinet ma jedną osobę, to w ogóle nie jest problem. Jeśli ma więcej, pierwsza wersja obsługuje jedną osobę, a reszta czeka.
Krok 5: kryterium gotowości
Zapisujemy: "wersja jest gotowa, gdy nowy klient może sam umówić wizytę przez stronę, a właściciel widzi ją na liście i nie musi o nic dopytywać".
Co z tego wynika
Zamiast aplikacji z piętnastoma funkcjami powstaje narzędzie z czterema, które można zbudować i sprawdzić na kilku prawdziwych osobach. Po kilku tygodniach używania właściciel będzie wiedział, co naprawdę przeszkadza: czy to brak przypomnień, czy płatność, czy może coś, czego na liście nie było. Wtedy wraca do listy "później" i wybiera jedną funkcję, nie osiem naraz.
Jak sprawdzić, że wycięcie było trafne
Po zbudowaniu pierwszej wersji nie pytaj znajomych, czy "fajna". Daj ją kilku osobom z grupy, dla której powstała, i obserwuj, co robią bez Twoich podpowiedzi. Zapisuj trzy rzeczy: czy doszły do końca ścieżki, w którym miejscu się zatrzymały i o co zapytały. Brak ruchu też jest informacją: jeśli nikt nie skorzystał, zanim dodasz funkcje, wróć do pytania, czy problem, który rozwiązujesz, jest dla tych ludzi ważny.
Dobrym sygnałem jest sytuacja, w której ktoś używa aplikacji, choć jest w niej brak, i prosi o konkretną funkcję. Wtedy wiesz, co dołożyć jako następne, i nie zgadujesz. Zła wiadomość też bywa cenna: kilka tygodni pracy i jasna odpowiedź kosztują mniej niż pół roku budowy pełnej wersji.
Pułapki, które psują cięcie
Wycinanie rdzenia zamiast dodatków. Zdarza się, że z ostrożności zostaje się przy ładnych dodatkach, a wycina to, co sprawia trudność. Test ścieżki użytkownika chroni przed tym: rdzeń to to, bez czego ścieżka nie działa, niezależnie od tego, jak trudno go zbudować.
"Jeszcze tylko to". Każda wymówka brzmi rozsądnie osobno. Kryterium gotowości z kroku 5 jest po to, żeby móc je odrzucić.
Budowanie dla wszystkich naraz. Pierwsza wersja obsługuje jedną grupę ludzi i jedną sprawę. Gdy próbujesz zadowolić klienta, pracownika i administratora jednocześnie, zakres rośnie trzykrotnie.
Wycinanie rzeczy prawnych i bezpieczeństwa. Zasada "tylko to, co potrzebne" nie dotyczy podstaw. Jeśli aplikacja zbiera dane ludzi, potrzebujesz polityki prywatności i bezpiecznego przechowywania danych, nawet w pierwszej wersji. Więcej o tym w tekście jak opublikować aplikację pod własną domeną.
Gdzie cięcie i budowa samemu zwykle się sypią
Da się to zrobić samemu, ale są dwa miejsca, w których pierwsza wersja często grzęźnie. Pierwsze to samo cięcie: własne funkcje trudno wyrzucać, a lista „później” po cichu wraca do zakresu. Drugie to budowa z AI po wycięciu. Zakres jest już mały, a mimo to wszystko staje na błędach: coś, co działało, przestaje działać po kolejnej zmianie, elementy nie chcą się połączyć, a Ty nie wiesz, czy winne jest AI, ustawienia czy Twój opis.
Prowadzenie 1:1 zmienia to, że przy obu momentach ktoś jest obok. W programie Własna Apka tniemy pomysł do pierwszej wersji razem, a potem budujesz z AI na żywo: łączysz elementy, testujesz i rozwiązujesz błędy, na których zwykle wszystko staje. Robisz to na gotowym szkielecie, nie od pustego ekranu, i nie musisz znać ani linijki kodu. Aplikacja nie musi też mieć AI w środku: AI pomaga ją zbudować. Oszczędność polega na tym, że błędy rozwiązujesz w trakcie spotkania, a nie w kolejnych wieczorach bez pewności, czy idziesz w dobrą stronę.
Co dalej po wycięciu
Gdy masz listę trzech, czterech funkcji i jedną ścieżkę, kolejny krok to budowa. W programie rusza ona na gotowym szkielecie, więc nie zaczynasz od pustego ekranu. Przy pracy z AI pomaga opisanie jej tak, jak ścieżka powyżej: osoba, czynność i oczekiwany wynik, jedna zmiana na raz. Całą drogę, od sprawdzenia pomysłu po wdrożenie, opisuję w przewodniku jak stworzyć aplikację bez programowania. Zanim zaczniesz ciąć, warto jeszcze upewnić się, że problem, który rozwiązujesz, naprawdę istnieje: o tym jest tekst jak sprawdzić pomysł na aplikację.
Jeśli chcesz to zrobić razem z kimś
Cięcie pomysłu możesz zrobić sam, z kartką i metodą z tego tekstu. Program Własna Apka jest dla osób, które wolą zrobić to z kimś, kto pomoże wyrzucić to, co ciężko wyrzucić, a potem poprowadzi budowę.
W programie dostajesz: około 15 godzin pracy na żywo, prowadzenie 1:1, w trzech etapach: potrzeba (sprawdzasz pomysł z ludźmi), budowa (budujesz z AI na gotowym szkielecie, nie zaczynasz od pustego ekranu) i wdrożenie (własny adres, pierwsi użytkownicy, oferta). Między spotkaniami dostajesz materiały i zadania do własnego projektu, a potem sprawdzamy każdy etap. Etap budowy to cięcie pomysłu do pierwszej wersji i budowanie z AI na żywo.
Program jest dla osoby, która ma pomysł i listę funkcji albo utknęła w budowie z AI. Nie jest dla osób, które chcą, żeby ktoś zbudował aplikację za nie, ani dla tych, którzy szukają gwarancji klientów lub przychodu: nie budujemy aplikacji za uczestnika i niczego takiego nie gwarantujemy. Wynik zależy od potrzeby rynkowej, jakości rozwiązania i Twojej pracy.
Cena brutto to 4 900 zł na start (albo 3 raty po ok. 1 633 zł) i 7 100 zł dopłaty, ale tylko wtedy, gdy Twoja aplikacja osiągnie 40 000 zł przychodu w 18 miesięcy. To warunek dopłaty, nie prognoza zarobków. Jest też wariant 8 700 zł jednorazowo, bez dopłaty.
Pierwszy krok to zgłoszenie na stronie (8 krótkich pytań), a potem bezpłatna rozmowa. Zgłoszenie nie jest zakupem. Przyjmujemy maksymalnie 5 nowych osób miesięcznie, to nasza zasada pracy.