Lectern
Product & Full-Stack Developer
About the Project
Lectern gives Nigerian university lecturers a single place to run their teaching — courses, materials, live sessions, recordings, assignments, and student enrolment — instead of stitching together WhatsApp groups, Google Drive, and ad-hoc Zoom links. It is built around tenants: a tenant is either an individual lecturer with a small support staff, or a whole department with a head of department, multiple lecturers, and shared students. The frontend is built; the backend is the next phase.
Key Highlights
- Designed a tenant model where individual and department accounts share one schema, differing only in seat limits and permissions
- Made matric number the student identity, so one student account works across courses at multiple tenants
- Built distinct route groups and permission surfaces for admin, lecturer, student, staff, and onboarding flows
- Specified Postgres row-level security as the tenant isolation mechanism rather than application-layer filtering
- Deliberately kept payment out of the platform — money changes hands offline, the platform handles access and content
Technical Challenges
The design decision I spent most time on was refusing to build two products. An individual lecturer and a whole department look like different customers, but modelling them as one tenant type with different limits meant not maintaining parallel permission logic forever. The other deliberate omission is payments: the target users already collect fees offline, and adding payment processing would have added compliance burden without solving a problem they actually have.