Engineering depth
you can verify.

The Problem

Hostel managers were running operations on paper registers and WhatsApp messages — no single place to answer who is in which room, what they owe, or which beds are actually free. Partial payments, refunds, room transfers, inventory, and maintenance requests were tracked manually and frequently inconsistent.

What We Built

A full-stack property management platform built around two core concepts: the Resident (a person who may stay multiple times) and the Stay (a single occupancy tied to a room, dates, and payment state). Administrators manage bookings, allocations, payments, refunds, inventory, and maintenance requests through a Django admin portal. Room status transitions automatically on check-in and checkout. Residents receive email notifications at key points via Brevo.

Key Features

• Resident & Stay separation — Returning residents keep their profile and history across multiple stays — no duplicate records.
• Room state machine — Rooms move through Available, Occupied, Maintenance, and Reserved automatically — no manual updates.
• Booking management — Reservations captured and tracked from request through check-in and checkout.
• Partial payment tracking — Running balance against total due per stay, so outstanding amounts are always clear.
• Refund workflow — Admin-approved refund requests with a full audit trail before any funds are marked returned.
• Inventory tracking — Property inventory — furniture, appliances, supplies — logged and monitored per unit.
• Maintenance requests — Issues logged, assigned, and tracked through resolution instead of getting lost in chat threads.
• Email notifications — Automated booking, payment, and checkout emails via Brevo HTTP API.

Status

Deployed and in active use. Backend on Render, frontend on Vercel. Replaced manual register-keeping for the property it was built for.

The Problem

Self-taught developers in Uganda lack structured progression — tutorials are scattered, there is no clear path from beginner to job-ready, and no way to demonstrate verifiable progress to employers.

What We Built

A learning platform with curriculum paths organised by skill level, progress tracking per module, and an assessment engine for quizzes and practical checkpoints. Built with React and Node.js, backed by PostgreSQL.

Key Features

• Structured learning paths — Curriculum organised by track and skill level — not a flat list of videos.
• Progress tracking — Per-module completion state so learners always know where they are and what is next.
• Assessment engine — Quizzes and checkpoints at key milestones to confirm understanding before advancing.
• Learner dashboard — At-a-glance view of active paths, completed modules, and upcoming assessments.

Status

In active development. Core data models and learning path structure are in place. Assessment and certification modules are in progress.

The Problem

School administrators manage students, fees, and attendance across multiple exercise books and spreadsheets. End-of-term reporting takes days; fee arrears are discovered too late; attendance data is lost between terms.

What We Built

A Django and React platform separating organisational structure (terms, classes, subjects) from transactional records (attendance entries, fee payments). Fee tracking is modelled as ledger entries — not a balance field — so payment history and partial instalments are always recoverable.

Key Features

• Student records — Centralised profiles with class, term, and guardian information — searchable and always current.
• Attendance capture — Per-class daily attendance with term-level summaries for reporting.
• Fee ledger — Instalments and partial payments tracked as entries against a term account — full history preserved.
• Academic reporting — End-of-term reports generated from structured data — not assembled manually from registers.

Status

Core data models for students, classes, and terms are in place. Attendance and fees modules are in active development. Not yet deployed to a production school.