Własny ból czy luka na rynku — skąd biorą się aplikacje, które firmy z branży naprawdę kupują?

Skąd biorą się aplikacje, za które firmy z branży płacą

Trzy na cztery pomysły zaczynają się od problemu, który założyciel obsługiwał sam. W ponad 300 rozmowach o pomysłach na aplikację, które prowadziliśmy między czerwcem a wrześniem 2026 (ręczna klasyfikacja opisów pomysłu, stan 16.09.2026), 3 na 4 pomysły zaczynają się od własnego, powtarzalnego problemu w firmie, 1 na 4 — od zauważonej luki na rynku.

To nie jest różnica stylu, tylko różnica materiału. Własny ból daje dane, których nie da się kupić: liczbę przebiegów, wyjątki, słownik branży i koszt dzisiejszego sposobu pracy. Luka na rynku daje na starcie jedno zdanie.

Pięć firm, które dziś sprzedają oprogramowanie własnej branży, ma w publicznych źródłach tę samą kolejność: najpierw firma i jej problem, potem narzędzie, na końcu produkt dla innych.

Trzy rzeczy w tej tabeli są ważniejsze niż nazwy firm.

Pierwszy użytkownik jest jeden i ma nazwisko. W Archdesku była to firma wspólnika: podwykonawca od schodów i balustrad, który w 2011 roku prowadził 25 projektów jednocześnie. Nie „rynek budowlany”, tylko jedna firma, której proces dało się rozłożyć na części.

Narzędzie dla siebie nie jest jeszcze produktem. Inne firmy pytały o oprogramowanie Archdesku wcześniej, ale sprzedać się go nie dało: było zrobione pod jeden proces produkcyjny, a u każdego podwykonawcy ten proces wygląda trochę inaczej.

Decyzję, czy pierwszą wersję budować od razu dla wielu firm, rozstrzygamy osobno: najpierw dla siebie czy od razu dla branży.

Praktykiem nie musi być osoba pisząca kod — ale musi być w projekcie. Założyciele ServiceTitana byli inżynierami; praktykami byli ich ojcowie, właściciele firm usług technicznych. Spółka zaczęła od obsługi jednej branży — hydrauliki — a nie całego rynku usług w budynkach.

Jedno zastrzeżenie do tabeli: strona Berg Systemu opisuje drogę zawodową współzałożyciela, a nie pojedynczy moment „napisałem to dla siebie”. Bierzemy z niej wyłącznie to, co jest udokumentowane — system powstał z wnętrza branży, którą obsługuje.

Własny ból czy luka na rynku — co jest czym

Jeden na cztery pomysły zaczyna się od luki, a luka bywa dwóch rodzajów. Widziana z zewnątrz to brak produktu w kategorii: informacja o katalogu, nie o gotowości do zapłaty. Widziana z warsztatu to konkretna czynność, którą firmy wokół robią ręcznie i którą umiesz wycenić w godzinach.

Różnicę sprawdza się bez badania rynku. Wystarczy, że każdemu sygnałowi przypiszesz liczbę i osobę.

Najgorszy wariant to luka, która jest cmentarzem: ktoś już próbował, branża odbiła to od siebie, a powód nadal obowiązuje. Zanim uznasz brak konkurencji za dobrą wiadomość, sprawdź, czy konkurencja to dowód rynku, czy wyrok na mój pomysł.

Które branże są już obsadzone, liczy serwis siostrzany: w których branżach nie ma już miejsca na kolejną aplikację. Czy firmy zapłacą akurat za Twój problem, rozstrzyga test pięciu pytań.

Wzorzec w pięciu krokach — i czym praktyk różni się od osoby z zewnątrz

Wzorzec jest ten sam w pięciu historiach z tabeli i ma pięć kroków. Przy każdym praktyk startuje z innego miejsca niż osoba wchodząca do branży z zewnątrz — i na tym polega cała przewaga, o którą tu chodzi.

1. Problem, który obsługujesz sam. Policz przebiegi z ostatnich dwunastu miesięcy i wypisz wyjątki. Praktyk zna wyjątki, bo je odkręcał; osoba z zewnątrz zna wersję z prezentacji, w której wszystko idzie zgodnie ze schematem.
2. Narzędzie dla własnej firmy. Pierwszym użytkownikiem jesteś Ty, a poligonem są Twoje prawdziwe zlecenia i terminy. Osoba z zewnątrz musi ten poligon kupić: znaleźć firmę, przekonać ją do pilota, dopiero potem zobaczyć, jak wygląda praca.
3. Pierwsze pytania z branży. „Jak ty to robisz?” pada w hurtowni, na szkoleniu, w grupie branżowej. Zapisuj, kto pytał i kiedy — z tego powstaje lista pierwszych partnerów, a nie z kupionej bazy kontaktów.
4. Przepisanie na wiele firm. To, co u Ciebie jest regułą, u sąsiada jest parametrem. Ten krok kosztuje: w Archdesku był to rok pracy nad nowym systemem, mimo pięciu lat szlifowania poprzedniego.
5. Zobowiązanie zamiast deklaracji. Pierwsze firmy płacą za dostęp albo wchodzą w płatny pilot; „chętnie bym używał” nie jest sygnałem. Praktyk ma z kim o tym rozmawiać od ręki, osoba z zewnątrz musi tę rozmowę najpierw kupić.

Do tego jeden próg, zanim w ogóle nazwiemy coś procesem: 50 przebiegów rocznie w Twojej firmie, czyli mniej więcej raz w tygodniu.

Dlaczego akurat tyle? Wyjątki wychodzą rzadko — co dziesiąty, co dwudziesty przebieg. Przy pięćdziesięciu zobaczysz kilka i będziesz je pamiętał, gdy przyjdzie opisać zakres. Przy pięciu w roku opiszesz proces z pamięci, a wyjątki wypłyną dopiero w gotowej aplikacji, jako zmiany zakresu.

To jest najdroższy moment, w jakim mogą się pojawić: zmiana po akceptacji ekranów ciągnie za sobą bazę i uprawnienia. Jak spisać zakres, żeby tego uniknąć, opisaliśmy w tekście o zakresie pierwszej wersji.

Czym jeszcze dysponuje praktyk, zanim powstanie pierwsza linia kodu, rozkładamy w tekście o tym, dlaczego masz już większość aplikacji, której jeszcze nie ma.

Konkurent jako partner: dlaczego narzędzie zbudowane dla siebie sprzedaje się w branży najłatwiej

Firma z branży kupuje dowód, nie prezentację, a najmocniejszy dowód brzmi: „działa u mnie od trzech lat i obsługuje dokładnie to, co robisz Ty”. Narzędzie zbudowane najpierw dla siebie ma historię eksploatacji w firmie takiej jak jego — produkt zaprojektowany pod rynek ma slajdy.

Konkurenci pracujący w jednym narzędziu to w B2B norma. Platforma założona przez prezesa spedycji miała w 2017 roku 35 tys. firm abonenckich z całej Europy, a spółka założona przez synów właścicieli firm usług technicznych — ok. 8 000 klientów rozliczających powyżej 10 tys. USD rocznie (stan na 31 stycznia 2024).

Na własnej stronie ta sama spółka podaje ponad 11 800 klientów z branż technicznych (odczyt 16 września 2026). Między prospektem a dzisiejszą stroną minęły prawie trzy lata — takim tempem rośnie narzędzie, które branża uznała za swoje.

W rozmowie z konkurentem wracają cztery obawy. Na każdą jest konkretna odpowiedź i konkretny zapis w umowie:

• „Zobaczysz moje ceny i moich klientów”. Dane rozdzielone per firma na poziomie bazy, administrator bez cichego wglądu, dziennik dostępu. To decyzja architektoniczna z pierwszego dnia, nie ustawienie — zasady obowiązujące od początku znaczą tu więcej niż zapewnienia.
• „Uzależnię się od konkurenta”. Eksport własnych danych w czytelnym formacie na żądanie, termin wypowiedzenia, opisane skutki zakończenia współpracy. Partner, który wie, jak wyjdzie, łatwiej wchodzi.
• „Dostanę gorszą wersję niż Ty”. Jedna wersja dla wszystkich, różnice wyłącznie w parametrach procesu. Twoja firma pracuje na tym samym kodzie co partner i można to sprawdzić.
• „Cena wzrośnie, gdy będę zależny”. Zasady zmiany ceny zapisane z góry: co ją zmienia, z jakim wyprzedzeniem i czego nie zmieniasz w trakcie opłaconego okresu.

Czego nie obiecywać: że do aplikacji nigdy nie wejdzie firma z jego miasta. Wyłączność brzmi dobrze przy pierwszym podpisie i blokuje cały pomysł przy dziesiątym.

Jest też korzyść, której konkurent nie kupi nigdzie indziej: aplikacja zbudowana przez praktyka mówi jego językiem. Wdrożenie nie zaczyna się od tłumaczenia, czym jest zlecenie, etap i poprawka w tej konkretnej branży.

Co zostaje po Twojej stronie, a co robi zespół, który buduje

Podział wynika wprost z tego, skąd pochodzi pomysł. Wiedza o problemie, wyjątkach i ludziach jest nieprzenośna — zespół techniczny jej nie odtworzy z dokumentacji. Architektura, kod, dane i pieniądze w aplikacji są przenośne i za nie odpowiada zespół w całości.

Zamiana ról kosztuje najwięcej tam, gdzie na początku nic nie widać. Praktyk, który zaczyna decydować o technice, płaci za to zwykle przebudową; zespół, który sam domyśla się procesu branży, buduje aplikację zgodną z opisem i nieprzydatną w pracy.

Kolejność prac i to, kto co akceptuje na każdym kroku, opisaliśmy w tekście o budowie krok po kroku. Gdzie kończy się droga „zrobię to sam narzędziami AI”, pokazujemy w tekście o granicach vibe-codingu.

Rachunek, w którym narzędzie dla jednej firmy zderza się z produktem dla całej branży, prowadzi serwis siostrzany: zbudować narzędzie dla siebie czy produkt dla całej branży.