Pomysł — banalna sytuacja w garażu

Sierpień 2025. Sprzątam szufladę w garażu, w której od lat zalegają stare telefony. Trzy sztuki. Wszystkie sprawne, wszystkie z Androidem, wszystkie z gniazdami SIM, GPS-em, mikrofonami i akcelerometrami.

I ta jedna myśl: „Ten Samsung A20 ma więcej mocy obliczeniowej niż laptopy, na których pisałem doktorat. A leży tu od 3 lat".

Druga myśl: „Mam też auto, które stoi pod blokiem. Bez alarmu, bez monitoringu, bez niczego. Bo dedykowany tracker GPS kosztuje 300-500 zł i wymaga abonamentu".

Trzecia myśl: „Zaraz, czemu by tych dwóch rzeczy nie połączyć?"

To wszystko. Cała geneza LocaCar. Bez głębokich analiz rynku, bez badania konkurencji, bez biznesplanu. Pomysł zrodzony przy szufladzie, w piątkowe popołudnie.

Następnego dnia (sobota) usiadłem do laptopa i zacząłem prototyp.

Pierwszy POC — weekend i HTML w przeglądarce

Pierwsza wersja LocaCar nie była aplikacją. Była stroną HTML.

Konkretnie: prosty plik index.html otwarty w przeglądarce starego Samsunga. Korzystający z natywnego API geolokalizacji (navigator.geolocation) i wysyłający koordynaty co 30 sekund na mój domowy serwer (Symfony, który już miałem postawiony pod inny projekt).

Działało. W garażu, na podjeździe, w drodze do sklepu. Telefon w aucie, otwarta przeglądarka, koordynaty lecą na serwer, mogę zobaczyć w czasie rzeczywistym, gdzie auto stoi.

Spędziłem 2 dni weekendu testując ten POC w realnych warunkach. Wniosek: technicznie da się. Pomysł nie jest absurdalny.

W poniedziałek wieczorem rozpisałem na kartce, czego brakuje, żeby z prototypu zrobić coś użytecznego. Lista miała 47 punktów.

Wtedy popełniłem pierwszy duży błąd.

Błąd #1 — Wybrałem React Native

Po POC stanąłem przed wyborem stosu technologicznego. Native Android (Kotlin)? Flutter? React Native? Cordova? PWA?

Wybrałem Expo / React Native. Z dwóch powodów:

  1. Znałem React z innych projektów (krzywa nauki = niska)
  2. Obietnica „write once, run on iOS too" — wydawało mi się, że dam radę zrobić jednocześnie wersję na iPhone'a

Pierwszy powód był dobry. Drugi okazał się iluzją.

Bo w trakcie budowy okazało się, że:

  • Background services na Androidzie wymagają natywnego kodu (Java/Kotlin) — nie da się wszystkiego przez React Native
  • Dostęp do akcelerometru w trybie tła to natywne moduły
  • Optymalizacja baterii? Natywne moduły
  • Push notifications z konkretnymi parametrami? Natywne moduły

Po 2 miesiącach okazało się, że 40% mojego kodu to natywny Android (Java + Kotlin), 60% to React Native. iOS — nawet nie tknięty.

Czy zmieniłbym decyzję dziś? Pewnie tak — gdybym mógł cofnąć czas, poszedłbym w czysty Native Android. Dał wymierną szybkość, znacznie mniej kombinowania z bibliotekami i dokładnie taką samą krzywą iOS-ową na później (i tak natywną).

Dlaczego zostałem przy React Native? Bo cena migracji teraz (przepisanie kodu od zera) jest wyższa niż koszt utrzymania obecnej hybrydowej architektury. Będę żyć z tym wyborem. Może rok, może dwa lata. Potem zobaczymy.

To pierwsza ważna lekcja solo-developera: nie ma idealnych decyzji. Są tylko wystarczająco dobre decyzje + cierpliwość, żeby z nimi żyć.

Najtrudniejsze 3 momenty

Moment 1: Optymalizacja baterii Androida (3 tygodnie)

Tutaj się dowiedziałem, że Android nie istnieje. Istnieje 11 różnych Androidów, w zależności od producenta telefonu i ROM-u.

Xiaomi MIUI? Aplikacja w tle żyje 30 minut, potem killowana. Trzeba w ustawieniach systemowych ręcznie odblokować autostart, ręcznie ustawić "no battery optimization", ręcznie dodać do białej listy MIUI.

Samsung One UI? Inny menedżer baterii, inna konfiguracja, inne ścieżki.

Realme/Oppo? Trzeci system optymalizacji.

Huawei? Czwarty.

Spędziłem 3 tygodnie pisząc:

  • Detektor producenta telefonu i wersji ROM
  • Wewnętrzny przewodnik konfiguracji dla każdego brand'u (z screenshotami!)
  • Mechanizm sprawdzający, czy aplikacja faktycznie działa w tle, i alert dla użytkownika, jeśli nie
  • Foreground service z persistent notification (żeby Android wiedział, że to świadomy, "ważny" proces)

Lekcja: to, co w jednym Androidzie działa za pierwszym podejściem, w innym wymaga 4 ekranów ustawień systemowych. Solo-developer mobile musi myśleć o tym jak o 11 osobnych systemach operacyjnych, nie jednym Androidzie.

Moment 2: WebSocket reconnection (2 tygodnie)

Architektura LocaCar opiera się na komunikacji w czasie rzeczywistym między telefonem-czujnikiem (w aucie) a telefonem-managerem (u właściciela). Wybrałem Socket.IO + Redis.

Wszystko działa pięknie — dopóki połączenie jest stabilne.

Co się dzieje, gdy:

  • Telefon w aucie traci sygnał LTE (parking podziemny)?
  • Przełącza się między WiFi domowym a LTE w drodze?
  • WebSocket disconnects po godzinie idle (bez aktywności)?
  • Backend się restartuje przy deploymentach?

W każdym z tych scenariuszy aplikacja powinna automatycznie przywrócić połączenie + odtworzyć zdarzenia, które zaszły w trakcie disconnect + nie zalewać serwera retries, jeśli backend faktycznie pada.

To jest mała inżynierska piekło. Spędziłem 2 tygodnie na exponential backoff, kolejkowaniu lokalnym (SQLite), idempotency keys, sequence numbers do detekcji utraconych eventów. Wszystkie te rzeczy znałem teoretycznie. W praktyce — zaimplementowanie ich tak, żeby działały w 100 różnych scenariuszach edge-case... to jest co innego.

Lekcja: real-time to nie jest problem techniczny. To jest problem filozoficzny. „Co znaczy 'czas rzeczywisty', gdy sieć jest zawodna?" Każdy solo-developer mobile prędzej czy później musi sobie odpowiedzieć na to pytanie.

Moment 3: Foreground service na różnych ROM-ach (4 tygodnie)

Najdłuższy z tych trzech momentów. Powiązany z pierwszym (optymalizacja baterii), ale dotyczył konkretniej utrzymania ciągłej pracy aplikacji w godzinę 0:00 do godziny 23:59, dzień po dniu, niezależnie od tego, co Android próbuje z tym zrobić.

Foreground service to mechanizm Androidowy, który mówi: „ta aplikacja jest świadomie uruchomiona przez użytkownika, ma persistent notification, nie wolno jej zabić". W teorii.

W praktyce każdy producent ma własne reguły, kiedy mimo wszystko zabija foreground service. Różne wersje Androida mają różne limity. Niektóre ROM-y mają „agresywne oszczędzanie baterii", które omija system Android i działa na poziomie ROM-u.

4 tygodnie iteracji:

  • Persistent notification z konkretnym priorytetem
  • WakeLock z timeoutami
  • Restart self z BroadcastReceiver po BOOT_COMPLETED
  • Periodic AlarmManager jako safety net
  • Native heartbeat co 60 sekund z eskalacją alertów

Aplikacja dziś działa stabilnie na ~95% testowanych konfiguracji. Te 5%, gdzie wciąż się zdarzają problemy — to pole walki na kolejne miesiące.

Lekcja: mobile development to nie jest „co napisałeś". To jest „w ilu warunkach to działa, mimo że nie powinno".

Czemu nie szukam inwestora

To pytanie dostaję regularnie, więc krótko i konkretnie.

Trzy powody:

1. Nie ma jeszcze czego sprzedawać inwestorowi. Mam działającą betę. Mam pierwszych testerów. Mam 0 zł przychodu. Mam 0 zł reklam. Każdy szanujący się inwestor zapyta: „pokaż mi traction". Nie mam co pokazać. Pieniądze przed traction = przedwczesna optymalizacja kapitałowa.

2. Solo-projekt = wolność produktowa. Mogę dziś zdecydować, że robię tryb „Młody kierowca" zamiast iOS. Albo odwrotnie. Bez nikogo, kto powie „nie, ten kwartał skupiamy się na onboardingu fleet customers, bo to obiecaliśmy w deck-u". Wolność jest dla mnie bardziej wartościowa niż przyspieszenie kosztem nieswojej drogi.

3. Małe ambicje są w porządku. Nie wszystko musi być unicornem. LocaCar może być rentownym małym biznesem dla 10-50 tys. użytkowników, na poziomie ~5-10 zł miesięcznie. To jest dla mnie satysfakcjonujący cel. Inwestor zwykle nie chce takich celów — bo z perspektywy funduszu to nie jest atrakcyjny exit.

Czy to się może zmienić? Tak. Jeśli za rok okaże się, że produkt rośnie wykładniczo i potrzebuję zespołu 10 osób, żeby obsłużyć skalę — wtedy rozmowa z inwestorem ma sens. Ale dziś? Solo + wolny czas + minimalny burn = optymalna sytuacja.

Czemu beta zamiast „od razu sprzedaż"

Tutaj odpowiedź jest jeszcze prostsza.

Bo aplikacja, która kosztuje pieniądze, podlega innym oczekiwaniom. Płacący użytkownik ma prawo żądać. Tester bety — daje feedback i wybacza błędy.

Beta pozwala mi:

  • Iterować szybko bez stresu „zwracam pieniądze"
  • Zbierać feedback od ludzi, którzy są skłonni go dawać (testerzy są bardziej zaangażowani niż klienci)
  • Testować różne hipotezy produktowe bez narzutu „lock-in z poprzednią ofertą"
  • Budować społeczność ludzi, którzy są emocjonalnie zainwestowani w sukces projektu

Sprzedaż przyjdzie. W lipcu pierwsze plany płatne. Ale podstawową bazą zawsze będą ludzie, którzy weszli przed monetyzacją. Im się należy lifetime premium — i to nie marketingowy chwyt, tylko uczciwa rekompensata za ryzyko, które wzięli na siebie.

Roadmapa najbliższego kwartału

Skoro już szczerze, to do końca:

Maj 2026: stabilizacja bety + cel 30 nowych testerów. Główny focus techniczny: detekcja akustyczna (analiza dźwięku w aucie — to nasza realna przewaga nad dedykowanymi trackerami).

Czerwiec 2026: wersja iOS. Albo jako React Native (ryzykowne, bo natywne moduły będą wymagały przepisania), albo jako oddzielna aplikacja w Swift (wolniej, ale czysto). Decyzja jeszcze nie podjęta.

Lipiec 2026: pierwsze plany płatne. Trzy poziomy: free (1 pojazd, podstawowe alerty), Standard (~5 zł/mc, 3 pojazdy, pełna historia), Premium (~9 zł/mc, 5+ pojazdów, ML detection, raporty PDF).

Q3 2026: aktywna sprzedaż. Płatne reklamy, partnerstwa z ubezpieczycielami, obecność na branżowych imprezach (motoryzacyjnych, IoT).

To jest plan. Może się zmienić w ciągu miesiąca. Solo-projekt to taki właśnie ma luksus.

Co bym zrobił inaczej, gdybym zaczynał dziś

3 rzeczy:

1. Zacząłbym pisać publicznie wcześniej. Pierwsze 6 miesięcy budowałem w ciszy. Bez bloga, bez postów, bez nikogo, kto by widział, co robię. To było marnowanie czasu — feedback, networking, motywacja społeczności to są kluczowe składniki sukcesu solo-projektu. Dziś zacząłbym budować in-public od dnia pierwszego.

2. Pierwszy tester po 2 tygodniach, nie po 3 miesiącach. Każdy dzień bez testera to dzień, w którym budujesz coś, czego być może nikt nie potrzebuje. Nawet jeśli aplikacja jest „brzydka" — pokaż ją. Brzydka aplikacja z feedbackiem > piękna aplikacja w pojedynkę.

3. Mniej funkcji, więcej szlifu. Dziś LocaCar ma 23 funkcje. Z tego ~6 jest faktycznie używanych przez większość testerów. Reszta to kod, który muszę utrzymywać, dokumentować, debugować. Gdybym zaczynał od nowa — zrobiłbym 5 funkcji, ale każdą dopracowaną. Reszta — tylko po request-cie od użytkowników.

Ostatnia myśl

Nie wiem, czy LocaCar odniesie sukces. Nie wiem, czy w lipcu znajdą się chętni na płatne plany. Nie wiem, czy za rok będę pisać o LocaCar jako sukcesie, czy jako ciekawej lekcji.

Wiem natomiast jedno: jest mi z tym dobrze. Praca po godzinach nad własnym projektem, gdzie mogę wszystko, jest formą wolności, której zazdroszczę sam sobie sprzed 12 miesięcy.

Jeśli czytasz ten artykuł i też budujesz coś sam — wiedz, że nie jesteś sam. Solo-developerzy to nie jest mała grupa. Większość po prostu nie pisze o tym publicznie.

Może warto to zmienić.

Podziękowania

Za doczytanie do tego miejsca — dzięki. Za każdy komentarz, polubienie, udostępnienie — podwójne dzięki. Za każdą rejestrację na becie — potrójne.

LocaCar nie jest moim zarobkiem. Jest moim ulubionym hobby, które może kiedyś stanie się czymś więcej. Ale nawet jeśli nie stanie się — i tak wygrałem, bo nauczyłem się więcej w te 8 miesięcy niż w 5 ostatnich latach pracy etatowej.

Zaproszenie do bety: locacar.ovh/beta. Bez karty kredytowej, bez zobowiązań, dożywotnia subskrypcja premium za feedback.

Następny artykuł na blogu LocaCar — sobota 9.05: „Optymalizacja baterii w aplikacjach mobilnych — 8 tygodni walki z Androidem". Wracamy do tematów technicznych. Subskrybuj newsletter na locacar.ovh, żeby nie ominąć.

Komentarze, własne historie solo-projektów, pytania, krytyka — wszystko mile widziane. Kontakt@locacar.ovh albo bezpośrednio pod artykułem.