DEV Community: Suzzane Koranteng

PowerPulse II

Suzzane Koranteng — Wed, 15 Jul 2026 17:45:17 +0000

The Problem I Was Actually Trying to Solve

If you've lived in Ghana, you know "dumsor" — the unofficial word for unpredictable power outages. Your light goes out and you genuinely have no idea: is it just your house? Your street? The whole area? Is ECG doing planned maintenance, or is something actually broken? There's no shared, real-time source of truth for any of this. You're guessing, or asking a WhatsApp group, or just sitting in the dark.

I'm not a professional developer. I build and ship things with AI assistance, learning as I go — mostly civic tech, tools for a Ghanaian context. PowerPulse started as an idea to fix that specific gap: what if outage reporting was crowd-sourced, confirmed by the community, and actually tracked restoration times over time?

So I built it. Here's the whole story — goal, build, the two times I had to tear things down and start over, and where it stands now.

What PowerPulse Actually Does

Report an outage — pick your region and town, add an optional note, tap "Power Out"
Community confirmation — others in the area tap "I see this too," so a report with 12 confirmations means something real, not one person's claim
Power Back reporting — closes out the outage and, crucially, lets the system calculate real average restoration times per region — data that doesn't really exist anywhere else in an accessible form
Subscriptions + notifications — watch a region, get alerted the moment something's reported or restored there
A trust/reputation system — Candle Bearer → Torch Carrier → Bulb Guardian → Voltage Warden → Grid Sentinel, tiers earned through accurate reporting, confirming others, and reporting restorations
A live stats dashboard — active outages, most affected regions, average restoration time, weekly vs. all-time views, with actual charts

The Stack

Next.js 16 (App Router) + TypeScript + Tailwind, Supabase for Postgres + Auth + Realtime, Recharts for the dashboard, deployed on Vercel. No custom backend server — Supabase's row-level security policies handle all the access control directly in the database, so the frontend talks straight to Postgres via their client library.

Pivot #1: Killing the Map

I originally planned a live Leaflet map of Ghana's regions — click your area, see color-coded outage intensity, the whole visual thing. I hit the exact wall a lot of people hit combining Leaflet with Next.js: Leaflet manipulates the DOM directly, and Next.js tries to server-render everything by default, which breaks immediately (window is not defined, or a silent zero-height container if you dynamically import it wrong).

I tried dynamic() imports with ssr: false. Then hit a second bug where the map container had zero height at the moment Leaflet initialized, so it "loaded" but rendered invisible. At that point I made a call that I think matters more than people admit: I cut the feature entirely.

Instead of a map, outage location became a simple region + town dropdown. Less impressive-looking, way more reliable, and it let me actually ship the features that mattered — reporting, confirming, restoring — instead of staying stuck on a visual that wasn't core to the value.

Pivot #2: The Whole Layout

The first working version was one long page — report form, feed, dashboard, badge explainer, all stacked vertically. It worked. It also felt like a class project, not a product.

So I rebuilt the whole navigation: a real sidebar (desktop) / bottom nav (mobile), a proper home dashboard with your tier, a live snapshot stat, and clickable action cards — Report, Live Feed, Statistics, Learn — each living in its own focused view instead of everything competing for attention on one page. That one architectural change did more for how "real" the app felt than any individual feature did.

The Annoying Technical Stuff (For the Engineers Reading This)

Tailwind v4 → v3 downgrade. The scaffolding tool defaults to Tailwind v4 now, which uses a completely different CSS-variable-based config system than what I was expecting to work with. Had to manually uninstall, reinstall v3, regenerate config files, rewrite the CSS import syntax from @import "tailwindcss" to the old @tailwind base/components/utilities directives.
PowerShell execution policy. Windows blocks npm/npx scripts by default. Needed Set-ExecutionPolicy RemoteSigned -Scope CurrentUser as admin before any tooling would run at all — an easy one-line fix, but a genuinely confusing wall to hit on day one.
Row Level Security. Before deploying, I locked down every database table so people can only do what the app logic allows — not whatever raw API calls someone could otherwise make with the public key. The tricky part: my points-awarding system needed a SECURITY DEFINER Postgres function, since confirming someone else's report has to update their points, which normal RLS would otherwise block entirely.
Auth redirect mismatch. Magic-link login worked perfectly on localhost, then 404'd in production until I updated Supabase's allowed redirect URLs to include the real Vercel domain.

Where It Stands

PowerPulse is live, installable as a PWA on phones (Safari's "Add to Home Screen" on iOS, Chrome's install prompt on Android), with the full loop working end to end: report → confirm → restore → points/tiers → live dashboard.

The Honest Limitation

A crowd-sourced platform is only as good as the number of people using it in any given area. Five active users in Accra and zero in Kumasi means Kumasi effectively has no coverage yet. This is the classic cold-start problem every platform like this faces — Waze, Citizen, all of them hit this early. The answer isn't technical. It's distribution, community adoption, getting real people in real neighborhoods to actually use it. That's the next hard problem, and it's not one I can solve by writing more code.

What's Next

An AI layer, using Claude's API, analyzing report patterns per region to estimate outage risk and restoration times — parked for now until there's a small budget for API costs, since it's the one part of this stack that isn't free. Beyond that: real push notifications instead of the current in-app-only alerts, and eventually seeing if this is worth turning into an actual native app.

If you're in Ghana and dealing with outages, or just curious how it's built — I'd love feedback. This was built by someone learning as they go, with a lot of AI-assisted pair programming and a lot of "wait, why is this not working" moments. If that's relatable to you, hopefully this post was useful.

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

Suzzane Koranteng — Sat, 11 Jul 2026 11:24:49 +0000

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.

Building with AI help, without deep framework knowledge

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.

Two bugs, one long session

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.

The bug that ate an afternoon: Server Components meet the map library

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 quieter bug: styles that silently stopped applying

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.

Where it stands: still broken

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.