Three systems, and the decisions behind them.
Each one below was taken end to end: data model, backend, application and release. The reasoning is mine to explain, not a summary of someone else's build. Client work under NDA is not listed; references are available during scoping.
MESSAGING · MOBILE APPLICATION
Pulse: private messaging
Flutter · NestJS · MongoDB
Problem
Mainstream messaging apps assume a good connection and a willingness to hand over a contact list. Neither holds for a private conversation on Ghanaian mobile data.
Approach
A Flutter client over a message service that treats delivery as a state machine: queued, sent, delivered, read. Messages written locally first and reconciled with the server on reconnect, so a dropped signal never loses a message or shows it twice.
Outcome
One codebase serving Android and iOS, with conversations that survive tunnels, dead zones and app restarts. [Add adoption or retention figures once you are ready to publish them.]
MESSAGING · MOBILE APPLICATION
Habor: anonymous conversation
Flutter · NestJS · MongoDB
Problem
People will say what is actually on their mind only when nothing traces back to them, which makes anonymity an architectural requirement, not a settings toggle.
Approach
No accounts and no identity to leak: ephemeral session identity, no contact-list access, and a data model that stores the minimum needed to route a conversation and forgets the rest. Moderation and rate limiting sit on the server so abuse is handled without unmasking anyone.
Outcome
A conversation app where the operator holds no personal data to hand over or lose. [Add usage figures or a moderation statistic once you are ready to publish them.]
EDUCATION · SCHOOL MANAGEMENT PLATFORM
AcademicTracker: school management
.NET · PostgreSQL · Next.js
Problem
Schools run on exercise books, WhatsApp broadcasts and one overworked spreadsheet. Nobody can answer who has paid, who was absent, or how a class performed last term without a manual count.
Approach
One model covering students, classes, teachers, attendance, assessments and fees, with role-based access so an owner, a head teacher, a class teacher and a parent each see only their own view. Term results and fee statements generate from the same records rather than being retyped.
Outcome
Enrolment, attendance, results and fees answerable from one screen, per term and per class. [Add school count or time-saved figures once you are ready to publish them.]