Medianet: The App Isn't Glamorous, the Job Was Real

Medianet was my first real project after joining EdgeFirm, and it taught me more about building under actual constraints than anything else I've worked on. I scoped it with the client and built both ends of it.

What it's for

K-Electric needed a way to manage field officers who go door to door recovering payment on overdue electricity accounts. That sounds simple until you look at what it requires. Assigning thousands of cases to officers in batches, verifying an officer actually turned up via GPS, recording every collection attempt with photos and meter readings, giving supervisors a live view of where their team is, then rolling all of it into reports management can trust. Over 300 field officers use it daily.

Why "just build a CRUD app" undersells it

The thing that made it genuinely hard is that field officers work on inconsistent connectivity, often none at all. If the app needs a live connection to submit an attempt, either the officer can't work or the data disappears. So the frontend, Next.js with a service worker, had to support real offline capture. Forms fill in normally with no connection, captures sit in IndexedDB, and everything syncs once the officer is back in range. That isn't a feature you bolt on at the end. It changes how you design every write operation in the app.

The backend had its own pressure

We built it on NestJS with Prisma over Postgres, and what shaped the architecture most was volume. This isn't a hundred cases, it's a system built for a large utility's delinquent account list, with bulk Excel import and export as a first class concern rather than an afterthought. Long running work like report generation and bulk imports runs through Bull queues on Redis instead of blocking a request, because nobody wants to watch a spinner while ten thousand rows import.

We also built proper role based access scoped to projects and IBCs, the regional units K-Electric organises recovery around. "Admin sees everything, officer sees their own cases" isn't how permissions actually work at this scale. Supervisors need visibility into their specific team, admins need cross region reporting, and officers need a stripped down, fast, offline tolerant screen with none of the management overhead in the way.

What stuck with me

There isn't a single line of AI in this project and it was still one of the most demanding things I've built, because the constraints were real people, real connectivity problems, and real money changing hands based on what the app recorded. It's a decent reminder that full stack engineer and AI engineer aren't separate skill sets. The discipline of building something that has to stay correct under bad conditions carries straight over into building AI systems that have to behave under uncertain inputs.