Case study APP Smart Control dla KG Elektronik – aplikacja do sterowania kotłem gazowym, którą zbudowaliśmy w 8 tygodni. Dziś podłączonych jest około 12 tysięcy urządzeń, liczba rośnie miesiąc do miesiąca, a klienci końcowi wracają do sklepu pytając wprost o sterownik z WiFi.
W skrócie
- Czas wdrożenia: 8 tygodni od briefu do publikacji w sklepach
- Podłączone urządzenia: około 12 tys. (stan 2026-04-13, rośnie miesiąc do miesiąca)
- Pobrania w Google Play: 1 000+
- Stack: AWS + Nest.js + Flutter + MQTT
- Branża: producent sterowników i kotłów gazowych (B2B + B2C)
TL;DR
- Co zrobiliśmy: aplikacja mobilna iOS + Android do zdalnego zarządzania sterownikami kotłów gazowych KG Elektronik
- Dla kogo: klienci końcowi KG Elektronik – użytkownicy sterowników z modułem WiFi
- Wynik biznesowy dla klienta: sterowniki kosztują tyle samo, ale w sklepie klienci wracają wołając ten z WiFi
- Czas: 8 tygodni MVP, dalej rozwój iteracyjny
- Stack: Flutter (mobile), NestJS + PostgreSQL + Redis + MQTT + Firebase (backend), Next.js (admin OTA panel), AWS EC2 + RDS + S3
Kim jest klient
KG Elektronik to polski producent sterowników i kotłów gazowych z 25-letnim doświadczeniem na rynku. W portfolio kilkadziesiąt typów sterowników do kotłów zasypowych i z podajnikiem (od SP-05 LCD przez CS-23 po SP-35 PID WiFi), regulatory pomp, instalacji, akcesoria. Sprzedaż prowadzą przez sieć dystrybutorów i sklep własny.
Dotychczasowy produkt KG był sterowany z fizycznego panelu w kotłowni. Klient końcowy musiał zejść do piwnicy, żeby cokolwiek zmienić. Firma z ćwierćwieczem doświadczenia w hardwarze potrzebowała warstwy cyfrowej – cel, który zespół KG nazwał wprost „przejściem od prostych sterowników do pełnego systemu Smart Home”.
Wyzwanie: hardware z 25-letnim stażem w świecie, który chce sterować wszystkim z telefonu
KG ma na rynku ćwierćwiecze. Sterowniki, które produkują, od lat po prostu działają. Problem nie leżał w hardware. Problem leżał w warstwie, której hardware nie miał.
Dotychczasowy sterownik był obsługiwany z fizycznego panelu w kotłowni. Żeby zmienić temperaturę, ustawić harmonogram, sprawdzić dlaczego piec zgasł – trzeba było zejść do piwnicy. O awarii klient końcowy dowiadywał się w najlepszym przypadku z termometru na ścianie, gdy temperatura już spadła. W najgorszym – rano, gdy robiło się zimno.
Z perspektywy KG był drugi problem, którego klient końcowy nie widzi. Aktualizacja firmware sterownika wymagała fizycznej obecności przy urządzeniu. Przy jednym kotle to drobna niedogodność. Przy dwunastu tysiącach zainstalowanych sterowników, z których każdy potencjalnie potrzebuje update’u, to jest liczba wyjazdów, których nie da się zrobić. Każda nowa wersja oprogramowania = koszt dotarcia do każdego urządzenia.
Cel projektu nie był więc „zrobić apkę”. Cel, jak później ujął to zespół KG w publikacji na LinkedIn, to było przejście „od prostych sterowników do pełnego systemu Smart Home”. Czyli: warstwa cyfrowa, która sprawia, że sterownik z 2010 może konkurować w 2026.
Prościej: sterownik bez aplikacji żyje w piwnicy. Sterownik z aplikacją żyje w kieszeni klienta. Pierwszy jest narzędziem. Drugi jest produktem.
„Klienci i konkurencja zostali zaskoczeni tak prostą i fajną apką”
„Ogólnie to klienci i konkurencja zostali zaskoczeni tak prostą i fajną apką. Oraz że sterowniki nic nie podrożały a mają takie bajery. Dopiero w tym miesiącu zaczynamy czuć, że klient w końcu wraca do sklepu wołając nasz sterownik z WiFi. Miłe zaskoczenie, ale na to liczyłem.”
To jest cytat z rozmowy w kwietniu 2026. Sześć miesięcy po starcie aplikacji w sklepach. Wracamy do tego pod koniec.
Co zbudowaliśmy: cały ekosystem, nie tylko aplikacja do sterowania kotłem gazowym
APP Smart Control to z punktu widzenia klienta końcowego aplikacja mobilna iOS + Android do zdalnego zarządzania sterownikami KG. Pod spodem zbudowaliśmy trzy współpracujące komponenty, każdy z innym celem:
1. Aplikacja mobilna (Flutter, iOS + Android). Dla właścicieli domów, zarządców biur i obiektów publicznych. Zobacz temperaturę, ustaw harmonogram, dostań powiadomienie gdy coś odbiega od normy. Flutter wybraliśmy nad React Native i natywem, bo to jeden zespół, jeden budżet i równoległy release na iOS i Android — plus identyczny wygląd na każdym telefonie (iPhone, Samsung, Huawei w organizacji klienta publicznego).
2. Backend IoT (NestJS na AWS EC2). Serce systemu. Łączy się ze sterownikami w kotłowniach przez MQTT, przechowuje dane w PostgreSQL (AWS RDS), obsługuje alarmy i wysyła push notifications przez Firebase Cloud Messaging. Kolejka zadań w Redis + BullMQ (dla spokoju, gdy 12 tysięcy sterowników wysyła telemetrię naraz). Całość w Dockerze, za Nginxem jako reverse proxy.
3. Panel admina dla KG Elektronik (Next.js 15 + React 19 + Tailwind). Tego nie widzi klient końcowy, ale to on robi robotę. KG wgrywa przez niego nowe wersje firmware sterowników (pliki .bin, .hex, .fw) do AWS S3, aktywuje wersje, pobiera logi. Dzięki temu aktualizacja 12 tysięcy urządzeń nie wymaga wysłania technika do każdej kotłowni — wersja firmware leci do sterownika przez MQTT, OTA (over-the-air).
Gdyby któregoś z tych trzech brakowało, reszta by nie działała. Sam mobile bez backendu to „pilot bez baterii”. Sam backend bez dashboardu to „baza danych bez panelu, żeby cokolwiek zmienić”. Dashboard bez mobile to „panel administratora bez użytkowników, do których się adresuje”.
Jak to wygląda w telefonie
Cztery ekrany z APP Smart Control – tak jak są prezentowane w Google Play.
← przewiń, żeby zobaczyć więcej →
Dwie decyzje techniczne, które kształtowały projekt
MQTT direct zamiast AWS IoT Core. W pierwszym tygodniu rozważaliśmy AWS IoT Core (managed MQTT broker) vs własny broker MQTT na EC2. Managed to wygoda, ale koszt rośnie liniowo z liczbą urządzeń — przy 12 tys. sterowników (i rosnącej bazie) rachunek AWS robi się poważny. Wybraliśmy direct MQTT w aplikacji NestJS, z Redis jako backing store dla kolejki (BullMQ) i PostgreSQL do persystencji. Kompromis: więcej własnej infrastruktury do utrzymania, ale przewidywalne koszty i pełna kontrola nad routing logic alarmów.
OTA firmware przez osobny panel admina. Moglibyśmy zrobić „monolit” — wgrywanie firmware z aplikacji mobilnej albo z backendu programistycznie. Ale aktualizacja firmware sterownika to nie jest feature dla end usera — to jest proces operacyjny KG. Dlatego zbudowaliśmy osobny dashboard (Next.js 15) tylko dla zespołu KG: upload .bin/.hex/.fw do S3, wybór której wersji aktywować na którym modelu, rollback jeśli coś pójdzie nie tak. Separation of concerns: mobile dla użytkowników końcowych, dashboard dla operatorów, backend jako most między sterownikami a jednym i drugim.
Dziś: około 12 tysięcy podłączonych urządzeń, liczba rośnie miesiąc do miesiąca
Stan na 13 kwietnia 2026: około 12 000 urządzeń podłączonych do platformy. Liczba rośnie z miesiąca na miesiąc, bo każdy nowy sterownik z modułem WiFi, który schodzi z linii produkcyjnej KG, trafia do bazy.
To są realne obiekty – od domów jednorodzinnych po hale produkcyjne. Każde urządzenie wysyła telemetrię przez MQTT do naszego backendu (NestJS na AWS EC2), dane trafiają do PostgreSQL, a aplikacja mobilna odczytuje aktualny stan przez API. Każde urządzenie może być sterowane z aplikacji w telefonie zarządcy lub właściciela.
Co to oznacza biznesowo dla KG, mówi sam Grzegorz w cytacie wyżej: klienci i konkurencja zaskoczeni, sterowniki w tej samej cenie, klient wraca do sklepu po model z WiFi. To są trzy efekty, których nie kupisz inaczej niż produktem, który po prostu działa.
Stack, konkretnie — bez mądrych brandów dla samego brzmienia
Mobile (APP Smart Control): Flutter (Dart). Jeden codebase, dwa sklepy (iOS App Store i Google Play), jeden zespół.
Backend IoT: NestJS 11 (TypeScript), PostgreSQL jako baza danych (AWS RDS), Redis 7 + BullMQ jako kolejka zadań (obsługa push notifications i jobów asynchronicznych), MQTT do komunikacji ze sterownikami, Socket.IO + WebSocket do real-time w dashboardzie, Firebase Admin SDK do push notyfikacji (Firebase Cloud Messaging) i autoryzacji. Wszystko w Dockerze, Nginx jako reverse proxy, deploy na AWS EC2.
Panel admina KG: Next.js 15 + React 19 + Tailwind CSS + Firebase (auth). Hostowany osobno na AWS.
Storage firmware: AWS S3. Każda wersja firmware jako osobny obiekt, wersjonowanie, presigned URLs do pobrania przez sterowniki.
Co celowo pominęliśmy: AWS IoT Core (droższy niż bezpośredni MQTT przy bazie 12 tys.+ urządzeń), Lambda + API Gateway (nie potrzebny tu serverless — konsystentny ruch, nie spikes), DynamoDB (relacyjne dane — urządzenia, użytkownicy, konfiguracje — pasują lepiej do Postgres).
FAQ
Jak aplikacja łączy się ze sterownikiem?
Przez MQTT — lekki protokół pub-sub zaprojektowany do IoT, używany w milionach urządzeń. Sterownik z modułem WiFi łączy się z brokerem MQTT w naszym backendzie, aplikacja mobilna dostaje aktualny stan przez API.
Ile kosztuje aplikacja dla użytkownika końcowego?
Aplikacja jest darmowa. Pobranie z Google Play lub App Store, logowanie przez Firebase Auth. Sterownik z modułem WiFi sprzedawany jest przez KG Elektronik w cenie zbliżonej do wersji bez WiFi.
Czy aplikacja działa z każdym sterownikiem KG?
Z modelami z modułem WiFi, w tym SP-35 PID WiFi i SP-18 Control Smart Multi. Pełna lista kompatybilnych sterowników na stronie kgelektronik.pl.
Jak wygląda aktualizacja firmware sterownika? Czy muszę wysyłać technika?
Nie. KG wgrywa nową wersję firmware przez panel admina (osobny dashboard), a sterowniki pobierają aktualizację OTA przez MQTT. 12 tysięcy urządzeń dostaje update bez wyjazdu technika.
Czy mogę dostać podobną aplikację dla mojego hardware’u?
APP Smart Control to pierwszy projekt IoT w portfolio JSON Crew (firma istnieje od 2024, core to konfiguratory produktowe i automatyzacja sprzedaży). Jeśli planujesz aplikację do swojego sterownika lub urządzenia — porozmawiajmy bez zobowiązań.
Porozmawiajmy o twoim projekcie
Masz w firmie hardware, do którego brakuje warstwy cyfrowej? Czy planujesz zupełnie nową aplikację mobilną dla klientów końcowych? Trzydzieści minut rozmowy zwykle wystarczy, żeby zobaczyć, czy projekt ma sens i jak mógłby wyglądać MVP.
Wyślij briefing → lub zadzwoń: +48 886 864 199, e-mail: [email protected].
Odpowiadamy w 24h w dni robocze.
