40 Final-Year Fullstack Project Ideas — A Student's Handbook

40 final-year project ideas for fullstack developer students, each with a description, key features, a database design and full table schemas. Campus systems, business, health, fintech, agriculture and community apps — plus how to choose, a recommended tech stack, a projects-by-sector finder, and guidance for a strong final-year defense. A practical handbook to pick and build your capstone.

A practical guide with 40 project descriptions, database designs, and table structures, covering campus, business, health, and community systems

Introduction

A final year project is your chance to show that you can design, build, and deploy a complete system. For a fullstack developer, a good project has:

A real problem that people on campus (or beyond) actually face.
A frontend (React, Vue, Angular, or Flutter/React Native for mobile).
A backend API (Node.js/Express, Django, Laravel, Spring Boot, or ASP.NET).
A well-designed relational database (PostgreSQL or MySQL are recommended).
Authentication and role-based access control (students, lecturers, admins).
Extra depth: payments, notifications, reports, analytics, or integrations.

How to Choose

Question	Why it matters
Can I find real users to test with?	Real feedback makes your defense stronger.
Is the scope achievable in 6 to 9 months?	Finish a smaller system well rather than a huge one badly.
Does it show database design skill?	Examiners love normalized schemas with clear relationships.
Does it have at least one "wow" feature?	QR codes, maps, payments, charts, or notifications set you apart.

Conventions Used in This Document

PK = Primary Key, FK = Foreign Key, UQ = Unique.
All tables should also include created_at and updated_at timestamps (omitted in listings to save space).
Passwords must always be stored hashed (bcrypt or argon2), never as plain text.
Where a users table appears, it is the central authentication table with a role column (or a separate roles table).

Suggested Common Tech Stack

Layer	Options
Frontend	React + Tailwind, Vue 3, Angular, Next.js
Backend	Node.js (Express/NestJS), Django REST, Laravel, Spring Boot
Database	PostgreSQL (preferred), MySQL, optionally Redis for caching
Auth	JWT + refresh tokens, or session cookies
Deployment	Docker, Render, Railway, VPS, or a campus server
Extras	Mobile Money / Stripe APIs, SMS/Email (Twilio, SendGrid), Google Maps API

Part 1: Campus and Student Projects

Campus Course Registration System
QR-Based Student Attendance Tracker
Online Examination and Quiz Platform
Library Management System
Hostel and Accommodation Booking System
Campus Marketplace (Buy and Sell)
Lost and Found Portal
Alumni Network and Tracer Portal
Final Year Project Management and Supervision System
Campus Event Management and Ticketing
Student Fees and Payment Management System
Campus Shuttle and Transport Tracking
Online Student Clearance System
Automated Timetable Scheduler
Campus Clinic Appointment and Records System
Internship and Job Placement Portal
Peer Tutoring and Study Group Platform
Student Complaint and Feedback System
Campus Canteen Pre-Ordering System
Research and Thesis Repository

Part 2: Business and Community Projects

Pharmacy Management and Inventory System
Blood Donation Management System
School Management System (Primary and Secondary)
Private Clinic and Hospital Management System
Point of Sale (POS) and Inventory System for Retail Shops
Telemedicine and Online Doctor Consultation Platform
SACCO and Village Savings Group Management System
Church and Community Organization Management System
Smart Farm Management and Agricultural Marketplace
Rental Property and Real Estate Management System
Hotel and Guest House Booking System
Restaurant Management and Table Reservation System
Employee, HR and Payroll Management System
Child Immunization and Community Health Tracker
Delivery and Boda-Boda Dispatch Platform
Learning Management System (LMS) for Schools and Training Centers
NGO Project, Donor and Grant Management System
CRM and Invoicing System for SMEs
Citizen Issue Reporting System for Local Government
Garage and Vehicle Fleet Management System

Projects by Sector (Quick Finder)

Sector	Projects
Health and Pharmacy	15, 21, 22, 24, 26, 34
Education and Schools	1, 2, 3, 4, 9, 14, 17, 20, 23, 36
Retail and Business	25, 31, 32, 33, 38, 40
Finance and Payments	11, 27, 37
Community, Faith and NGOs	8, 18, 28, 37, 39
Agriculture	29
Real Estate and Housing	5, 30, 31
Transport and Logistics	12, 35, 40
Student Life	6, 7, 10, 16, 19

PART 1: Campus and Student Projects (1 to 20)

Project 1: Campus Course Registration System

Description

A web platform where students register for courses each semester, view prerequisites, check credit-unit limits, and see their registration status. Lecturers see class lists, and administrators manage courses, semesters, and registration windows. The system should block clashes (timetable conflicts), enforce prerequisites, and cap credit units.

Key Features

Student registration with prerequisite and credit-limit validation
Admin-controlled registration windows per semester
Lecturer class lists exportable to PDF/Excel
Registration slip generation (PDF)
Email notifications on approval or rejection

Database Design

A many-to-many relationship between students and courses is resolved through a registrations table. Courses can require other courses (a self-referencing many-to-many relationship via course_prerequisites). Semesters scope everything.

Tables

Table	Columns	Notes
`users`	id (PK), email (UQ), password_hash, role, full_name	Roles: student, lecturer, admin
`students`	id (PK), user_id (FK, UQ), reg_number (UQ), program_id (FK), year_of_study	One-to-one with users
`lecturers`	id (PK), user_id (FK, UQ), staff_number (UQ), department_id (FK)
`departments`	id (PK), name, faculty_id (FK)
`faculties`	id (PK), name
`programs`	id (PK), name, department_id (FK), duration_years
`courses`	id (PK), code (UQ), title, credit_units, department_id (FK)
`course_prerequisites`	course_id (FK), prerequisite_id (FK)	Composite PK
`semesters`	id (PK), name, academic_year, reg_start, reg_end, is_active
`course_offerings`	id (PK), course_id (FK), semester_id (FK), lecturer_id (FK), capacity	A course offered in a semester
`registrations`	id (PK), student_id (FK), offering_id (FK), status, registered_at	UQ(student_id, offering_id)

Relationships: faculty → departments → programs → students; course ↔ course (prerequisites); student ↔ offering (registrations).

Project 2: QR-Based Student Attendance Tracker

Description

Lecturers start a class session and the system generates a time-limited, rotating QR code. Students scan it with their phones (via a web app or PWA) to mark attendance. Optional geofencing checks that the student is physically in the classroom. Reports show attendance percentage per student and per course, and flag students below the required threshold.

Key Features

Rotating QR codes (new token every 20-30 seconds) to prevent sharing
GPS/geofence validation
Attendance percentage dashboard and low-attendance alerts
Lecturer manual override with audit log
Export to Excel

Database Design

Each class meeting is a sessions row. Each scan creates an attendance_records row. QR tokens are stored with expiry to validate scans.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`students`	id, user_id (FK), reg_number, program_id
`lecturers`	id, user_id (FK), staff_number
`courses`	id, code, title, lecturer_id (FK)
`enrollments`	id, student_id (FK), course_id (FK)	UQ pair
`class_sessions`	id, course_id (FK), started_by (FK), start_time, end_time, latitude, longitude, radius_m
`qr_tokens`	id, session_id (FK), token (UQ), expires_at	Rotating tokens
`attendance_records`	id, session_id (FK), student_id (FK), scanned_at, latitude, longitude, status	UQ(session_id, student_id)
`attendance_overrides`	id, record_id (FK), changed_by (FK), old_status, new_status, reason	Audit trail
`notifications`	id, user_id (FK), message, is_read

Project 3: Online Examination and Quiz Platform

Description

Lecturers create question banks and schedule timed exams or quizzes. Students sit exams in a browser with a countdown timer, randomized questions, and auto-submission when time ends. Objective questions are auto-marked; essays go to the lecturer for manual grading. Includes basic anti-cheating measures such as tab-switch detection and question shuffling.

Key Features

Question bank with categories and difficulty
Randomized question and option order
Timer, auto-save answers, auto-submit
Auto-marking and manual marking for essays
Result analytics (average, pass rate, question difficulty analysis)

Database Design

Questions belong to a bank and can be reused across exams through a join table. Each student attempt stores its own answers.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`courses`	id, code, title
`question_banks`	id, course_id (FK), name, created_by (FK)
`questions`	id, bank_id (FK), type, text, marks, difficulty	type: mcq, true_false, essay
`question_options`	id, question_id (FK), option_text, is_correct
`exams`	id, course_id (FK), title, start_time, end_time, duration_min, total_marks, shuffle
`exam_questions`	exam_id (FK), question_id (FK), order_no	Composite PK
`exam_attempts`	id, exam_id (FK), student_id (FK), started_at, submitted_at, score, status	UQ(exam_id, student_id)
`attempt_answers`	id, attempt_id (FK), question_id (FK), selected_option_id (FK, nullable), answer_text, marks_awarded
`proctor_events`	id, attempt_id (FK), event_type, occurred_at	e.g. tab_switch

Project 4: Library Management System

Description

A system for managing a campus library: cataloging books, issuing and returning them, tracking fines, handling reservations, and searching the catalog online. Includes barcode support so librarians can scan books and student ID cards. Students can reserve books, renew loans, and see their borrowing history.

Key Features

Catalog with search and filters (title, author, ISBN, category)
Issue/return with barcode scanning
Automatic fine calculation for overdue books
Reservations and renewals
Digital resources (PDF e-books) section

Database Design

Distinguish a book title (bibliographic record) from a book copy (physical item). Loans link members to copies.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	Roles: member, librarian, admin
`members`	id, user_id (FK), member_no (UQ), type, status	Student/staff
`authors`	id, name, bio
`categories`	id, name
`books`	id, isbn (UQ), title, publisher, year, category_id (FK), description
`book_authors`	book_id (FK), author_id (FK)	Many-to-many
`book_copies`	id, book_id (FK), barcode (UQ), shelf_location, condition, status
`loans`	id, copy_id (FK), member_id (FK), issued_at, due_date, returned_at, renewed_count
`reservations`	id, book_id (FK), member_id (FK), reserved_at, status
`fines`	id, loan_id (FK), amount, reason, is_paid, paid_at
`ebooks`	id, book_id (FK), file_url, access_level

Project 5: Hostel and Accommodation Booking System

Description

Manages campus hostels and off-campus approved accommodation. Students browse hostels, view available rooms, apply for a bed space, and pay a booking deposit. Wardens approve allocations, manage room inventory, and record maintenance issues. Landlords of private hostels can list their properties for admin approval.

Key Features

Room and bed inventory with real-time availability
Application, approval, and allocation workflow
Payment of deposit and rent (Mobile Money integration)
Maintenance request tracking
Photo galleries and map locations of hostels

Database Design

Hierarchy: hostel → floor/block → room → bed. Bookings attach a student to a bed for a period.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, warden, landlord, admin
`students`	id, user_id (FK), reg_number, gender	Gender matters for allocation
`hostels`	id, name, type, owner_id (FK), address, latitude, longitude, gender_policy	on-campus / private
`rooms`	id, hostel_id (FK), room_number, floor, type, price_per_semester, capacity
`beds`	id, room_id (FK), bed_label, status
`hostel_images`	id, hostel_id (FK), image_url
`bookings`	id, student_id (FK), bed_id (FK), semester_id (FK), status, booked_at
`payments`	id, booking_id (FK), amount, method, transaction_ref (UQ), status, paid_at
`maintenance_requests`	id, room_id (FK), reported_by (FK), description, status, resolved_at
`semesters`	id, name, start_date, end_date

Project 6: Campus Marketplace (Buy and Sell)

Description

A student-to-student marketplace where users can sell second-hand textbooks, electronics, clothing, and services (laundry, tutoring, graphic design). Includes in-app chat between buyer and seller, product ratings, favourites, and a reporting tool for suspicious listings. Moderators approve or remove items.

Key Features

Listings with multiple images, categories, and price negotiation
Real-time chat (WebSockets)
Seller ratings and reviews
Wishlist/favourites and search with filters
Report and moderation workflow

Database Design

Listings belong to sellers and categories. Conversations are tied to a listing and two participants. Reviews are tied to completed transactions.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, phone, avatar_url
`categories`	id, name, parent_id (FK, nullable)	Nested categories
`listings`	id, seller_id (FK), category_id (FK), title, description, price, condition, status
`listing_images`	id, listing_id (FK), image_url, is_primary
`favourites`	user_id (FK), listing_id (FK)	Composite PK
`conversations`	id, listing_id (FK), buyer_id (FK), seller_id (FK)
`messages`	id, conversation_id (FK), sender_id (FK), body, sent_at, is_read
`transactions`	id, listing_id (FK), buyer_id (FK), agreed_price, status, completed_at
`reviews`	id, transaction_id (FK, UQ), reviewer_id (FK), rating, comment
`reports`	id, listing_id (FK), reported_by (FK), reason, status, handled_by (FK)

Project 7: Lost and Found Portal

Description

A central place for reporting lost and found items on campus. Users post items with photos, location, and date. The system suggests possible matches between lost and found reports using category, keywords, date, and location similarity. Security offices verify ownership claims before handing items back.

Key Features

Report lost or found items with images and map pin
Automated match suggestions with a scoring algorithm
Claim and verification workflow (questions only the owner can answer)
Email/SMS notification when a potential match is found
Admin dashboard with statistics (most common lost items and hot-spots)

Database Design

Separate items for lost and found with a type column, and a matches table linking a lost report to a found report with a similarity score.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, phone
`item_categories`	id, name	Phones, ID cards, bags, keys...
`locations`	id, name, latitude, longitude	Campus places
`items`	id, reporter_id (FK), type, category_id (FK), title, description, location_id (FK), event_date, status	type: lost/found
`item_images`	id, item_id (FK), image_url
`matches`	id, lost_item_id (FK), found_item_id (FK), score, status	UQ pair
`claims`	id, found_item_id (FK), claimant_id (FK), proof_description, status, reviewed_by (FK)
`verification_questions`	id, found_item_id (FK), question, answer_hash
`notifications`	id, user_id (FK), message, is_read
`handover_logs`	id, claim_id (FK), handed_by (FK), handed_at, notes

Project 8: Alumni Network and Tracer Portal

Description

Connects graduates with the university. Alumni create profiles, share employment updates, post job openings, mentor current students, and donate to campus projects. The university uses it as a graduate tracer study tool to collect employability statistics for accreditation.

Key Features

Alumni profiles with employment history
Job postings and mentorship requests
Tracer survey with analytics (employment rate by program)
Announcements, newsletters, and events
Donation campaigns

Database Design

Alumni are linked to graduation records. Employment history is one-to-many. Survey responses feed analytics.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	alumni, student, admin
`alumni_profiles`	id, user_id (FK), program_id (FK), graduation_year, bio, linkedin_url, current_city
`programs`	id, name, department
`employment_history`	id, alumni_id (FK), company, position, start_date, end_date, industry
`job_posts`	id, posted_by (FK), title, company, description, deadline, status
`mentorships`	id, mentor_id (FK), mentee_id (FK), topic, status, started_at
`surveys`	id, title, description, opens_at, closes_at
`survey_questions`	id, survey_id (FK), question_text, type
`survey_responses`	id, survey_id (FK), alumni_id (FK), submitted_at
`survey_answers`	id, response_id (FK), question_id (FK), answer_text
`donation_campaigns`	id, title, goal_amount, deadline
`donations`	id, campaign_id (FK), donor_id (FK), amount, payment_ref

Project 9: Final Year Project Management and Supervision System

Description

A system to manage the entire final year project lifecycle: topic proposals, supervisor allocation, milestones, document submissions, supervisor feedback, meeting logs, defense scheduling, and final grading. It prevents duplicate topics and gives coordinators a bird's-eye view of every student's progress.

Key Features

Topic proposal submission and approval
Supervisor allocation with workload limits
Milestone tracking and deadline reminders
Document uploads with version history
Defense scheduling and panel scoring

Database Design

A project belongs to a student (or a group) and has one supervisor. Milestones, submissions, and meetings hang off the project. Defense scores connect panel members to projects.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, supervisor, coordinator, panelist
`students`	id, user_id (FK), reg_number, program_id (FK)
`supervisors`	id, user_id (FK), department_id (FK), max_students
`projects`	id, title, abstract, status, supervisor_id (FK), academic_year
`project_members`	project_id (FK), student_id (FK)	Supports group projects
`proposals`	id, project_id (FK), submitted_at, status, reviewer_comment
`milestones`	id, name, due_date, academic_year	e.g. Chapter 1, Prototype
`submissions`	id, project_id (FK), milestone_id (FK), file_url, version, submitted_at
`feedback`	id, submission_id (FK), supervisor_id (FK), comment, grade
`meetings`	id, project_id (FK), scheduled_at, agenda, minutes, attended
`defense_sessions`	id, project_id (FK), venue, defense_time
`defense_scores`	id, session_id (FK), panelist_id (FK), score, remarks

Project 10: Campus Event Management and Ticketing

Description

Lets clubs and departments create events, sell or issue tickets, and manage attendees. Students discover events on a calendar, RSVP, receive QR-code tickets, and get reminders. Organizers check people in at the gate by scanning tickets and view real-time attendance and sales reports.

Key Features

Event creation with ticket types (free, regular, VIP)
Online payments and QR-coded e-tickets
Gate check-in scanner (web or mobile)
Calendar view and reminders
Organizer analytics dashboard

Database Design

Events have many ticket types; orders contain tickets; each ticket has a unique code for check-in.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`organizations`	id, name, type, owner_id (FK)	Clubs, departments
`venues`	id, name, capacity, location
`events`	id, organization_id (FK), venue_id (FK), title, description, start_time, end_time, status
`ticket_types`	id, event_id (FK), name, price, quantity, sales_start, sales_end
`orders`	id, user_id (FK), total_amount, status, payment_ref
`tickets`	id, order_id (FK), ticket_type_id (FK), code (UQ), checked_in_at
`rsvps`	id, event_id (FK), user_id (FK), status
`event_staff`	event_id (FK), user_id (FK), role	Gate scanners
`reminders`	id, event_id (FK), user_id (FK), send_at, sent

Project 11: Student Fees and Payment Management System

Description

Handles tuition and other fee structures per program and semester, records payments (bank slips and Mobile Money), issues electronic receipts, tracks balances, and blocks result access or registration when fees are outstanding. Finance staff get reconciliation reports; students see their statements and can pay in installments.

Key Features

Fee structure configuration per program/year
Mobile Money and card payment integration (webhook handling)
Installment plans and scholarships/waivers
PDF receipts and statements
Defaulters report and clearance flag

Database Design

Fee items are grouped into fee structures. Each student gets an invoice per semester, and payments are allocated against invoices.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, bursar, admin
`students`	id, user_id (FK), reg_number, program_id (FK)
`fee_items`	id, name, description	Tuition, library, ICT...
`fee_structures`	id, program_id (FK), semester_id (FK), year_of_study
`fee_structure_items`	structure_id (FK), fee_item_id (FK), amount
`invoices`	id, student_id (FK), semester_id (FK), total_amount, balance, status
`invoice_lines`	id, invoice_id (FK), fee_item_id (FK), amount
`payments`	id, invoice_id (FK), amount, method, transaction_ref (UQ), paid_at, recorded_by (FK)
`receipts`	id, payment_id (FK, UQ), receipt_no (UQ), issued_at
`waivers`	id, student_id (FK), semester_id (FK), type, amount, approved_by (FK)	Scholarships
`installment_plans`	id, invoice_id (FK), due_date, amount, is_paid

Project 12: Campus Shuttle and Transport Tracking

Description

Tracks campus buses or shuttles in real time. Drivers share GPS location from a phone, and students see buses on a map with estimated arrival times at each stop. Includes route and schedule management, seat reservations for peak times, and incident reports.

Key Features

Live map with bus positions (WebSockets)
ETA calculation per stop
Route, stop, and schedule administration
Optional seat booking and QR boarding passes
Trip history and driver performance reports

Database Design

Routes consist of ordered stops. Trips are scheduled runs of a bus on a route by a driver. Location pings are stored as a high-volume time series.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, driver, admin
`drivers`	id, user_id (FK), license_no, phone
`buses`	id, plate_number (UQ), capacity, status
`routes`	id, name, description
`stops`	id, name, latitude, longitude
`route_stops`	route_id (FK), stop_id (FK), stop_order, offset_minutes	Composite PK
`schedules`	id, route_id (FK), bus_id (FK), driver_id (FK), departure_time, days_of_week
`trips`	id, schedule_id (FK), trip_date, started_at, ended_at, status
`location_pings`	id, trip_id (FK), latitude, longitude, speed, recorded_at	Index on (trip_id, recorded_at)
`seat_bookings`	id, trip_id (FK), student_id (FK), seat_no, status
`incidents`	id, trip_id (FK), reported_by (FK), description, severity

Project 13: Online Student Clearance System

Description

Replaces paper-based clearance forms that students carry from office to office. A graduating student starts a clearance request, and it flows through departments (library, finance, hostel, sports, faculty, records). Each office approves, rejects with a reason, or lists items to settle. When all approvals are in, a clearance certificate is generated.

Key Features

Configurable clearance workflow with ordered or parallel steps
Approval/rejection with comments
Live progress tracker for the student
Auto-checks (e.g., unpaid fees or unreturned books block approval)
Digital certificate with QR verification

Database Design

A clearance request spawns one approval row per department. Workflow definitions are stored in tables so admins can change them without code changes.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`students`	id, user_id (FK), reg_number, program_id (FK), graduation_year
`clearance_departments`	id, name, officer_id (FK), step_order
`clearance_requests`	id, student_id (FK), status, submitted_at, completed_at
`clearance_approvals`	id, request_id (FK), department_id (FK), status, comment, acted_by (FK), acted_at	UQ(request_id, department_id)
`outstanding_items`	id, approval_id (FK), description, amount, is_resolved
`certificates`	id, request_id (FK, UQ), certificate_no (UQ), qr_token, issued_at
`audit_logs`	id, user_id (FK), action, entity, entity_id, created_at

Project 14: Automated Timetable Scheduler

Description

Generates class and exam timetables automatically while respecting constraints: no lecturer or room double-booking, room capacity, lecturer availability, and student group clashes. Administrators can run the generator (using a constraint-solving or genetic algorithm), review conflicts, and manually adjust.

Key Features

Constraint-based automatic generation
Conflict detection and reporting
Drag-and-drop manual adjustment
Personalized timetables per student, lecturer, and room
Export to PDF and calendar (iCal)

Database Design

Time slots, rooms, lecturers, and student groups are resources. Timetable entries bind a course session to a slot, room, and lecturer. Constraints are stored as data.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`lecturers`	id, user_id (FK), department_id (FK), max_hours_per_week
`courses`	id, code, title, weekly_hours, requires_lab
`student_groups`	id, program_id (FK), year, size
`group_courses`	group_id (FK), course_id (FK)
`course_lecturers`	course_id (FK), lecturer_id (FK)
`rooms`	id, name, capacity, type (lecture/lab)
`time_slots`	id, day_of_week, start_time, end_time
`lecturer_availability`	lecturer_id (FK), slot_id (FK), is_available
`timetable_versions`	id, semester_id (FK), name, status, generated_at	Draft vs published
`timetable_entries`	id, version_id (FK), course_id (FK), group_id (FK), lecturer_id (FK), room_id (FK), slot_id (FK)	UQ constraints on (version, room, slot) and (version, lecturer, slot)
`conflicts`	id, version_id (FK), type, description, resolved

Project 15: Campus Clinic Appointment and Records System

Description

Digitizes the campus health center. Students book appointments, nurses record triage vitals, doctors enter diagnoses and prescriptions, and the pharmacy dispenses medicine and manages stock. Records are confidential and accessible only to authorized medical staff. Reports show common illnesses and stock levels.

Key Features

Online appointment booking and queue management
Electronic medical records with strict access control and audit logs
Prescription and pharmacy stock management
Referral letters (PDF)
Health statistics dashboard (anonymized)

Database Design

A patient has many visits; each visit includes vitals, diagnoses, and prescriptions. Pharmacy inventory is linked to dispensing.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, nurse, doctor, pharmacist, admin
`patients`	id, user_id (FK), reg_number, blood_group, allergies, emergency_contact
`staff`	id, user_id (FK), specialization, license_no
`appointments`	id, patient_id (FK), doctor_id (FK), scheduled_at, reason, status
`visits`	id, appointment_id (FK), patient_id (FK), checked_in_at, status
`vitals`	id, visit_id (FK), temperature, blood_pressure, pulse, weight, recorded_by (FK)
`diagnoses`	id, visit_id (FK), doctor_id (FK), icd_code, description, notes
`medicines`	id, name, form, strength, unit_price
`stock_batches`	id, medicine_id (FK), quantity, expiry_date, received_at
`prescriptions`	id, visit_id (FK), medicine_id (FK), dosage, duration, quantity
`dispensing`	id, prescription_id (FK), pharmacist_id (FK), quantity_given, dispensed_at
`access_logs`	id, user_id (FK), patient_id (FK), action, accessed_at	Privacy audit

Project 16: Internship and Job Placement Portal

Description

Links students with employers offering internships and graduate jobs. Students build profiles and CVs and apply with one click. Employers post opportunities and review applicants. The career office manages employer partnerships, approves postings, and tracks placement statistics. Includes skill-based job recommendations.

Key Features

Student profile and CV builder (PDF export)
Employer registration and approval
Application tracking pipeline (applied, shortlisted, interview, offer)
Skill matching and recommendations
Interview scheduling and placement reports

Database Design

Skills form many-to-many relationships with students and jobs, which enables matching. Applications link students and jobs with a status workflow.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, employer, admin
`student_profiles`	id, user_id (FK), program_id (FK), gpa, summary, cv_url
`education`	id, student_id (FK), institution, qualification, start_year, end_year
`experiences`	id, student_id (FK), company, role, description, start_date, end_date
`skills`	id, name (UQ)
`student_skills`	student_id (FK), skill_id (FK), level
`employers`	id, user_id (FK), company_name, industry, website, is_verified
`jobs`	id, employer_id (FK), title, type, description, location, deadline, status	internship/full-time
`job_skills`	job_id (FK), skill_id (FK), is_required
`applications`	id, job_id (FK), student_id (FK), cover_letter, status, applied_at	UQ(job_id, student_id)
`interviews`	id, application_id (FK), scheduled_at, mode, link_or_venue, outcome
`placements`	id, application_id (FK, UQ), start_date, end_date

Project 17: Peer Tutoring and Study Group Platform

Description

Connects students who need help with students who excel in a subject. Tutors set topics, rates (or volunteer hours), and availability. Students request sessions, join video calls, and rate the experience. Also supports study groups with shared notes and scheduled meetings.

Key Features

Tutor profiles with subjects and availability calendar
Session booking and reminders
Embedded video call link (Jitsi/WebRTC)
Study groups with discussion boards and file sharing
Ratings, reviews, and tutor leaderboard

Database Design

Tutors teach subjects (many-to-many) and publish availability slots. Bookings reserve slots. Groups have members, posts, and resources.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, full_name
`subjects`	id, name, department
`tutor_profiles`	id, user_id (FK), bio, hourly_rate, rating_avg, is_verified
`tutor_subjects`	tutor_id (FK), subject_id (FK)
`availability_slots`	id, tutor_id (FK), start_time, end_time, is_booked
`tutoring_sessions`	id, slot_id (FK), student_id (FK), subject_id (FK), topic, meeting_link, status
`session_reviews`	id, session_id (FK, UQ), rating, comment
`study_groups`	id, name, subject_id (FK), owner_id (FK), description, is_private
`group_members`	group_id (FK), user_id (FK), role, joined_at
`group_posts`	id, group_id (FK), author_id (FK), body, created_at
`group_resources`	id, group_id (FK), uploaded_by (FK), title, file_url
`group_meetings`	id, group_id (FK), scheduled_at, location_or_link, agenda

Project 18: Student Complaint and Feedback System

Description

A structured channel for students to submit complaints (missing marks, facilities, harassment, lecturer issues) and suggestions, optionally anonymously. Complaints are routed to the right office, tracked with a ticket number, escalated automatically if unresolved after a set time, and closed with a documented resolution. Management gets trend analytics.

Key Features

Anonymous or identified submissions with attachments
Automatic routing by category
SLA timers and auto-escalation
Ticket conversation thread and status tracking
Analytics (resolution time, top issues per department)

Database Design

Tickets belong to categories, which map to responsible departments. A comment thread and a status history table provide full traceability.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`departments`	id, name, head_id (FK)
`complaint_categories`	id, name, department_id (FK), sla_hours
`complaints`	id, ticket_no (UQ), submitter_id (FK, nullable), is_anonymous, category_id (FK), subject, description, priority, status, assigned_to (FK)
`complaint_attachments`	id, complaint_id (FK), file_url
`complaint_comments`	id, complaint_id (FK), author_id (FK), body, is_internal
`status_history`	id, complaint_id (FK), old_status, new_status, changed_by (FK), changed_at
`escalations`	id, complaint_id (FK), escalated_to (FK), reason, escalated_at
`resolutions`	id, complaint_id (FK, UQ), summary, resolved_by (FK), resolved_at
`satisfaction_ratings`	id, complaint_id (FK, UQ), rating, comment

Project 19: Campus Canteen Pre-Ordering System

Description

Students and staff order food from campus canteens or kiosks in advance, pay online, and pick up at a scheduled time without queuing. Vendors manage menus, stock, and incoming orders on a kitchen dashboard. Supports loyalty points and daily specials.

Key Features

Multi-vendor menus with categories and photos
Cart, scheduled pickup, and Mobile Money payment
Real-time order status (placed, preparing, ready, collected)
Vendor dashboard and sales reports
Loyalty points and promotions

Database Design

Vendors own menu items. Orders contain order items, which snapshot the price at the time of ordering to keep history accurate.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, phone	customer, vendor, admin
`vendors`	id, user_id (FK), name, location, opening_time, closing_time, is_open
`menu_categories`	id, vendor_id (FK), name
`menu_items`	id, vendor_id (FK), category_id (FK), name, description, price, image_url, stock, is_available
`carts`	id, user_id (FK), vendor_id (FK)
`cart_items`	id, cart_id (FK), menu_item_id (FK), quantity
`orders`	id, user_id (FK), vendor_id (FK), total, pickup_time, status, placed_at
`order_items`	id, order_id (FK), menu_item_id (FK), quantity, unit_price	Price snapshot
`payments`	id, order_id (FK, UQ), method, transaction_ref, status
`loyalty_accounts`	id, user_id (FK, UQ), points
`loyalty_transactions`	id, account_id (FK), order_id (FK), points, type
`promotions`	id, vendor_id (FK), code, discount_percent, valid_from, valid_to

Project 20: Research and Thesis Repository

Description

A searchable institutional repository where students submit theses, dissertations, and research papers. Supervisors and librarians review submissions before publication. The system includes full-text search, citation export (BibTeX/APA), download statistics, and a basic similarity check against existing documents to discourage plagiarism.

Key Features

Submission workflow with review and approval
Full-text search (PostgreSQL full-text search or Elasticsearch)
Metadata (keywords, abstract, supervisor, year, department)
Similarity scoring against existing repository documents
Access control (open, campus-only, embargoed) and download analytics

Database Design

Documents have metadata, authors, keywords, and versions. Access rules and download logs enable analytics. Similarity results are stored per submission.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	student, supervisor, librarian, admin
`departments`	id, name, faculty
`documents`	id, title, abstract, type, department_id (FK), year, access_level, embargo_until, status, search_vector	type: thesis, paper, dissertation
`document_authors`	document_id (FK), user_id (FK), author_order
`document_supervisors`	document_id (FK), supervisor_id (FK)
`keywords`	id, term (UQ)
`document_keywords`	document_id (FK), keyword_id (FK)
`document_files`	id, document_id (FK), file_url, version, file_size, uploaded_at
`reviews`	id, document_id (FK), reviewer_id (FK), decision, comments, reviewed_at
`similarity_reports`	id, document_id (FK), compared_with_id (FK), score, generated_at
`downloads`	id, document_id (FK), user_id (FK, nullable), downloaded_at, ip_address
`citations_cache`	document_id (FK), bibtex, apa	Pre-generated formats

PART 2: Business and Community Projects (21 to 40)

These projects serve real organizations such as pharmacies, clinics, schools, shops, farms, NGOs, and community groups. They are excellent if you want to deploy your system to an actual client after graduation.

Project 21: Pharmacy Management and Inventory System

Description

A complete system for running a retail or hospital pharmacy. It tracks medicine stock by batch and expiry date, handles sales with a point-of-sale screen, manages suppliers and purchase orders, validates prescriptions, and alerts staff about low stock and soon-to-expire drugs. Owners see profit and loss reports, and the pharmacist can record controlled-drug dispensing for compliance.

Key Features

Batch and expiry tracking with FEFO (first-expiry, first-out) selling
POS with barcode scanning, discounts, and receipts
Low-stock and near-expiry alerts (email/SMS)
Supplier management and purchase orders
Prescription records and controlled-drug register
Sales, profit, and stock valuation reports

Database Design

Medicines (products) have many batches. Sales items deduct from specific batches. Purchases add batches. A prescription can be linked to a sale.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	owner, pharmacist, cashier
`branches`	id, name, address, phone	Supports multi-branch
`medicine_categories`	id, name	Antibiotics, analgesics...
`medicines`	id, name, generic_name, category_id (FK), form, strength, barcode (UQ), reorder_level, is_controlled, selling_price
`suppliers`	id, name, phone, email, address
`purchase_orders`	id, supplier_id (FK), branch_id (FK), order_date, status, total
`purchase_order_items`	id, po_id (FK), medicine_id (FK), quantity, unit_cost
`stock_batches`	id, medicine_id (FK), branch_id (FK), batch_no, expiry_date, quantity_remaining, unit_cost
`customers`	id, name, phone, address	Optional
`prescriptions`	id, customer_id (FK), doctor_name, issued_date, image_url
`sales`	id, branch_id (FK), cashier_id (FK), customer_id (FK, nullable), prescription_id (FK, nullable), total, payment_method, sold_at
`sale_items`	id, sale_id (FK), medicine_id (FK), batch_id (FK), quantity, unit_price
`stock_adjustments`	id, batch_id (FK), quantity_change, reason, adjusted_by (FK)	Damage, expiry, theft
`controlled_drug_register`	id, sale_item_id (FK), patient_name, id_number, dispensed_by (FK)

Project 22: Blood Donation Management System

Description

A platform that links blood donors, hospitals, and blood banks. Donors register with blood group and location, get reminders when they are eligible to donate again, and receive emergency alerts when their blood type is urgently needed nearby. Hospitals post requests, and blood banks manage inventory of blood units with expiry dates. Donation drives can be organized and tracked.

Key Features

Donor registration with eligibility rules (e.g., 3-4 months between donations)
Emergency request broadcast to matching donors by blood group and distance
Blood bank inventory by blood group, component, and expiry
Donation drive/camp scheduling and attendance
SMS/WhatsApp/email notifications
Dashboards showing shortages and donation trends

Database Design

Donors have many donations. Each donation produces blood units stored in banks. Requests from hospitals are matched with donors and units.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	donor, hospital, bank_staff, admin
`blood_groups`	id, name	A+, A-, B+, O-, AB+...
`donors`	id, user_id (FK), blood_group_id (FK), dob, gender, weight, phone, latitude, longitude, last_donation_date, is_available
`health_screenings`	id, donor_id (FK), screened_at, hemoglobin, blood_pressure, result, screened_by (FK)
`hospitals`	id, user_id (FK), name, address, latitude, longitude, phone, is_verified
`blood_banks`	id, name, address, phone, manager_id (FK)
`donation_drives`	id, title, venue, drive_date, organizer_id (FK), target_units
`donations`	id, donor_id (FK), bank_id (FK), drive_id (FK, nullable), donated_at, volume_ml, status
`blood_units`	id, donation_id (FK), blood_group_id (FK), component, collected_at, expiry_date, status	whole blood, plasma, platelets
`blood_requests`	id, hospital_id (FK), blood_group_id (FK), units_needed, urgency, patient_ref, status, needed_by
`request_responses`	id, request_id (FK), donor_id (FK), response, responded_at
`unit_issues`	id, unit_id (FK), request_id (FK), issued_at, issued_by (FK)
`notifications`	id, user_id (FK), channel, message, sent_at

Project 23: School Management System (Primary and Secondary)

Description

An all-in-one platform for schools: admissions, student records, class and subject allocation, attendance, exams and report cards, fee collection, parent portal, and announcements. Teachers record marks, the system computes grades and class positions, and parents log in to see results, fees, and attendance for their children.

Key Features

Admission and student profile management
Class, stream, subject, and teacher allocation
Daily attendance with parent SMS alerts for absences
Marks entry, grading scales, and automatic report card PDFs
Fee structures, payments, and balances
Parent portal and school-wide announcements

Database Design

A student belongs to a class in an academic year (enrollment). Marks are tied to student, subject, and exam. Parents link to students via a guardian table.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	admin, teacher, parent, student, bursar
`academic_years`	id, name, start_date, end_date, is_current
`terms`	id, academic_year_id (FK), name, start_date, end_date
`classes`	id, name, level, stream
`subjects`	id, name, code
`class_subjects`	id, class_id (FK), subject_id (FK), teacher_id (FK)
`teachers`	id, user_id (FK), staff_no, phone, qualification
`students`	id, user_id (FK, nullable), admission_no (UQ), full_name, dob, gender, photo_url
`guardians`	id, user_id (FK), full_name, phone, occupation
`student_guardians`	student_id (FK), guardian_id (FK), relationship
`enrollments`	id, student_id (FK), class_id (FK), academic_year_id (FK)	UQ(student, year)
`attendance`	id, enrollment_id (FK), date, status, recorded_by (FK)
`exams`	id, term_id (FK), name, type, weight_percent
`marks`	id, exam_id (FK), enrollment_id (FK), subject_id (FK), score	UQ triple
`grading_scales`	id, min_score, max_score, grade, remark
`fee_invoices`	id, enrollment_id (FK), term_id (FK), total, balance
`fee_payments`	id, invoice_id (FK), amount, method, reference, paid_at
`announcements`	id, title, body, audience, posted_by (FK), posted_at

Project 24: Private Clinic and Hospital Management System

Description

Supports a small to medium hospital or private clinic from reception to billing. Receptionists register patients and issue queue numbers. Nurses capture vitals; doctors record consultations, order lab tests, and prescribe medicine. The lab enters results, the pharmacy dispenses, and the cashier generates a consolidated bill. Management views revenue and disease statistics.

Key Features

Patient registration with unique patient numbers
Queue and appointment management
Consultation notes, lab orders, and results
Prescriptions linked to in-house pharmacy
Billing with insurance and cash options, receipts, and invoices
Admission, ward, and bed management (optional advanced module)

Database Design

A visit (encounter) is the central record. Lab orders, prescriptions, services, and bills all link to the visit.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	receptionist, nurse, doctor, lab_tech, pharmacist, cashier, admin
`patients`	id, patient_no (UQ), full_name, dob, gender, phone, address, next_of_kin, insurance_id (FK, nullable)
`insurers`	id, name, contact, coverage_percent
`visits`	id, patient_id (FK), visit_date, type, status, queue_no	OPD/IPD
`vitals`	id, visit_id (FK), temperature, bp, pulse, weight, height, recorded_by (FK)
`consultations`	id, visit_id (FK), doctor_id (FK), complaints, findings, diagnosis, plan
`lab_tests`	id, name, price, normal_range	Catalog
`lab_orders`	id, visit_id (FK), test_id (FK), ordered_by (FK), status
`lab_results`	id, order_id (FK, UQ), result_value, remarks, entered_by (FK), entered_at
`drugs`	id, name, price, stock_qty
`prescriptions`	id, visit_id (FK), drug_id (FK), dosage, duration, quantity, dispensed
`services`	id, name, price	Consultation fee, dressing...
`bills`	id, visit_id (FK), total, insurer_amount, patient_amount, status
`bill_items`	id, bill_id (FK), item_type, item_id, description, amount
`payments`	id, bill_id (FK), amount, method, paid_at, received_by (FK)
`wards`	id, name, type
`beds`	id, ward_id (FK), bed_no, status
`admissions`	id, visit_id (FK), bed_id (FK), admitted_at, discharged_at, discharge_notes

Project 25: Point of Sale (POS) and Inventory System for Retail Shops

Description

A POS and stock management web app for small supermarkets, hardware shops, and boutiques. Cashiers ring up sales using barcode scanners, accept cash or mobile money, and print receipts. Owners track stock levels, suppliers, expenses, employee sales, and profit per product. Works across multiple branches and can sync after brief internet outages.

Key Features

Fast POS interface with barcode scanning and keyboard shortcuts
Stock-in, stock transfers between branches, and stocktaking
Supplier purchases and credit tracking
Customer credit (debt) tracking and loyalty
Expense recording and profit and loss reports
Offline-first mode (PWA with IndexedDB sync)

Database Design

Products have stock per branch. Sales, purchases, and transfers are recorded as documents with line items, and a stock-movements ledger gives a full audit trail.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, branch_id (FK)	owner, manager, cashier
`branches`	id, name, address
`categories`	id, name
`products`	id, sku (UQ), barcode (UQ), name, category_id (FK), cost_price, selling_price, reorder_level
`branch_stock`	product_id (FK), branch_id (FK), quantity	Composite PK
`stock_movements`	id, product_id (FK), branch_id (FK), type, quantity, reference_id, created_at	Ledger
`suppliers`	id, name, phone, balance_owed
`purchases`	id, supplier_id (FK), branch_id (FK), total, paid_amount, purchased_at
`purchase_items`	id, purchase_id (FK), product_id (FK), quantity, unit_cost
`customers`	id, name, phone, credit_limit, balance
`sales`	id, branch_id (FK), cashier_id (FK), customer_id (FK, nullable), subtotal, discount, total, payment_method, sold_at
`sale_items`	id, sale_id (FK), product_id (FK), quantity, unit_price, unit_cost	Cost snapshot for profit
`stock_transfers`	id, from_branch_id (FK), to_branch_id (FK), status, created_by (FK)
`expenses`	id, branch_id (FK), category, amount, description, spent_at
`shifts`	id, cashier_id (FK), opened_at, closed_at, opening_cash, closing_cash	Till reconciliation

Project 26: Telemedicine and Online Doctor Consultation Platform

Description

Lets patients in remote areas consult doctors by chat or video. Patients describe symptoms, choose a doctor or specialty, book a slot, pay, and join a consultation. Doctors issue e-prescriptions and follow-up notes. Patients can upload photos or lab reports and keep a personal health history.

Key Features

Doctor profiles, specialties, and availability calendars
Video consultation (WebRTC/Jitsi) and secure chat
Appointment booking with online payment
E-prescriptions (PDF) and follow-up reminders
Patient health records and uploads
Ratings and doctor verification by admin

Database Design

Appointments connect patients to doctors via availability slots. Each consultation produces notes, prescriptions, and optional messages.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	patient, doctor, admin
`patients`	id, user_id (FK), dob, gender, blood_group, allergies, phone
`specialties`	id, name
`doctors`	id, user_id (FK), specialty_id (FK), license_no, bio, fee, is_verified, rating_avg
`availability_slots`	id, doctor_id (FK), start_time, end_time, is_booked
`appointments`	id, patient_id (FK), doctor_id (FK), slot_id (FK, UQ), mode, reason, status, meeting_link
`payments`	id, appointment_id (FK, UQ), amount, method, transaction_ref, status
`consultations`	id, appointment_id (FK, UQ), symptoms, diagnosis, advice, follow_up_date
`prescriptions`	id, consultation_id (FK), medicine, dosage, duration, instructions
`messages`	id, appointment_id (FK), sender_id (FK), body, attachment_url, sent_at
`medical_documents`	id, patient_id (FK), title, file_url, uploaded_at
`reviews`	id, appointment_id (FK, UQ), rating, comment

Project 27: SACCO and Village Savings Group Management System

Description

Digitizes savings groups, SACCOs, and microfinance associations. Members make savings deposits, buy shares, request loans, and repay with interest. The system calculates interest schedules, tracks guarantors, applies penalties for late payments, produces member statements, and gives treasurers instant balance sheets. Members get SMS confirmations for every transaction.

Key Features

Member registration and KYC documents
Savings, shares, and withdrawals ledger
Loan application, guarantor approval, and committee approval workflow
Automatic repayment schedules (flat or reducing balance)
Penalties, dividends, and annual interest distribution
Financial reports (trial balance, portfolio at risk)

Database Design

Each member has multiple accounts (savings, shares). All money movement is stored in a transactions ledger. Loans have schedules, repayments, and guarantors.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	member, treasurer, chair, admin
`members`	id, user_id (FK), member_no (UQ), full_name, national_id, phone, address, join_date, status
`member_documents`	id, member_id (FK), type, file_url
`account_types`	id, name, min_balance, interest_rate	savings, shares, fixed
`accounts`	id, member_id (FK), account_type_id (FK), balance
`transactions`	id, account_id (FK), type, amount, balance_after, reference, recorded_by (FK), created_at	Ledger
`loan_products`	id, name, interest_rate, interest_method, max_amount, max_term_months, penalty_rate
`loans`	id, member_id (FK), product_id (FK), amount, term_months, status, applied_at, approved_by (FK), disbursed_at
`loan_guarantors`	id, loan_id (FK), guarantor_id (FK), amount_guaranteed, status
`loan_schedules`	id, loan_id (FK), due_date, principal_due, interest_due, paid, paid_at
`loan_repayments`	id, loan_id (FK), amount, paid_at, method
`penalties`	id, loan_id (FK), schedule_id (FK), amount, applied_at
`meetings`	id, date, agenda, minutes
`meeting_attendance`	meeting_id (FK), member_id (FK), status
`dividends`	id, year, member_id (FK), amount, paid_at

Project 28: Church and Community Organization Management System

Description

Helps churches, mosques, clubs, and community-based organizations manage members, families, small groups, attendance, offerings and tithes, pledges, events, and communication. Leaders send bulk SMS or email to groups, and the treasurer produces transparent financial reports for the congregation.

Key Features

Member and household registry
Small groups, ministries, and leader roles
Service attendance (QR or manual)
Giving: tithes, offerings, pledges, and receipts
Event calendar and volunteer scheduling
Bulk SMS/email and birthday/anniversary reminders

Database Design

Members belong to households and many groups. Contributions and pledges link to members and funds. Events have volunteers and attendance.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role
`households`	id, name, address
`members`	id, user_id (FK, nullable), household_id (FK), full_name, gender, dob, phone, marital_status, join_date, status
`groups`	id, name, type, leader_id (FK), description
`group_members`	group_id (FK), member_id (FK), role, joined_at
`services`	id, name, service_date, type
`attendance`	id, service_id (FK), member_id (FK)	UQ pair
`funds`	id, name, description	Tithe, building fund...
`contributions`	id, member_id (FK, nullable), fund_id (FK), amount, method, given_at, recorded_by (FK)
`pledges`	id, member_id (FK), fund_id (FK), amount, due_date, fulfilled_amount
`events`	id, title, description, start_time, end_time, venue
`event_volunteers`	event_id (FK), member_id (FK), task
`expenses`	id, fund_id (FK), amount, description, approved_by (FK), spent_at
`messages_sent`	id, group_id (FK), channel, body, sent_by (FK), sent_at

Project 29: Smart Farm Management and Agricultural Marketplace

Description

Helps small-scale farmers record fields, crops, planting dates, inputs, expenses, and harvests. It then connects them to buyers through a marketplace where produce can be listed with quantity, price, and location. The system gives farming calendars and weather alerts, and calculates profit per crop and per season.

Key Features

Farm, plot, and crop season records
Input, labor, and expense tracking with profit analysis
Livestock records (optional: vaccinations, breeding, milk and egg production)
Produce marketplace with buyer inquiries and orders
Weather API integration and planting reminders
SMS/USSD-friendly design for farmers with basic phones

Database Design

A farmer owns farms with plots. Each plot has crop seasons, with activities, costs, and harvests. Harvests can be listed for sale.

Tables

Table	Columns	Notes
`users`	id, email/phone, password_hash, role	farmer, buyer, extension_officer, admin
`farmers`	id, user_id (FK), full_name, district, village, phone
`farms`	id, farmer_id (FK), name, size_acres, latitude, longitude
`plots`	id, farm_id (FK), name, size_acres, soil_type
`crops`	id, name, variety, growth_days	Catalog
`crop_seasons`	id, plot_id (FK), crop_id (FK), planting_date, expected_harvest, status
`activities`	id, season_id (FK), type, description, activity_date	Planting, weeding, spraying
`inputs`	id, name, type, unit	Seeds, fertilizer, pesticide
`input_usage`	id, season_id (FK), input_id (FK), quantity, cost
`expenses`	id, season_id (FK), category, amount, spent_at
`harvests`	id, season_id (FK), quantity, unit, quality_grade, harvested_at
`produce_listings`	id, harvest_id (FK), farmer_id (FK), price_per_unit, quantity_available, pickup_location, status
`buyer_orders`	id, listing_id (FK), buyer_id (FK), quantity, total_price, status
`livestock`	id, farm_id (FK), species, tag_no, dob, status	Optional module
`advisory_messages`	id, extension_officer_id (FK), crop_id (FK), message, sent_at

Project 30: Rental Property and Real Estate Management System

Description

Helps landlords and property agents manage buildings, units, tenants, leases, rent invoices, payments, and maintenance. Tenants get monthly invoices, pay through mobile money, and submit repair requests. Landlords see occupancy, arrears, and income per property. A public listing section advertises vacant units.

Key Features

Property and unit management with photos and amenities
Lease agreements with start/end dates and deposits
Automated monthly invoicing and arrears reminders
Payment tracking and receipts
Maintenance request workflow with contractor assignment
Public vacancy listings with inquiries

Database Design

Properties contain units. A lease links a tenant to a unit for a period. Invoices generate from leases; payments settle invoices.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	landlord, agent, tenant, admin
`properties`	id, owner_id (FK), name, address, latitude, longitude, type
`units`	id, property_id (FK), unit_no, bedrooms, bathrooms, rent_amount, status
`unit_images`	id, unit_id (FK), image_url
`tenants`	id, user_id (FK), full_name, national_id, phone, employer
`leases`	id, unit_id (FK), tenant_id (FK), start_date, end_date, rent_amount, deposit, status
`invoices`	id, lease_id (FK), period_month, amount, due_date, status	UQ(lease, period)
`payments`	id, invoice_id (FK), amount, method, transaction_ref, paid_at
`maintenance_requests`	id, unit_id (FK), tenant_id (FK), description, priority, status, assigned_to (FK)
`contractors`	id, name, trade, phone
`inquiries`	id, unit_id (FK), name, phone, message, created_at
`expenses`	id, property_id (FK), category, amount, description, spent_at
`documents`	id, lease_id (FK), type, file_url	Signed lease, ID copies

Project 31: Hotel and Guest House Booking System

Description

Online booking and front-desk management for hotels, lodges, and guest houses. Guests search availability by dates and room type, book and pay online. Staff handle check-in/out, housekeeping status, room service charges, and invoices. Includes dynamic pricing for seasons and weekends.

Key Features

Availability search and online reservation with payment
Room types, rate plans, and seasonal pricing
Front desk: check-in, check-out, and folio billing
Housekeeping task board
Extra services (laundry, restaurant, tours) charged to the room
Occupancy and revenue reports

Database Design

Room types have many rooms. Reservations hold room types/dates and are assigned physical rooms at check-in. Folios aggregate charges.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	guest, receptionist, housekeeper, manager
`guests`	id, user_id (FK, nullable), full_name, phone, id_number, nationality
`room_types`	id, name, description, capacity, base_price
`rooms`	id, room_no (UQ), room_type_id (FK), floor, status, housekeeping_status
`room_amenities`	id, room_type_id (FK), amenity
`rate_plans`	id, room_type_id (FK), name, price, start_date, end_date, days_of_week
`reservations`	id, guest_id (FK), room_type_id (FK), check_in, check_out, adults, children, status, total, source
`stays`	id, reservation_id (FK), room_id (FK), checked_in_at, checked_out_at
`folio_charges`	id, stay_id (FK), service_id (FK), description, amount, charged_at
`services`	id, name, price
`payments`	id, reservation_id (FK), amount, method, reference, paid_at
`housekeeping_tasks`	id, room_id (FK), assigned_to (FK), task_type, status, completed_at
`reviews`	id, reservation_id (FK, UQ), rating, comment

Project 32: Restaurant Management and Table Reservation System

Description

Handles table reservations, in-house ordering through tablets or QR menus, a kitchen display screen, billing, and stock control of ingredients. Waiters take orders on a phone, the kitchen sees them in real time, and the cashier closes bills with split payments. Managers analyze best sellers and ingredient wastage.

Key Features

Digital menu with QR code per table
Table map and reservations
Kitchen display system (real-time via WebSockets)
Recipe-based ingredient deduction
Split bills, tips, and multiple payment methods
Daily sales and waste reports

Database Design

Orders belong to tables and contain items sent to kitchen stations. Menu items link to ingredients through recipes for automatic stock deduction.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	waiter, chef, cashier, manager
`tables`	id, label, capacity, qr_code, status
`reservations`	id, table_id (FK), customer_name, phone, party_size, reserved_at, status
`menu_categories`	id, name, station	Kitchen, bar
`menu_items`	id, category_id (FK), name, description, price, is_available
`ingredients`	id, name, unit, stock_qty, reorder_level
`recipes`	menu_item_id (FK), ingredient_id (FK), quantity_used	Composite PK
`orders`	id, table_id (FK), waiter_id (FK), status, opened_at, closed_at
`order_items`	id, order_id (FK), menu_item_id (FK), quantity, unit_price, notes, kitchen_status
`bills`	id, order_id (FK, UQ), subtotal, tax, tip, total, status
`bill_payments`	id, bill_id (FK), amount, method, paid_at	Supports split payment
`suppliers`	id, name, phone
`ingredient_purchases`	id, supplier_id (FK), ingredient_id (FK), quantity, cost, purchased_at
`waste_logs`	id, ingredient_id (FK), quantity, reason, logged_by (FK), logged_at

Project 33: Employee, HR and Payroll Management System

Description

Helps small and medium companies manage employee records, contracts, attendance, leave, overtime, salary structures, tax and social security deductions (e.g., PAYE and NSSF in Uganda), and monthly payslips. Employees log in to request leave, view payslips, and update personal details. HR approves leave and runs payroll in one click.

Key Features

Employee profiles, contracts, and documents
Clock-in/clock-out and shift scheduling
Leave types, balances, and approval workflow
Payroll engine with allowances, deductions, and statutory contributions
PDF payslips by email
Performance reviews and HR analytics

Database Design

Employees belong to departments and positions. Payroll runs generate one payslip per employee with itemized lines.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	employee, manager, hr, admin
`departments`	id, name, head_id (FK)
`positions`	id, title, department_id (FK), base_salary
`employees`	id, user_id (FK), employee_no (UQ), full_name, national_id, dob, phone, position_id (FK), hire_date, status, bank_account
`contracts`	id, employee_id (FK), type, start_date, end_date, salary
`employee_documents`	id, employee_id (FK), type, file_url
`attendance`	id, employee_id (FK), date, clock_in, clock_out, hours_worked
`leave_types`	id, name, days_per_year, is_paid
`leave_balances`	employee_id (FK), leave_type_id (FK), year, balance
`leave_requests`	id, employee_id (FK), leave_type_id (FK), start_date, end_date, status, approved_by (FK)
`salary_components`	id, name, type, is_taxable, calculation_rule	allowance/deduction
`employee_components`	employee_id (FK), component_id (FK), amount
`payroll_runs`	id, period_month, status, run_by (FK), run_at
`payslips`	id, run_id (FK), employee_id (FK), gross, deductions, tax, net
`payslip_lines`	id, payslip_id (FK), component_id (FK), amount
`performance_reviews`	id, employee_id (FK), reviewer_id (FK), period, score, comments

Project 34: Child Immunization and Community Health Tracker

Description

Helps health centers and community health workers (CHWs) track children's vaccinations, pregnancy visits, and growth monitoring. The system schedules each child's vaccines based on the national immunization schedule, sends SMS reminders to caregivers, and flags defaulters. District health officers view coverage dashboards and vaccine stock levels.

Key Features

Child registration with vaccination schedule auto-generation
SMS reminders to caregivers and defaulter tracing lists
Antenatal care and growth (weight/height) monitoring charts
Vaccine stock per facility with wastage tracking
Offline-capable mobile web app for CHWs in the field
Coverage dashboards by district and facility

Database Design

Children have scheduled vaccinations derived from a vaccine schedule template. Administered doses are recorded against facility stock batches.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	chw, nurse, district_officer, admin
`facilities`	id, name, level, district, latitude, longitude
`chws`	id, user_id (FK), facility_id (FK), village_assigned, phone
`caregivers`	id, full_name, phone, village, relationship
`children`	id, child_no (UQ), full_name, dob, gender, caregiver_id (FK), facility_id (FK), birth_weight
`vaccines`	id, name, disease_prevented, doses_required
`schedule_templates`	id, vaccine_id (FK), dose_no, age_in_weeks	National schedule
`child_vaccinations`	id, child_id (FK), vaccine_id (FK), dose_no, due_date, given_date, status, given_by (FK), batch_id (FK)
`vaccine_batches`	id, facility_id (FK), vaccine_id (FK), batch_no, expiry_date, quantity
`growth_records`	id, child_id (FK), recorded_at, weight_kg, height_cm, muac
`anc_visits`	id, mother_id (FK), visit_no, visit_date, bp, weight, notes	Mothers table (optional)
`reminders`	id, child_vaccination_id (FK), channel, send_at, status
`defaulter_followups`	id, child_id (FK), chw_id (FK), visited_at, outcome, notes

Project 35: Delivery and Boda-Boda Dispatch Platform

Description

A ride and parcel dispatch platform for motorbike (boda-boda) riders, couriers, and small delivery businesses. Customers request a delivery or ride, nearby riders get the request, and the customer follows the rider on a map. Fares are calculated from distance, and riders have wallets with earnings and commission deductions.

Key Features

Request creation with pickup/drop-off on a map
Nearest-rider matching and real-time tracking
Fare estimation by distance and time
Rider wallet, commission, and payouts
Ratings, trip history, and receipts
Admin: rider verification, pricing rules, and analytics

Database Design

A request becomes a trip when a rider accepts. Location pings and payments attach to trips; riders own wallets with ledgers.

Tables

Table	Columns	Notes
`users`	id, phone, password_hash, role	customer, rider, admin
`riders`	id, user_id (FK), license_no, vehicle_plate, status, is_online, rating_avg, is_verified
`rider_locations`	id, rider_id (FK), latitude, longitude, updated_at	Index on rider_id
`delivery_requests`	id, customer_id (FK), type, pickup_address, pickup_lat, pickup_lng, drop_address, drop_lat, drop_lng, item_description, estimated_fare, status
`trips`	id, request_id (FK, UQ), rider_id (FK), accepted_at, picked_at, delivered_at, distance_km, final_fare
`trip_tracking`	id, trip_id (FK), latitude, longitude, recorded_at
`pricing_rules`	id, base_fare, per_km, per_minute, surge_multiplier, active_from
`payments`	id, trip_id (FK), amount, method, reference, status
`wallets`	id, rider_id (FK, UQ), balance
`wallet_transactions`	id, wallet_id (FK), type, amount, trip_id (FK, nullable), created_at
`payout_requests`	id, rider_id (FK), amount, status, processed_at
`ratings`	id, trip_id (FK, UQ), customer_rating, rider_rating, comment

Project 36: Learning Management System (LMS) for Schools and Training Centers

Description

An online learning platform where instructors publish courses made of modules, video lessons, reading materials, assignments, and quizzes. Learners enroll, track progress, submit assignments, and earn verifiable certificates. Useful for secondary schools, vocational institutes, and corporate trainers.

Key Features

Course builder with modules, lessons, videos, and files
Quizzes and assignments with grading and feedback
Progress tracking and completion certificates (QR-verifiable)
Discussion forums per course
Paid courses with payment integration (optional)
Instructor analytics (completion rate, drop-off lessons)

Database Design

Courses have modules, which contain lessons. Enrollments track progress per lesson. Assessments hang off courses and modules.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role, full_name	learner, instructor, admin
`categories`	id, name
`courses`	id, instructor_id (FK), category_id (FK), title, description, price, level, status
`modules`	id, course_id (FK), title, position
`lessons`	id, module_id (FK), title, type, content_url, body, duration_min, position	video/text/file
`enrollments`	id, course_id (FK), learner_id (FK), enrolled_at, status, completed_at	UQ pair
`lesson_progress`	enrollment_id (FK), lesson_id (FK), completed_at	Composite PK
`quizzes`	id, module_id (FK), title, pass_mark, time_limit
`quiz_questions`	id, quiz_id (FK), question_text, type
`quiz_options`	id, question_id (FK), option_text, is_correct
`quiz_attempts`	id, quiz_id (FK), learner_id (FK), score, passed, attempted_at
`assignments`	id, module_id (FK), title, instructions, due_date, max_score
`assignment_submissions`	id, assignment_id (FK), learner_id (FK), file_url, score, feedback, submitted_at
`forum_threads`	id, course_id (FK), author_id (FK), title, body
`forum_replies`	id, thread_id (FK), author_id (FK), body
`certificates`	id, enrollment_id (FK, UQ), certificate_no (UQ), issued_at
`payments`	id, enrollment_id (FK), amount, method, reference

Project 37: NGO Project, Donor and Grant Management System

Description

Helps non-profit organizations manage donors, grants, projects, budgets, beneficiaries, and reporting. Program managers plan activities against budgets, field officers register beneficiaries and record services delivered, and finance tracks expenditure per donor. The system auto-generates donor reports with indicators and spending summaries.

Key Features

Donor and grant tracking with reporting deadlines
Project, activity, and budget-line management
Beneficiary registry and service delivery records
Expense recording against budget lines with approvals
Monitoring and evaluation (M&E) indicators and dashboards
Donor-specific report generation (PDF/Excel)

Database Design

Grants fund projects. Projects have budget lines and activities. Expenses draw from budget lines. Indicators measure results from activities.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	admin, program_manager, finance, field_officer, donor_viewer
`donors`	id, name, type, contact_person, email
`grants`	id, donor_id (FK), title, amount, currency, start_date, end_date, reporting_frequency
`projects`	id, grant_id (FK), name, description, manager_id (FK), start_date, end_date, status
`budget_lines`	id, project_id (FK), category, description, allocated_amount
`expenses`	id, budget_line_id (FK), amount, description, receipt_url, spent_at, approved_by (FK), status
`activities`	id, project_id (FK), title, planned_date, actual_date, status, location
`beneficiaries`	id, beneficiary_no (UQ), full_name, gender, dob, village, district, phone
`services_delivered`	id, activity_id (FK), beneficiary_id (FK), service_type, delivered_at, officer_id (FK)
`indicators`	id, project_id (FK), name, unit, baseline, target
`indicator_values`	id, indicator_id (FK), period, actual_value, recorded_by (FK)
`reports`	id, grant_id (FK), period, status, generated_at, file_url
`staff_timesheets`	id, user_id (FK), project_id (FK), date, hours

Project 38: CRM and Invoicing System for SMEs

Description

A lightweight customer relationship management and invoicing tool for small businesses and freelancers. It tracks leads, customers, deals through a sales pipeline, quotes, invoices, and payments, and reminds staff to follow up. Owners see sales forecasts and overdue invoices at a glance.

Key Features

Lead capture forms and customer database
Kanban sales pipeline (lead, contacted, proposal, won, lost)
Quotes converted to invoices in one click
Recurring invoices and automatic overdue reminders
Payment tracking and PDF invoice emailing
Task and follow-up reminders with activity timeline

Database Design

Contacts belong to companies. Deals move through pipeline stages. Quotes and invoices are documents with line items and linked payments.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	owner, sales, accountant
`companies`	id, name, industry, website, address
`contacts`	id, company_id (FK), full_name, email, phone, position, source
`pipeline_stages`	id, name, position, probability
`deals`	id, contact_id (FK), owner_id (FK), title, value, stage_id (FK), expected_close, status
`activities`	id, deal_id (FK), contact_id (FK), type, note, due_at, done, created_by (FK)	Calls, meetings
`products_services`	id, name, description, unit_price, tax_rate
`quotes`	id, deal_id (FK), quote_no (UQ), issue_date, valid_until, total, status
`quote_items`	id, quote_id (FK), product_id (FK), quantity, unit_price
`invoices`	id, quote_id (FK, nullable), contact_id (FK), invoice_no (UQ), issue_date, due_date, total, balance, status, is_recurring
`invoice_items`	id, invoice_id (FK), product_id (FK), quantity, unit_price
`payments`	id, invoice_id (FK), amount, method, reference, paid_at
`recurring_schedules`	id, invoice_id (FK), frequency, next_run
`email_logs`	id, invoice_id (FK), sent_to, sent_at, type

Project 39: Citizen Issue Reporting System for Local Government

Description

Lets residents report community problems such as potholes, broken water points, garbage, street lights, or insecurity by posting a photo and pin on a map. The report is routed to the right municipal department, which assigns a technician, updates the status publicly, and closes the case with proof of fix. Citizens can upvote existing reports to show priority.

Key Features

Report with photo, GPS pin, and category (mobile-friendly web or PWA)
Public map of issues with status colors
Upvoting and duplicate detection by location
Department routing, assignment, and SLA timers
Citizen notifications at each status change
Transparency dashboard (average fix time, per ward performance)

Database Design

Issues belong to categories and wards. Status history provides transparency, and updates carry photos before and after repair.

Tables

Table	Columns	Notes
`users`	id, email/phone, password_hash, role	citizen, officer, technician, admin
`wards`	id, name, district, boundary_geojson
`departments`	id, name, head_id (FK)	Roads, water, sanitation
`issue_categories`	id, name, department_id (FK), sla_days
`issues`	id, reporter_id (FK), category_id (FK), ward_id (FK), title, description, latitude, longitude, status, priority, created_at
`issue_images`	id, issue_id (FK), image_url, stage	before/after
`issue_votes`	issue_id (FK), user_id (FK)	Composite PK
`assignments`	id, issue_id (FK), technician_id (FK), assigned_by (FK), assigned_at, due_date
`status_history`	id, issue_id (FK), old_status, new_status, changed_by (FK), note, changed_at
`comments`	id, issue_id (FK), author_id (FK), body, is_public
`duplicates`	issue_id (FK), duplicate_of_id (FK)
`notifications`	id, user_id (FK), issue_id (FK), message, is_read

Project 40: Garage and Vehicle Fleet Management System

Description

Serves auto repair garages and companies with vehicle fleets. Garages record customer vehicles, job cards, parts used, mechanic time, and invoices; customers receive service reminders. Fleet owners track fuel, trips, drivers, insurance and license expiry, and maintenance costs per vehicle.

Key Features

Customer and vehicle records with service history
Job cards with labor, parts, and approval of quotes
Parts inventory and supplier purchases
Service reminders (by date or mileage) via SMS/email
Fleet module: drivers, trips, fuel logs, document expiry alerts
Cost-per-kilometer and downtime analytics

Database Design

Vehicles belong to customers or fleets. Job cards link a vehicle to tasks and parts used. Fleet trips and fuel logs link vehicles to drivers.

Tables

Table	Columns	Notes
`users`	id, email, password_hash, role	admin, service_advisor, mechanic, fleet_manager, customer
`customers`	id, user_id (FK, nullable), full_name, phone, email, address, type	individual/company
`vehicles`	id, customer_id (FK), plate_no (UQ), make, model, year, vin, color, current_mileage
`job_cards`	id, vehicle_id (FK), advisor_id (FK), opened_at, closed_at, complaint, status, mileage_in
`job_tasks`	id, job_card_id (FK), description, mechanic_id (FK), labor_hours, labor_rate, status
`parts`	id, part_no (UQ), name, unit_price, stock_qty, reorder_level
`job_parts`	id, job_card_id (FK), part_id (FK), quantity, unit_price
`suppliers`	id, name, phone
`part_purchases`	id, supplier_id (FK), part_id (FK), quantity, unit_cost, purchased_at
`quotes`	id, job_card_id (FK), total, status, approved_at
`invoices`	id, job_card_id (FK, UQ), total, balance, status, issued_at
`payments`	id, invoice_id (FK), amount, method, paid_at
`service_reminders`	id, vehicle_id (FK), type, due_date, due_mileage, sent
`drivers`	id, full_name, license_no, license_expiry, phone	Fleet module
`fleet_trips`	id, vehicle_id (FK), driver_id (FK), start_odometer, end_odometer, started_at, ended_at, purpose
`fuel_logs`	id, vehicle_id (FK), driver_id (FK), litres, cost, odometer, filled_at
`vehicle_documents`	id, vehicle_id (FK), type, expiry_date, file_url	Insurance, inspection

Bonus: Guidance for Delivering a Strong Final Year Project

1. Suggested Development Timeline

Phase	Duration	Deliverables
Requirements and research	3-4 weeks	Problem statement, interviews, user stories
Design	3-4 weeks	ER diagram, UML (use case, sequence), wireframes
Core development	10-14 weeks	Authentication, main modules, API
Advanced features	4-6 weeks	Payments, notifications, analytics
Testing	3-4 weeks	Unit, integration, and user acceptance testing
Deployment and documentation	2-3 weeks	Live system, user manual, final report

2. Database Design Best Practices to Demonstrate

Normalize to at least Third Normal Form (3NF) and explain any intentional denormalization.
Use foreign keys with sensible ON DELETE rules and indexes on columns used in searches and joins.
Add unique constraints to prevent duplicates (e.g., one registration per student per course).
Use transactions for multi-step operations such as payments and stock updates.
Keep audit tables for sensitive actions (grades, payments, medical records).
Use migrations (Prisma, Sequelize, Django, Laravel, Flyway) so the schema is version controlled.
Seed realistic test data for demos.

3. Features That Impress Examiners

Role-based access control with a clear permissions matrix
Real-time features (WebSockets or Server-Sent Events)
Payment integration (Mobile Money or card, with webhook handling)
Automated tests and a CI pipeline
Dockerized deployment and a live URL
Clear API documentation (Swagger/OpenAPI)
Analytics dashboards with charts
Security awareness: input validation, rate limiting, hashed passwords, protection against SQL injection, XSS, and CSRF

4. Documents Typically Required in the Final Report

Problem statement, objectives, scope, and significance
Literature review and review of existing systems
Methodology (Agile, Scrum, or Waterfall) and justification
System analysis: functional and non-functional requirements
System design: architecture diagram, ER diagram, UML diagrams, UI wireframes
Implementation details and code samples
Testing results (test cases and outcomes)
Conclusion, limitations, and recommendations for future work
References and appendices (user manual, sample screenshots)

5. Ranking by Difficulty (to Help You Choose)

Level	Projects
Beginner-friendly	1 (Course Registration), 4 (Library), 7 (Lost and Found), 13 (Clearance), 18 (Complaints), 28 (Church/Community), 38 (CRM and Invoicing), 39 (Citizen Reports)
Intermediate	2, 5, 6, 8, 9, 10, 11, 15, 16, 17, 19, 20, 21 (Pharmacy), 22 (Blood Donation), 23 (School), 25 (POS), 30 (Rental), 31 (Hotel), 32 (Restaurant), 34 (Immunization), 36 (LMS), 37 (NGO), 40 (Garage and Fleet)
Advanced	3 (Online Exams with proctoring), 12 (Live Transport Tracking), 14 (Timetable Scheduler), 24 (Hospital Management), 26 (Telemedicine), 27 (SACCO Loans Engine), 29 (Smart Farm and Marketplace), 33 (HR and Payroll), 35 (Dispatch Platform)

6. Choosing a Project That Can Become a Real Business

Projects 21 to 40 are especially good if you want your final year project to continue after graduation. Ask yourself:

Is there a paying customer? Pharmacies, clinics, shops, SACCOs, schools, and hotels all pay for software that saves them time or money.
Can I run a pilot? Visit a nearby pharmacy, school, or clinic early in your project and agree to test with them. Real feedback and a signed letter from a client strengthen your defense.
Is data privacy handled properly? Health and finance systems (21, 22, 24, 26, 27, 34) hold sensitive data. Show encryption, access control, and audit logs.
Does it work in low-connectivity environments? For community and rural systems (22, 25, 29, 34), consider offline-first design, SMS/USSD support, and lightweight pages.
Can I package it as a subscription (SaaS)? A multi-tenant design (a tenant_id or organization_id on every table) lets one deployment serve many shops, schools, or clinics.

Tip: Multi-Tenancy in Your Database Design

For business projects, add an organizations (or tenants) table and include organization_id as a foreign key in the main tables. This shows examiners you understand SaaS architecture:

Approach	Description	Best for
Shared database, shared schema	One set of tables with `organization_id` on rows	Simplest; most student projects
Shared database, separate schemas	One schema per customer in PostgreSQL	Stronger isolation
Separate databases	One database per customer	Highest isolation; more operational work

Final Tip

Pick the project where you can reach real users and real data. A modest system that students or staff actually use is far more impressive than an ambitious system that only exists on your laptop. Whatever you choose, start by drawing the ER diagram, because a good database design makes everything else easier.

Good luck with your final year project!

Accept Mobile Money in your app

JB

40 Final-Year Fullstack Project Ideas — A Student's Handbook