PowerPulse: Building a Crowd-Sourced Outage Tracker for Ghana (and Losing a Fight With My Own Stack)

A quick disclosure up front: this post was drafted with AI assistance, and edited by me. The PowerPulse codebase itself has also been built largely with AI help — which is actually a big part of what this post is about.

Why I'm building this

If you live in Ghana, you know the drill. The lights go off, and within minutes the group chat lights up instead: "Is it just us or is the whole area off?" Nobody really knows if it's a blown transformer, scheduled load-shedding, or something bigger, and there's no single place to check.

That's the gap PowerPulse is trying to fill: a crowd-sourced electricity outage reporting and tracking app for Ghana. People report outages as they happen, the app plots them on a live map across all 16 regions, and over time it's meant to build up enough signal to flag which areas are at higher risk and roughly when power might come back.

It started small — a single self-contained HTML prototype with a schematic map of the regions and some rough outage-reporting logic. That was enough to prove the idea had legs. So I rebuilt it properly: Next.js, React, Tailwind CSS, and Supabase for the backend, with an interactive mapping library for the live view.

That's roughly where things stopped going smoothly.

I'll be upfront about something: I'm not coming at this as someone who's spent years deep in the internals of Next.js or Tailwind. I've been leaning heavily on AI tools to scaffold the app, generate components, and help me reason through errors I don't fully recognize on sight. That's worked well for getting a lot of the app off the ground quickly.

But it also means that when something breaks in a way that touches the framework's deeper plumbing, I'm not just debugging code — I'm debugging code I didn't fully write, using tools that sometimes talk past each other.

That's exactly what happened here.

The most recent debugging session was rough. I ran into an error rooted in how Next.js separates code that runs on the server from code that has to run in the browser — the interactive map library needs the browser to draw anything, and something in how it was wired up was breaking that boundary. I went back and forth with AI assistance trying different fixes, and each one seemed to patch one symptom while leaving the underlying issue untouched.

Layered on top of that was a second, quieter problem: the styling started silently breaking. No error message, no red text in the terminal — just spacing and layout that looked subtly wrong, like the CSS wasn't fully applying. That kind of bug is worse in some ways than a hard crash, because there's nothing pointing you at the cause. I eventually traced it to a CSS configuration issue, but tracing it and actually fixing it turned out to be two different problems.

By the end of the session I was mid-way through a fairly blunt fix — reinstalling dependencies from scratch via Command Prompt — and that's where things got left hanging.

Here's roughly the shape of the problem. The map component looked something like this:

import { MapContainer, TileLayer, Marker } from 'react-leaflet';

export default function OutageMap() {
  return (
    <MapContainer center={[7.9465, -1.0232]} zoom={7}>
      <TileLayer url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png" />
    </MapContainer>
  );
}

Nothing obviously wrong there — until Next.js tried to render it on the server, and it blew up with something like:

ReferenceError: window is not defined

The map library needs the browser's window

object to draw anything, and Next.js's App Router defaults every component to a Server Component unless told otherwise. So the very first render pass — on the server, before anything hits the browser — had no window

to work with, and it crashed.

The second problem didn't come with a stack trace at all. Somewhere in the Tailwind setup, the custom theme values weren't making it through:

@import "tailwindcss";

@theme {
  --color-primary: oklch(0.6 0.2 250);
  --spacing-section: 4rem;
}

That's roughly what the config was supposed to look like — but the actual values weren't being picked up. No error, no warning. Utility classes referencing those variables just quietly did nothing, and the layout looked subtly broken in a way that was hard to pin down without knowing exactly where to look.

I want to be honest about this rather than wrap it up with a neat bow: as of right now, it isn't fixed. The reinstall was pending, and I don't yet know if it'll resolve either issue or just shuffle the problem somewhere else. That's the reality of building like this — AI tools can get you shockingly far, shockingly fast, right up until you hit a knot that needs a genuinely deep understanding of what's happening under the hood, and then progress can stall out for a while.

I'm sharing this mid-mess on purpose. If you've built something serious by leaning on AI-assisted development without being a framework expert yourself, you've probably hit a version of this same wall — where the fixes stop compounding and start contradicting each other. I'd genuinely like to hear how other people have pushed through that stage, because right now I'm still in it.

More updates once I actually get this working.