Kiedy pomysł nie nadaje się na aplikację?

Pięć sygnałów, że pomysł nie jest aplikacją

Poniższe kryteria to wnioski redakcji, nie wynik badania — filtr wstępny, który zajmuje kwadrans zamiast kwartału. Im więcej odpowiedzi „tak”, tym większa szansa, że kod jest najdroższą z dostępnych dróg.

1. Częstotliwość użycia. Ile razy w miesiącu ta sama osoba wróci do rozwiązania? Sprawy o rytmie kwartalnym albo rocznym — rozliczenie, przegląd, rekrutacja — nie utrzymują ikony na ekranie telefonu.
2. Masa krytyczna. Czy pomysł działa przy 20 użytkownikach, czy dopiero przy 2 000? Giełdy, platformy pośredniczące i „portal dopasowań dla branży X” potrzebują dwóch stron naraz. Pusta baza w aplikacji wygląda jak awaria, pusty arkusz albo świeża grupa — nie.
3. Miejsce wartości. Jeśli klient płaci za Twoją ocenę, za dostęp, za wiedzę albo za to, że ktoś odbierze telefon, oprogramowanie jest opakowaniem, a nie produktem.
4. Przedmiot zakupu. Klient płaci za wynik (raport, dostawa, podpisana umowa) czy za narzędzie (licencja, dostęp)? Za wynik płaci od pierwszego dnia. Za narzędzie dopiero wtedy, gdy jest wyraźnie lepsze od tego, czego już używa.
5. Gotowy substytut. Czy Airtable, Notion, Formularze Google, arkusz, Calendly albo grupa na WhatsAppie zrobią 80% tego w tydzień? Jeśli tak, prawdziwym kosztem budowy nie są pieniądze, tylko miesiące bez klienta.

Rynek nie pomaga temu, kto buduje, „bo wypada mieć aplikację”. Według analiz Appfigures liczba nowych aplikacji trafiających do App Store i Google Play wzrosła w I kwartale 2026 r. o 60% rok do roku, a w kwietniu 2026 r. — licząc do 18 kwietnia — o 104% wobec tego samego okresu rok wcześniej.

Popyt nie nadąża za podażą: w 2025 r. globalna liczba pobrań wyniosła 106,9 mld, o 2,7% mniej niż rok wcześniej, choć wydatki konsumentów urosły o 21,6%, do 155,8 mld USD. Podaż rośnie szybciej niż uwaga użytkowników — nowa ikona startuje dziś z gorszej pozycji.

Objaw pomysłu, tańsza forma i moment, w którym jednak potrzebna jest aplikacja

Tabela zbiera najczęstsze zdania, z jakimi ludzie przychodzą po aplikację, oraz najtańszą formę dającą ten sam efekt. Progi w trzeciej kolumnie to nasze progi praktyczne — wnioski redakcji, nie normy branżowe. Wszystkie sytuacje są hipotetyczne.

Reguła, którą stosuje redakcja: tańsza forma odpada dopiero wtedy, gdy widać konkretną regułę biznesową, której nie da się w niej zapisać. Sam wzrost liczby wierszy takim powodem nie jest.

Ile dostajesz za 0 zł (stan na sierpień 2026)

Zanim policzysz budżet na budowę, sprawdź, gdzie kończą się plany bezpłatne. Poniższe limity pochodzą ze stron producentów, odczytane 26 sierpnia 2026 r.

Wniosek redakcji z tej tabeli jest jeden: darmowe plany rzadko pękają na ilości danych. Pękają na regułach — na tym, czego nie da się w nich wyrazić, i na współpracy większej liczby osób.

Czy wartość jest w oprogramowaniu, czy w człowieku i danych?

Aplikacja zwraca się wtedy, gdy to kod wykonuje pracę, za którą płaci klient. Jeśli pracę wykonuje człowiek, a ekran tylko zbiera dane wejściowe, kupujesz drogie opakowanie usługi.

Trzy pytania rozstrzygają to szybciej niż analiza rynku:

• Czy da się dostarczyć ten sam wynik telefonem, mailem i arkuszem? Jeśli tak, wartość siedzi w człowieku.
• Czy dane, na których stoi pomysł, należą do kogoś innego — rejestrów, dostawców, partnerów? Wtedy pierwszym zadaniem jest dostęp do danych, nie interfejs. Bez danych najlepszy ekran pokazuje pustkę.
• Czy przewagą jest relacja, licencja, ekipa albo wiedza ekspercka? Tego oprogramowanie nie skopiuje, a konkurent skopiuje ekran w tydzień.

Przykład hipotetyczny: doradca chce aplikację, która sama dobierze program dotacyjny do firmy. Praca, za którą klient płaci, to interpretacja regulaminu i przygotowanie wniosku. Formularz zbierający dane plus godzina rozmowy dają ten sam wynik, a różnicę widać dopiero, gdy wniosków jest kilkadziesiąt miesięcznie i reguły są jednoznaczne.

Klient płaci za wynik czy za narzędzie?

To pytanie rozstrzyga model biznesowy, a nie technologię. Sprzedaż wyniku zaczyna się od jednego klienta; sprzedaż narzędzia zaczyna się dopiero po zebraniu bazy płacących.

Nasze wyliczenie na hipotetycznych założeniach: narzędzie w abonamencie 49 zł miesięcznie potrzebuje 200 płacących kont, żeby dać 9 800 zł przychodu miesięcznie. Usługa rozliczana za wynik po 2 000 zł potrzebuje pięciu klientów miesięcznie, żeby dać 10 000 zł. Różnica nie kończy się na arytmetyce: 200 kont trzeba zdobyć, wdrożyć, obsłużyć i co miesiąc odbudowywać po rezygnacjach.

Jest jeszcze argument, który przeważa w praktyce. Sprzedaż wyniku daje dowód, że ktoś płaci za rozwiązanie problemu. To jedyny materiał, na którym da się oprzeć decyzję o budowie — deklaracje z ankiet nie mają tej mocy.

Test 30 dni bez kodu: obsłuż pierwszych klientów ręcznie

W 30 dni da się sprawdzić prawie wszystko, co miałaby zweryfikować pierwsza wersja aplikacji, bez pisania linijki kodu. Plan poniżej jest wnioskiem redakcji, a liczby oznaczone jako progi praktyczne to nasze założenia robocze.

1. Dni 1–7: zbierz zgłoszenia. Jedna strona z opisem oferty, Formularz Google jako wejście, obsługa osobista każdego zgłoszenia. Od pierwszego dnia notuj czas pracy nad każdym zleceniem.
2. Dni 8–14: weź pieniądze. Link płatniczy, przelew, faktura — obojętne. Bez płatności test nie mierzy niczego poza uprzejmością rozmówców.
3. Dni 15–21: powtórz bez improwizacji. Ta sama ścieżka, ten sam formularz, ta sama treść odpowiedzi. To, co powtarzasz identycznie dziesięć razy, jest kandydatem do automatyzacji.
4. Dni 22–30: policz i rozdziel. Wypisz kroki zajmujące najwięcej minut i zaznacz, które są mechaniczne (przepisywanie, kopiowanie, wysyłka), a które decyzyjne (ocena, negocjacja, wyjątek).

Jeśli po 30 dniach nie ma pięciu płatności, aplikacja tego nie naprawi — problem leży w ofercie albo w dotarciu, a jedno i drugie kosztuje mniej niż budowa. Jeśli płatności są, ale czas obsługi trzyma się poniżej 20 minut, kod nadal poczeka: taniej dołożyć drugą osobę niż utrzymywać oprogramowanie.

Kiedy aplikacja naprawdę ma sens

Aplikacja wygrywa tam, gdzie ręczna obsługa albo gotowe narzędzie zaczynają kosztować więcej niż kod. W praktyce sprowadza się to do pięciu sytuacji: codzienny rytm użycia, praca offline i w terenie, powiadomienia będące rdzeniem usługi, reguły i role, których arkusz nie utrzyma, oraz dane, których nie wolno rozsyłać mailem.

Do rachunku dolicz wejście do sklepów, bo ustawia ono minimalny czas premiery. Rejestracja konta dewelopera w Google Play to jednorazowe 25 USD, a konta osobiste założone po 13 listopada 2023 r. muszą przed publikacją przeprowadzić test zamknięty z minimum 12 testerami zapisanymi nieprzerwanie przez 14 dni. Apple Developer Program kosztuje 99 USD rocznie. Same kwoty są niewielkie — istotne jest to, że pierwsza publikacja aplikacji na Androida z nowego konta osobistego wymaga dwóch tygodni testów, zanim ktokolwiek ją pobierze.

Wniosek redakcji: kolejność „najpierw ręcznie, potem narzędzie z półki, na końcu kod” nie jest oszczędzaniem. To sposób na to, żeby budować dokładnie te reguły, które ktoś już opłacił.