Kiedy zaprosić drugą osobę do pomocy w utrzymaniu aplikacji zbudowanej z AI

Większość aplikacji zbudowanych za pomocą kreatora aplikacji z AI zaczyna jako projekt jednej osoby. Miałeś pomysł w sobotni poranek, opisałeś go kreatorowi, do sobotniego wieczoru miałeś coś, co działało, a do następnego weekendu miałeś prawdziwych ludzi, którzy tego używali. Przez jakiś czas możesz prowadzić całość sam — odpowiadając na wiadomości, poprawiając tę jedną literówkę na stronie głównej, dodając nową funkcję, o którą wciąż prosi użytkownik, oglądając analitykę na telefonie w kawiarni.

Potem pewnego dnia zauważasz, że właściwie nie zbudowałeś nic nowego od trzech tygodni. Każda wolna godzina idzie na utrzymanie. „Drobne poprawki” nigdy się nie kończą. Odpowiadasz na to samo pytanie od nowych użytkowników po raz piętnasty. Zaczynasz bać się otwierania aplikacji, co jest najgorszym uczuciem, jakie budujący może mieć wobec czegoś, co stworzył.

To moment, by pomyśleć o zaproszeniu drugiej osoby. Nie współzałożyciela, nie pracownika, nie wykonawcy do dużej przebudowy — po prostu jednej osoby więcej, która może pomóc nieść tę rzecz.

Ten wpis jest o tym, jak rozpoznać, że doszedłeś do tego momentu, kto jest właściwą pierwszą osobą do zaproszenia i jak przekazać jej kawałek aplikacji zbudowanej z AI bez oddawania kontroli nad całością.

Znaki, że nadszedł czas

Poznasz, że nadszedł czas, gdy możesz odpowiedzieć tak na większość z tych:

Mówisz nie zmianom, które chciałbyś wprowadzić. Nie dlatego, że to złe pomysły — dlatego, że nie masz godzin. Zacząłeś prywatną listę „rzeczy, które bym zrobił, gdybym miał czas” i wciąż się wydłuża.
To samo pytanie użytkownika wciąż wraca. Odpowiedziałeś „jak wyeksportować moje dane?” osiem razy w dwa tygodnie. To strona pomocy, ale nie masz czasu jej napisać, więc wciąż odpowiadasz ręcznie.
Unikasz aplikacji. Konkretny jej zakątek wydaje się ciężki. Może sekcja administratora, może ekran rozliczeń — coś, gdzie każda zmiana wydaje się operacją. Pozwalasz błędom tam starzeć się dłużej, niż powinieneś.
Jeden błąd by zabolał. Twoja aplikacja ma teraz prawdziwych użytkowników z prawdziwymi danymi. Pojedyncze złe wdrożenie w zmęczony wtorkowy wieczór mogłoby zgubić czyjąś pracę. Nie masz drugiej pary oczu.
Jesteś wąskim gardłem wzrostu. Trzech potencjalnych klientów poprosiło o małą zmianę, zanim by się zarejestrowali. Dwa miesiące temu zbudowałbyś ją tego wieczoru. Teraz nie możesz nawet odpowiedzieć przez trzy dni.

Jeśli dwa z tych są prawdziwe, może być w porządku. Jeśli cztery z nich są prawdziwe, byłeś wąskim gardłem dłużej, niż sobie zdajesz sprawę.

Kogo zaprosić najpierw

Instynkt to znaleźć kogoś „bardziej technicznego niż Ty”. To zwykle błąd. Pierwsza osoba do zaproszenia to nie ta, która umie pisać kod. To osoba, która już przejmuje się Twoją aplikacją.

Szukaj mniej więcej w tej kolejności:

Użytkownik, który wciąż coś sugeruje. Prawdopodobnie masz takiego. Przysłał Ci cztery pomysły na funkcje, dwa zgłoszenia błędów i uprzejmą skargę na sformułowanie na ekranie rejestracji. Chce, żeby ten produkt był dobry. Zwraca uwagę. Jeśli zapytasz go, czy chciałby pomóc ukształtować jeden jego zakątek, odpowiedź często brzmi tak.

Znajomy, który obserwował z boku. Ktoś, kto słuchał, jak mówisz o aplikacji od miesięcy, i jest ciekaw. Nie musi umieć pisać kodu — Twój kreator aplikacji z AI to robi. Musi umieć jasno opisać, czego chce, co większość ludzi, którzy obserwowali Twoje zmagania przez jakiś czas, potrafi lepiej, niż im się wydaje.

Ktoś w Twojej społeczności. Jeśli Twoja aplikacja obsługuje nauczycieli, znajdź nauczyciela. Jeśli obsługuje fotografów ślubnych, znajdź fotografa ślubnego. Wiedza dziedzinowa jest warta więcej niż umiejętności techniczne, bo kreator aplikacji z AI może uzupełnić umiejętności techniczne, ale nie może uzupełnić „czego fotografowie ślubni naprawdę potrzebują w sobotę w lipcu”.

Prawdziwy przykład, lekko zamaskowany. Ktoś, kogo znamy, zbudował mały marketplace dla ręcznie robionej ceramiki za pomocą kreatora aplikacji z AI. Po sześciu miesiącach tonęła — odpowiadając na wiadomości od sprzedawców, poprawiając ten sam tekst kasy trzy razy, budując funkcje dla kupujących, których nie spotkała. Zaprosiła jedną ze swoich sprzedawczyń, kobietę, która już napisała do niej z jedenastoma sugestiami w ciągu roku. W ciągu dwóch miesięcy ta sprzedawczyni przepisała większość stron skierowanych do sprzedawców, głosem, którego żaden ktoś z zewnątrz nie mógłby skopiować. Founderka dalej budowała dla kupujących. Aplikacja nie zwolniła; niemal podwoiła tempo.

Najgorszym pierwszym zaproszeniem jest zwykle generyczny wykonawca techniczny. Wykona dobrą pracę, ale nie będzie się przejmował, a pierwsza osoba, którą zaprosisz, musi się przejmować, bo będzie podejmować mnóstwo małych decyzji bez Ciebie.

Jaki kawałek im przekazać

Błędem jest przekazanie im całej aplikacji. Cała aplikacja jest w Twojej głowie. Wiesz, które części są kruche, których nigdy do końca nie skończyłeś, które części użytkownik kiedyś prawie zepsuł. Oni nie.

Przekaż im kawałek. Prawdziwy, z krawędziami:

Stronę główną i strony marketingowe. Niskie ryzyko, wysoka widoczność. Mogą iterować na tekście, sekcjach, zrzutach ekranu, opiniach. Jeśli coś zepsują, zauważysz w ciągu godziny i żaden użytkownik nie traci danych.
Centrum pomocy. Jeśli wciąż odpowiadasz na te same pytania, to jest ten kawałek. Oni piszą odpowiedzi; Ty przeglądasz pierwsze kilka, aż zaufasz głosowi; potem wypuszczają.
Jedną konkretną funkcję skierowaną do użytkowników. Może to przepływ eksportu, system komentarzy albo powiadomienia. Coś z czystą granicą, gdzie błąd w tym nie kładzie całej aplikacji.
Narzędzia administracyjne, których sam używasz. Zaskakująco dobry startowy kawałek. Mogą ulepszyć narzędzia, których używasz, nie dotykając niczego, co widzą klienci. Czujesz ulepszenia codziennie, co buduje zaufanie.

Kształt kawałka ma mniejsze znaczenie niż fakt, że to kawałek. Oni są jego właścicielami. Ty nie kwestionujesz każdej zmiany. Uzgadniacie rytm spotkań i pozwalasz im pracować.

Czego nie robić pierwszego dnia

Krótka lista, głównie z obserwowania innych robiących to źle:

Nie dawaj im dostępu do swojej działającej bazy danych. Większość kreatorów aplikacji z AI pozwala zrobić kopię staging Twojej aplikacji. Zacznij ich tam. Dzień, w którym wypuszczą swoją pierwszą rzecz na produkcję, powinien być małą ceremonią, nie wypadkiem.
Nie zrzucaj wszystkiego na ich barki. „Oto dokument w Notion z 87 rzeczami, wybierz cokolwiek”. To przytłaczające i zrezygnują. Wybierzcie razem pierwsze trzy rzeczy. Skończcie te. Potem wybierzcie kolejne trzy.
Nie oczekuj, że będą czytać Ci w myślach. Żyjesz z tą aplikacją od miesięcy. Masz skrót dla wszystkiego. Zapisz pięć rzeczy o tym, jak działa aplikacja i jak podejmujesz wobec niej decyzje. Przekaż im to. Zajmie Ci to dziewięćdziesiąt minut i zaoszczędzi tygodnie.
Nie znikaj. Potrzebują Cię przez pierwsze kilka tygodni. Ustaw prawdziwy rytm — szybką rozmowę raz w tygodniu, wiadomości asynchroniczne pomiędzy. Po miesiącu prawdopodobnie możesz zejść do co drugi tydzień. Nie wcześniej.

Jak to faktycznie się czuje potem

Większość solo budujących jest zaskoczona, gdy po raz pierwszy zaproszą kogoś, jak dużo energii odzyskują. Nie dlatego, że ta druga osoba jest szybka — prawdopodobnie nie jest, na początku — ale dlatego, że połowa Twojego zmartwienia dotyczyła rzeczy, do których nie dochodziłeś. Gdy ktoś inny do nich dochodzi, zmartwienie się przesuwa.

Zauważysz też, że Twoja aplikacja zaczyna wydawać się mniej krucha. Dwie osoby rozumiejące system są więcej niż dwa razy bardziej odporne niż jedna. Współczynnik autobusu idzie z jednego do dwóch, co brzmi jak mała rzecz, dopóki nie nadejdzie tydzień, gdy Twój laptop padnie, a ktoś inny wciąż może wypuszczać.

Jeśli siedzisz z długą listą „rzeczy, które bym zrobił, gdybym miał czas”, może warto poświęcić dziś godzinę na pomyślenie, kto mógłby być tą pierwszą osobą i jaki kawałek swojej aplikacji zbudowanej z AI byś jej przekazał.

To zwykle mniejszy skok, niż wygląda.