Skip to content

System Overview

The three user roles

The platform is built around three distinct entry points, each with its own view:

  • Organiser — the allocation board: assigns tutors to courses and sees violations (marks, timetable clashes, remaining hours) as they make choices
  • Tutor — a dashboard showing what they owe (hours, timesheets) and when, plus the ability to log hours and excuse themselves from sessions
  • Student — a plain view for volunteering on unclaimed overflow work

High-level architecture

Replace this with a real diagram once the design is settled (e.g. draw.io, Mermaid, Excalidraw exported as SVG).

flowchart LR
    subgraph Client[Front-end]
        A[Organiser Board]
        B[Tutor Dashboard]
        C[Student View]
    end
    subgraph Server[Back-end API]
        D[Auth]
        E[Allocation Service]
        F[Timesheet Service]
    end
    G[(Database)]
    H[[External Integration]]

    A --> Server
    B --> Server
    C --> Server
    Server --> G
    Server --> H

Key design constraints (from the project brief)

  • Front-end and back-end must be non-monolithic — no framework that couples them (or if it does, only used for one side)
  • The API must be hand-written, not generated by a BaaS such as Firebase/Supabase
  • Authentication must use an established library/service, not a custom-built auth system
  • Must integrate with at least one external API
  • Must be deployed with CI/CD

Where to go next