Jak zbudowałbym MVP i jak właściwie wybieram stos

Gdybyście jutro poprosili mnie o zbudowanie MVP, nie otworzyłbym porównania 40 frameworków. Nie rysowałbym mapy mikrousług. Nie „zabezpieczałbym przyszłości” produktu, który nigdy nie spotkał płacącego użytkownika. Zapisałbym jedno zdanie: dla kogo to jest, jaką pełni funkcję i co zmierzymy za cztery tygodnie. Stos pojawia się po tym zdaniu, a nie przed.

Większość nieudanych MVP nie jest zbyt mała. Są fałszywe: na wpół zbudowana „platforma” z uwierzytelnianiem, pulpitami nawigacyjnymi, powiadomieniami i trzema środowiskami – i wciąż nikt nie wykonuje jedynego zadania, które potwierdzałoby ten pomysł. Technologia jest zwykle alibi. W tym artykule opisano, w jaki sposób faktycznie wysyłałbym przesyłki.

1. Kim jest MVP i czego nie chcę nim nazywać

MVP nie jest „wersją 1 z mniejszą liczbą ekranów”. To najtańszy eksperyment, który może zabić lub wzmocnić najbardziej ryzykowne założenie. Jeśli założymy, że „ludzie zapłacą za rezerwację tej usługi online”, MVP to proces rezerwacji, płatność i człowiek po drugiej stronie, a nie CRM, program lojalnościowy czy aplikacja natywna.

• Opłacalne oznacza, że ​​prawdziwy użytkownik może dokończyć prawdziwą pracę. Klikalny prototyp Figma to badania, a nie MVP.
• Minimum oznacza, że ​​wszystko, co nie służy temu zadaniu, zostanie odłożone na później – nawet jeśli wygląda na „łatwe do dodania”.
• Produkt oznacza, że ​​możesz powtórzyć to w przyszłym tygodniu bez heroizmu. Formularz Google i arkusz kalkulacyjny mogą być MVP. Nie można napisać na nowo architektury Netflixa.

2. Pięć pytań, zanim powstanie jakiekolwiek repozytorium

Argumenty stosu są tanie. Pytania dotyczące produktu bez odpowiedzi są drogie. Nie wybieram Postgres kontra Mongo, dopóki nie odpowiem na nie głośno – z założycielem, a nie z postem na blogu.

• Kto jest pierwszą dziesiątką użytkowników, jeśli to możliwe, z nazwiskami – nie „każdy z telefonem”.
• Jakie jest jedno zadanie, do którego zatrudniają ten produkt w tym miesiącu? Jeden. Nie platforma.
• Skąd pochodzą pieniądze lub sygnał – obciążenie karty, podpisana umowa, zarezerwowany slot, kwalifikowany lead?
• Jakie ograniczenie jest rzeczywiste: cztery tygodnie, jeden programista, domena regulowana, istniejąca CRM, Telegram odbiorców?
• Co by nas zatrzymało? Jeśli nie możemy podać kryterium zabicia, budujemy hobby, a nie eksperyment.

3. Pięć filtrów, których używam do wyboru technologii

Nie wybieram narzędzi dlatego, że są modne. Wybieram je, bo wytrzymują kontakt z solowym deweloperem, mały budżet i pierwszego wściekłego użytkownika. Każda technologia musi przejść przez te filtry.

• Czas na pierwszego prawdziwego użytkownika. Jeśli do stosu dodany zostanie tydzień, zanim ktokolwiek będzie mógł kliknąć, jest to niewłaściwy stos dla MVP. Nudne narzędzia, które już wysyłam do produkcji, są lepsze niż modne, których chciałbym się nauczyć w terminie.
• Możliwość obsługi przez jedną osobę. Powinienem być w stanie wdrożyć, odczytać dzienniki, przywrócić kopię zapasową i obrócić klucz bez zespołu zajmującego się platformą. Kubernetes nie przechodzi tego testu w przypadku prawie każdego wczesnego produktu.
• Możliwość wynajmu i wymiany. TypeScript, Postgres i React nie są ekscytujące. Są to języki, którymi posługują się już inni dobrzy ludzie. MVP, którego tylko ja mogę przedłużyć, jest zakładnikiem, a nie aktywem.
• Waga danych. Umieść źródło prawdy w prawdziwej bazie danych z migracjami od pierwszego dnia, jeśli produkt ma użytkowników i pieniądze. Arkusze kalkulacyjne nadają się do eksperymentów obok produktu, a nie wewnątrz kasy.
• Właz ewakuacyjny. Będę korzystać z zarządzanego uwierzytelniania, hostowanego Postgresa i dostawcy płatności. Nie podpiszę pięcioletniego zawieszenia, które utrudnia eksport. Sprzedawca w porządku. Pułapka nie.

4. Domyślny stos internetowy, od którego zacznę w 2026 roku

W przypadku typowego MVP B2B lub usługi – rezerwacja, pozyskiwanie leadów, mały portal klienta, kalkulator zamieniający się w wycenę – zacząłbym od tego. Nie dlatego, że jest to modne. Ponieważ mogę to wysłać, SEO i nadal móc zatrudnić kogoś innego za sześć miesięcy.

• Next.js + TypeScript + Tailwind: jedna aplikacja dla stron marketingowych (SEO, renderowanie serwera) i interfejsu produktu. Mniej repozytoriów, jedno wdrożenie, typy współdzielone. App Router jest w porządku, jeśli zespół już o tym wie; Nie będę przepisywać działającej aplikacji Pages „dla czystości”.
• Postgres (często przez Supabase, Neon lub mały VPS): dane relacyjne, transakcje i SQL Mogę sprawdzać o 2 w nocy. Sięgam po magazyn dokumentów tylko wtedy, gdy kształt rzeczywiście przypomina dokument - nie dlatego, że „NoSQL jest szybszy”.
• Auth: zarządzany dostawca (Clerk, Auth.js + znany dostawca tożsamości lub Supabase Auth), chyba że produkt jest autoryzowany. Ciągłe sesje niestandardowe w pierwszym tygodniu polegają na wycieku tokenów i blokowaniu rzeczywistej funkcji.
• Płatności: Stripe (lub lokalna równowartość, z której faktycznie korzystają pierwsi użytkownicy). Brak domowego mechanizmu rozliczeniowego. Faktury mogą poczekać; opłata robocza nie może.
• Hosting: Vercel dla aplikacji Next.js, jeśli ruch ma charakter internetowy, a zespół chce podglądów; a Hetzner/VPS + Docker Utwórz, jeśli potrzebujemy długotrwałego pracownika, przewidywalnych kosztów lub miejsca na dane. O tym kompromisie pisałem osobno – zasada MVP brzmi: jedno środowisko, które rozumiesz, nocne kopie zapasowe, HTTPS i domena.
• E-mail i pliki: Wyślij ponownie lub podobną transakcję API; Pamięć kompatybilna z S3. Nie „zbudujemy moduł załączników”.

5. Kiedy wyrzucę domyślny

Domyślnym zakładem jest zakład początkowy, a nie religia. Zmieniam to, gdy ograniczeniem jest iloczyn.

• Publiczność żyje już w Telegram: bot lub Mini App może być całym MVP. Strona internetowa, której nie otworzą, nie jest „bardziej profesjonalna”. To drugi pusty pokój.
• Zadanie jest w terenie ze złym sygnałem: biorę pod uwagę ścieżkę lokalną lub PWA, a nie natywną przeróbkę w pierwszym tygodniu. Natywny to decyzja dotycząca dystrybucji, a nie odznaka.
• Rdzeniem jest język (wsparcie, cytowanie, wyodrębnianie dokumentów): dodaję LLM API za ścisłym schematem i etapem przeglądu przez człowieka. Nie owijam widżetu czatu i nie nazywam go produktem.
• Założyciel jest operatorem, a treść jest produktem: szybka witryna plus CMS, z którego faktycznie będą korzystać, może pokonać niestandardowego administratora. Wartość WordPress jest nadal dozwolona, ​​jeśli publikuje się ofertę pracy, a nie aplikację.
• Rynek dwustronny: nadal wysyłam najpierw jedną stronę. Podaż czy popyt – w zależności od tego, co jest trudniejsze do osiągnięcia. „Platforma” z pustymi miejscami po obu stronach to strona docelowa z dodatkowymi stolikami.

6. Czego nie dodam przed pierwszymi użytkownikami

Najszybszym sposobem na ominięcie eksperymentu jest zbudowanie firmy wokół eksperymentu. To jest lista, którą trzymam obok zaległości.

• Mikrousługi, magistrala komunikatów i Kubernetes. Jeden proces, jedna baza danych, jedno wdrożenie. Podziel, gdy pojawi się prawdziwe wąskie gardło lub prawdziwa granica zespołu, a nie wtedy, gdy diagram wygląda na starszy.
• System projektowania z 80 tokenami i bez ekranów. Wyślij trzy ekrany, które zbierają pieniądze. Wyodrębnij komponenty, gdy trzecie kopiowanie i wklejanie boli.
• Role, uprawnienia, dzienniki audytu i logowanie jednokrotne – chyba że płacący kupujący B2B zablokował transakcję na nich. W takim razie są MVP, a nie zadaniem pobocznym.
• Druga aplikacja mobilna. Responsywna sieć lub mini aplikacja obejmuje pierwszych stu użytkowników w większości firm usługowych, jakie widzę.
• Doskonałe pokrycie testowe kodu kleju. Chcę testów dotyczących pieniędzy, uwierzytelnienia i podstawowej pracy. Nie chcę tygodnia drwin z formularza do lądowania.

7. Jak faktycznie będą wyglądać pierwsze cztery tygodnie

Kalendarz traktuję jako decyzję produktową. Jeśli nie potrafimy opisać tygodni, nie mamy planu – mamy życzenie.

• Tydzień 0 (dwa dni, a nie dwa tygodnie): napisz jednostronicowy artykuł. Użytkownik, praca, kryterium zabicia, inne niż cele. Naszkicuj trzy ekrany. Zgadzam się, co oznacza „gotowe”: nieznajomy może wykonać zadanie bez telefonu z naszej strony przez Zoom.
• Tydzień 1: plasterek pionowy. Domena, wdrożenie, baza danych, pusty układ, jedna szczęśliwa ścieżka w produkcji (nawet jeśli jest brzydka). Jeśli nie uda nam się wdrożyć trzeciego dnia, stos już leży.
• Tydzień 2: praca. Rezerwacja, wycena, przesyłanie, płatność – cokolwiek nazwaliśmy w tygodniu 0. Dozwolone są ręczne operacje za interfejsem użytkownika: ping Telegram do właściciela jest funkcją, jeśli zamyka pętlę.
• Tydzień 3: brzydkie krawędzie. Puste stany, błędy, telefon komórkowy, e-maile, podstawowe statystyki (gdzie spadły). Nie hurtownia danych. Lejek, który możesz przeczytać.
• Tydzień 4: przedstaw to dziesięciu wymienionym osobom. Oglądać. Nie dodawaj funkcji podczas połączeń. Zapisz, co zrobili, zamiast tego, co twierdzili, że chcą.

8. Po uruchomieniu: zachowaj, wyodrębnij lub napisz ponownie

Dobry MVP może być nieco zawstydzający. Nie wolno być pułapką. Powyższy stos jest celowo nudny: można do niego dorosnąć. Rzadko trzeba z tego wyrastać w pierwszym roku.

• Zachowaj: język, bazę danych, nazwy domen w kodzie. Są tanie w utrzymaniu i drogie w wyrzuceniu.
• Wyciąg: pracownik, druga usługa, prawdziwa kolejka – gdy praca jest powolna, niebezpieczna lub należy do innego zespołu. Dopiero gdy.
• Przepisz tylko tę część, która nauczyła się niewłaściwej lekcji. Jeśli kasa jest błędna, przepisz kasę. Jeśli cała aplikacja jest labiryntem zakodowanym wibracją, jest to przede wszystkim problem ludzi: ktoś musi być w stanie to wyjaśnić o 2 w nocy.

Wniosek: wybierz stos, który przetrwa pierwszą nie

Stworzyłbym MVP w mało efektowny sposób: jedno zadanie, jedna baza danych, jedno wdrożenie, narzędzia, którymi mogę operować samodzielnie, i data, kiedy zdecydujemy się kontynuować lub zakończyć. „Najlepsza” technologia to taka, która nie odrywa nas od tej decyzji. Next.js, TypeScript, Postgres, zarządzana autoryzacja i dostawca płatności nie są osobowością. Są sposobem na spędzenie nielicznych tygodni na produkcie zamiast na platformie.

Jeśli masz pomysł, termin i obawiasz się wybrania „złego” stosu - napisz przez dział kontaktów. Możemy określić zakres jednego zadania, nazwać cele inne niż cele i wysłać fragment, który możesz zaprezentować prawdziwym ludziom, bez konieczności budowania najpierw fałszywej platformy.