PowerPulse, społecznościowy tracker przerw w dostawie prądu, stworzony przez ghańską programistkę przy użyciu narzędzi low-code wspomaganych przez AI, zadebiutował na platformie Vercel po dwóch dużych zmianach koncepcji produktu (pivotach). Aplikacja pozwala każdemu w Ghanie zgłosić brak prądu, śledzić na żywo strumień zgłoszeń oraz przeglądać statystyki przywracania zasilania – bez konieczności posiadania formalnego wykształcenia inżynierskiego.

Dlaczego „dumsor” potrzebuje wspólnej prawdy

W Ghanie termin „dumsor” opisuje nieregularne przerwy w dostawie prądu, które bez ostrzeżenia pogrążają całe dzielnice w ciemnościach. Mieszkańcy tracą godziny na zgadywanie, czy problem leży w ich przyłączeniu, na ich ulicy, czy w krajowej sieci energetycznej. Ta niepewność paraliżuje biznes, naukę i życie codzienne. Społecznościowo zweryfikowane źródło danych o awariach pozwoliłoby ludziom planować działania w oparciu o przerwy w dostawie prądu, koordynować pomoc i wywierać presję na dostawców usług, aby poprawzyli jakość świadczonych usług.

Od osobistej frustracji do prototypu civic-tech

Twórczyni, która określa siebie mianem nieprofesjonalnej programistki, przekuła swoją osobistą irytację zjawiskiem dumsor w użyteczne narzędzie publiczne. Wykorzystała platformy low-code oparte na AI – generowanie kodu na podstawie promptów oraz gotowe usługi – aby stworzyć aplikację webową typu full-stack bez ręcznego przepisywania każdej linii kodu.

Produkt oferuje cztery główne funkcje:

  • Zgłoszenie awarii poprzez wybór regionu i miasta z menu rozwijanych.
  • Śledzenie na żywo wszystkich obecnie zgłoszonych przerw w dostawie prądu.
  • Przeglądanie statystyk dotyczących czasu trwania awarii i szybkości ich usuwania.
  • Zdobywanie punktów i poziomów statusu dla częstych użytkowników, co zachęca do regularnego zgłaszania incydentów.

Stos technologiczny, który to umożliwił

  • Next.js 16 i TypeScript jako framework front-endowy i zapewnienie bezpieczeństwa typów.
  • Tailwind CSS do szybkiego stylowania opartego na klasach pomocniczych (utility-first).
  • Supabase do obsługi bazy danych, uwierzytelniania użytkowników i aktualizacji w czasie rzeczywistym.
  • Vercel do hostingu z automatycznym skalowaniem.

Wszystkie komponenty są oprogramowaniem open source lub usługami zarządzanymi, dzięki czemu programistka mogła skupić się na logice produktu, podczas gdy AI wypełniało powtarzalny kod (boilerplate).

Pivot 1 – Rezygnacja z mapy na żywo

Pierwszy prototyp zawierał mapę Ghany na żywo, zbudowaną przy użyciu Leaflet, biblioteki mapowania JavaScript open source. Leaflet wymaga środowiska przeglądarkowego, co kolidowało z renderowaniem po stronie serwera (SSR) w Next.js i powodowało trudne do zdiagnozowania błędy. Po walce z tymi błędami, programistka zastąpiła mapę prostymi listami rozwijanymi do wyboru regionu i miasta. Interfejs użytkownika stracił wizualny efekt, ale podstawowa funkcjonalność – zbieranie i wyświetlanie zgłoszeń – stała się niezawodna i gotowa do wdrożenia.

Pivot 2 – Redesign układu

Pierwsza wersja była pojedynczą przewijaną stroną, która łączyła zgłaszanie, strumienie danych i statystyki w jednym miejscu. Użytkownicy twierdzili, że „wygląda to jak projekt szkolny”. Aby nadać aplikacji bardziej profesjonalny wygląd, przebudowano nawigację. W przeglądarkach na komputerach głównymi sekcjami zarządza pasek boczny, natomiast użytkownicy mobilni korzystają z dolnego paska nawigacji. Każdy widok – Zgłoszenie, Strumień, Statystyki – ma swój własny ekran, dzięki czemu aplikacja sprawia wrażenie dojrzałego produktu, a nie tylko dowodu koncepcji (proof-of-concept).

Dylemat „zimnego startu”

Nawet przy funkcjonalnym interfejsie, system oparty na crowdsourcingu zależy od zaangażowania użytkowników. Aplikacja jest użyteczna tylko tam, gdzie wystarczająca liczba osób zgłasza awarie, aby zapewnić pokrycie danych. Nie jest to błąd w kodzie, lecz wyzwanie związane z budowaniem społeczności. Bez krytycznej masy współtwórców zbiór danych pozostaje rzadki, co ogranicza wartość aplikacji.

Kontrargument: ograniczenia i kompromisy low-code

Narzędzia low-code wspomagane przez AI przyspieszają rozwój, ale narzucają pewne ograniczenia. Problem z mapą pokazuje, jak gotowa biblioteka może nie współgrać z wybranym frameworkiem, wymuszając redesign, który poświęca kontekst geograficzny. Poleganie na zarządzanych backendach, takich jak Supabase, może również ograniczać niestandardową analitykę lub możliwości pracy offline, które mógłby zapewnić dedykowany serwer. Programiści muszą ważyć szybkość względem elastyczności, zwłaszcza gdy w grę wchodzi wpływ społeczny.

Co dalej

Mapa drogowa zakłada trzy ulepszenia:

  • Przewidywanie ryzyka awarii oparte na AI, wykorzystujące dane historyczne do prognozowania prawdopodobnych stref braku prądu.
  • Powiadomienia push, które informują użytkowników, gdy w ich okolicy zostanie zgłoszona awaria lub przywrócone zasilanie.
  • Rozwój natywnej aplikacji mobilnej.

Każde z tych ulepszeń ma na celu zwiększenie zaangażowania użytkowników, rozwiązując problem „zimnego startu” od strony podaży – więcej funkcji to więcej powodów, by zainstalować i używać aplikacji.

Wnioski

PowerPulse pokazuje, że zdeterminowana osoba może wykorzystać platformy low-code wspomagane przez AI, aby dostarczyć funkcjonalne rozwiązanie typu civic-tech, nawet na rynku borykającym się z problemami z niestabilną siecią energetyczną. Historia ta podkreśla dwie lekcje: po pierwsze, wypuszczenie używalnego produktu jest ważniejsze niż dopracowywanie wadliwej funkcji; po drugie, sama technologia nie rozwiąże problemu opartego na crowdsourcingu – prawdziwym wąskim gardłem jest zbudowanie społeczności współtwórców.