Jak stworzyć aplikację dla firmy: od pomysłu do MVP

Większość poradników o tym, jak stworzyć aplikację, zaczyna od wyboru platformy: Android czy iOS, kod czy no-code. Dla firmy to zła kolejność. Technologia jest najtańszą decyzją w całym projekcie. Najdroższa jest ta, której nikt nie podjął: czy ta aplikacja w ogóle powinna powstać i co dokładnie ma robić w pierwszej wersji.

Ten tekst jest dla właścicieli i menedżerów firm, które nie są firmami technologicznymi. Macie pomysł na portal dla klientów, narzędzie dla zespołu albo nową usługę w formie aplikacji. Poniżej pięć kroków, które prowadzą od pomysłu do MVP, czyli pierwszej wersji, która działa i którą da się zmierzyć.

Krok 1: nazwij jeden problem i policz, ile kosztuje

Aplikację dla firmy zaczyna się od jednego zdania: kto ma problem, jaki i ile on kosztuje dziś. Jeśli tego zdania nie da się napisać, za wcześnie na makiety i wyceny. Dobry problem jest częsty, konkretny i ma właściciela w firmie, który odczuje różnicę po wdrożeniu.

Kilka przykładów, jak to zdanie może wyglądać:

• „Klient, który korzysta z dwóch naszych usług, ma dwa konta, dwie faktury i nikt nie widzi jego pełnej historii.”
• „Biuro przepisuje zamówienia z maili do systemu, zajmuje to jednej osobie kilka godzin dziennie.”
• „Handlowcy liczą wyceny w arkuszu, każda wersja wygląda inaczej i trudno je porównać.”

Zwróćcie uwagę, czego tu nie ma. Nie ma słowa „aplikacja”, nie ma funkcji, nie ma technologii. Jest tylko sytuacja i jej koszt: czas, pieniądze albo klienci, którzy odchodzą. Z takiego zdania łatwo potem wyprowadzić, co pierwsza wersja musi robić. Z listy funkcji wyprowadzić problemu się nie da.

Jeszcze jedno: policzcie koszt choćby z grubsza. Godziny pracy w tygodniu razy stawka, liczba utraconych zamówień, czas odpowiedzi klientowi. Ta liczba przyda się dwa razy. Najpierw, żeby ocenić, czy budowa ma sens. Potem, żeby po wdrożeniu sprawdzić, czy aplikacja zadziałała.

Krok 2: sprawdź pomysł, zanim powstanie kod

Najtańszy moment, żeby odkryć, że pomysł nie działa, jest przed pierwszą linią kodu. Ten etap nazywa się discovery: krótka faza, w której rozmawia się z przyszłymi użytkownikami, sprawdza obecne narzędzia i testuje najbardziej ryzykowne założenie najtańszym możliwym sposobem.

W praktyce to kilka rzeczy:

1. Rozmowy z użytkownikami. Z klientami, jeśli aplikacja jest dla klientów. Z zespołem, jeśli dla zespołu. Pytacie o to, jak robią to dziś i co ich w tym boli, a nie o to, czy chcieliby aplikację. Na to drugie prawie każdy odpowie „tak”.
2. Mapa obecnych narzędzi. Gdzie dziś są dane, kto je wpisuje, gdzie się psuje. Często okazuje się, że połowę problemu rozwiązuje lepsza konfiguracja tego, co już jest.
3. Test ryzykownego założenia. Klikalny prototyp, prosta strona z zapisem na listę albo usługa robiona ręcznie dla kilku klientów. Jeśli nikt nie chce wersji ręcznej, wersja automatyczna też nie pomoże.

Discovery kończy się decyzją: budujemy, budujemy coś mniejszego albo nie budujemy. Każda z tych odpowiedzi jest dobrym wynikiem. Zła jest tylko sytuacja, w której tej decyzji nikt nie podjął, a zespół pisze już kod.

Znamy to z obu stron. Max był współzałożycielem startupu Skillsbite (2021, AI do analizy CV), gdzie własny pomysł trzeba było sprawdzić i zmienić kierunek. Potem projektował i budował produkty dla klientów. Najdroższy błąd po obu stronach wygląda tak samo: pełna budowa, zanim ktokolwiek sprawdził, że klienci tego chcą.

Krok 3: zawęź pierwszą wersję do jednej rzeczy

MVP aplikacji dla firmy powinno robić jedną rzecz, której nie daje żadne gotowe narzędzie, i łączyć się z resztą. Nie powinno na start odtwarzać kalendarza, płatności, fakturowania ani księgowości. To problemy rozwiązane przez gotowe programy, a ich przepisywanie od zera to miejsce, w którym znikają budżety i terminy.

Prosty sposób, żeby podzielić zakres:

Dobra reguła: jeśli pierwsza wersja potrzebuje więcej niż trzech, czterech ekranów, żeby była użyteczna, zakres jest prawdopodobnie za szeroki. Lepiej wypuścić coś wąskiego za kilka tygodni niż szerokiego za rok. Wąska wersja szybciej trafia do ludzi, a dopiero ludzie mówią, co dalej.

Przykład: jedna aplikacja dla kilku firm usługowych

Pracujemy teraz z klientem w USA, który prowadzi kilka firm usług domowych: sprzątanie, hydraulika, elektryka, malowanie, przeprowadzki i inne. Każda firma działa dobrze osobno. Kłopot ma klient końcowy. Właściciel domu, który w tym miesiącu zamawia sprzątanie, a w następnym hydraulika, trafia do dwóch różnych firm, przechodzi dwie różne rezerwacje i nie ma wspólnej historii.

Pomysł to platforma abonamentowa dla właścicieli domów: jedno miejsce, żeby zamówić dowolną usługę, śledzić zlecenie i trzymać historię domu ze zdjęciami i fakturami. Firmy zostają przy swoim programie do obsługi zleceń (Jobber), a nowa aplikacja łączy się z nim jako warstwa, którą widzi klient. Cel na 12 miesięcy jest konkretny: MVP z płacącymi abonentami.

Najważniejsza decyzja zapadła na początku: pierwsza wersja nie przepisuje planowania ani fakturowania. Zespoły zostają w narzędziu, które znają. Aplikacja zaczyna od tego, czego żadne narzędzie nie robi, czyli od wspólnego konta klienta i historii usług we wszystkich firmach.

Krok 4: zbuduj na tym, czego firma już używa

Pierwszą wersję buduje się etapami, każdy z jasnym wynikiem i ceną ustaloną przed startem. Kolejność, którą stosujemy: diagnoza w pierwszym tygodniu, prototyp na prawdziwych danych klienta w drugim, wdrożenie w tygodniach od trzeciego do szóstego. Potem opieka i poprawki według tego, co pokazali użytkownicy.

Kilka zasad, które oszczędzają najwięcej czasu i pieniędzy:

• Integracje zamiast zastępowania. Większość programów branżowych ma API albo gotowe połączenia. Aplikacja czyta i zapisuje dane w systemie, którego zespół już używa. Zanim zaplanujecie zakres, sprawdźcie, czy wasz plan w tym programie daje dostęp do API.
• Dane i konta po stronie firmy. Repozytorium kodu, serwer, domena i konta w usługach powinny należeć do was, nie do wykonawcy. To samo dotyczy danych klientów.
• Stała cena za etap. Widełki da się podać po pierwszej rozmowie, a dokładną cenę przed każdym etapem, kiedy wiadomo już, co w nim będzie. Rozliczenie „ile wyjdzie” przy nieznanym zakresie kończy się zwykle sporem.
• Koszty działania liczone od razu. Jeśli aplikacja korzysta z AI albo płatnych usług, ich miesięczny koszt trzeba policzyć przed budową, nie po pierwszej fakturze.

Przykład: co pokazuje budowa własnego produktu

Max zbudował od zera Podium, narzędzie do pisania i publikowania artykułów na blogi firm. Plan pierwszej wersji miał siedem tygodniowych etapów: infrastruktura i płatności, onboarding, skan widoczności, silnik artykułów, publikacja, linki, ustawienia dla wielu stron.

Dwie rzeczy z tej budowy dobrze pokazują, po co jest MVP. Pierwszy artykuł wygenerowany na największym modelu AI kosztował 2,10 dolara, bo wymagał trzech prób. Plan zakładał tańszy model, więc decyzja zapadła od razu: tańszy model domyślnie, do tego dzienny budżet na stronę (2 dolary), po którego przekroczeniu system wstrzymuje pracę i wysyła alarm. Bez prawdziwego uruchomienia tej liczby by nie było.

Druga rzecz: pierwszy prawdziwy onboarding na serwerze produkcyjnym od razu pokazał błędy, których nie było na komputerze. Brakowało kluczy do usług AI na serwerze, jedna z usług odrzuciła zapytania z powodu braku środków na koncie, a panel pokazywał surowe komunikaty błędów zamiast zrozumiałej informacji. Każdą z tych rzeczy dało się naprawić. Tylko że żadnej z nich nie widać, dopóki aplikacja nie trafi do prawdziwego użytkownika.

Krok 5: zmierz i zdecyduj, co dalej

MVP ma sens tylko wtedy, gdy po wdrożeniu ktoś patrzy na liczby i podejmuje decyzję. Wracacie do kosztu z pierwszego kroku: czy przepisywanie zamówień trwa krócej, czy klienci zakładają konto, czy ktoś płaci za abonament. Na tej podstawie decydujecie, co rozwijać, co uprościć i co wyrzucić.

Co mierzyć w pierwszych tygodniach:

Lista funkcji z początku projektu nie jest planem na dalszy rozwój. Jest hipotezą. Po pierwszych tygodniach zwykle okazuje się, że jedna funkcja jest używana codziennie, a trzech innych nikt nie otworzył. Kolejny etap budujecie wokół tej pierwszej.

Ile to trwa i kto powinien to zbudować

Discovery trwa zwykle tydzień albo dwa. Wąska pierwsza wersja zbudowana na istniejących narzędziach to kilka tygodni więcej, zależnie od liczby integracji. Pełne zastąpienie programów, których firma używa do planowania i fakturowania, trwa wielokrotnie dłużej i rzadko jest dobrym pierwszym krokiem.

Przy wyborze wykonawcy macie z grubsza trzy drogi:

• Narzędzia no-code. Dobre do prototypu i do prostych narzędzi wewnętrznych. Gorzej sprawdzają się, kiedy aplikacja ma łączyć kilka systemów albo obsługiwać płatności i abonamenty klientów.
• Software house. Duży zespół, który dobrze buduje to, co zostało opisane. Upewnijcie się, kto w tym układzie odpowiada za pytanie, czy w ogóle warto to budować.
• Mały zespół produktowy. Ta sama osoba prowadzi discovery i odpowiada za budowę, więc decyzje z rozmów z użytkownikami nie giną po drodze. Sprawdza się przy wąskich pierwszych wersjach, gorzej przy dużych systemach budowanych od razu w całości.

Niezależnie od wyboru zapytajcie o trzy rzeczy: jak wykonawca sprawdzi, że pomysł ma sens, co dokładnie będzie w pierwszej wersji, a czego w niej nie będzie, i do kogo będzie należał kod oraz konta.

Jeśli zastanawiacie się nad aplikacją dla swojej firmy, 30-minutowa rozmowa zwykle wystarcza, żeby ustalić, czy potrzebna jest nowa aplikacja, czy lepsze ustawienie narzędzi, które już macie. Umów rozmowę albo przeczytaj, jak wygląda budowa MVP. Możesz też zamówić darmowy raport z pomysłami dla Twojej firmy.

Najczęstsze pytania

Jak stworzyć aplikację, jeśli nie umiem programować?

Nie musisz programować, ale musisz umieć opisać problem i jego koszt. To Twoja część pracy. Prototyp możesz zrobić w narzędziu no-code albo zlecić. Budowę pierwszej wersji, która łączy się z innymi systemami, zwykle lepiej zlecić zespołowi, który zacznie od discovery, a nie od wyceny listy funkcji.

Co to jest MVP aplikacji?

MVP (minimum viable product) to najmniejsza wersja aplikacji, która rozwiązuje jeden prawdziwy problem i pozwala zmierzyć, czy ludzie z niej korzystają. Dla firmy to zwykle kilka ekranów połączonych z narzędziami, których zespół już używa. Celem MVP jest decyzja, co budować dalej, a nie kompletny produkt.

Ile kosztuje stworzenie aplikacji dla firmy?

To zależy od zakresu i liczby integracji, dlatego uczciwa wycena wymaga rozmowy o problemie. U nas widełki pojawiają się po pierwszej rozmowie, a stała cena przed każdym etapem. Najwięcej oszczędza wąski zakres pierwszej wersji: im mniej rzeczy aplikacja przepisuje od zera, tym taniej i szybciej powstaje.

Ile trwa stworzenie aplikacji?

Discovery zajmuje tydzień albo dwa. Pierwsza wersja zbudowana na istniejących narzędziach to kilka tygodni więcej. W naszym procesie diagnoza trwa tydzień, prototyp na danych klienta drugi tydzień, a wdrożenie tygodnie od trzeciego do szóstego. Większe systemy budowane w całości trwają znacznie dłużej.

Aplikacja mobilna czy webowa na początek?

Dla większości firm na start lepsza jest aplikacja webowa, która działa w przeglądarce na telefonie i komputerze. Powstaje szybciej, nie wymaga publikacji w sklepach i łatwiej ją zmieniać po pierwszych tygodniach. Aplikację mobilną warto rozważyć, gdy użytkownicy potrzebują aparatu, powiadomień albo pracy bez internetu.

Czy aplikacja dla firmy musi korzystać z AI?

Nie. Aplikacja ma rozwiązywać problem, a AI jest jednym z narzędzi. Portal dla klientów, rezerwacje, narzędzie wewnętrzne czy połączenie kilku systemów często działa świetnie bez AI. Sztuczną inteligencję dodaje się tam, gdzie realnie skraca pracę, na przykład przy wyciąganiu danych z maili, i od razu liczy jej miesięczny koszt.