K–12 EdTech Case study

TurtlEd

Personalized English and mathematics tutoring through one-to-one and small-group live sessions.

K–12 EdTech

TurtlEd TurtlEd

Lead Engineer

System map · Operational ecosystem

Engineering scope

  • One session model Group and individual lessons never branch the calendar
  • Attendance observed Embedded video rather than an external meeting link

Session lifecycle

  1. Schedule

    One session model, group or individual

  2. Remind

    Calendars synchronised

  3. Teach

    Embedded video, inside the platform

  4. Record

    Attendance observed, not self-reported

  5. Report

    Answered from what the system saw

Who the platform serves

  • Students
  • Tutors
  • Parents
  • Administrators
Product surface
The public TurtlEd site, showing its tutoring product for schools, parents and tutors.

Engineering

Role-based dashboards · Scheduling · Jitsi · Live learning workflows

Public product · Proprietary source code

Role
Lead Engineer
Disclosure
Public product · Proprietary source code
Links
Product website

The problem

What the system had to solve.

A tutoring session involves a student and a tutor, but the platform serves two more people who are never in the room: a parent who is paying and wants to know it is working, and a school coordinating scheduling and coverage across many students.

Each needs a different view of the same lesson, and the platform has to hold one-to-one and small-group teaching in one model without treating groups as a special case.

What I owned

The responsibility behind the work.

Led engineering for the company website and the core learning platform: the administrator, tutor and student surfaces, scheduling and classroom workflows, and the domain model underneath them.

Led engineering for the company website and core learning platform, including administrator, teacher and student dashboards, scheduling, classroom-management workflows and embedded Jitsi video calling.

Engineering approach

How it was built.

The backend is organised into domain modules rather than technical layers, with group and individual lessons sharing one session model so calendars, attendance and reporting never branch on lesson type. Live sessions run on embedded video rather than external meeting links, which lets the platform observe attendance instead of relying on it being reported, and scheduling synchronises to tutors’ own calendars with reminders and recurrence handled as background work.

Session lifecycle

  1. Schedule
  2. Remind
  3. Teach
  4. Record
  5. Report

Four people in every lesson

Who a tutoring platform actually serves.

A tutoring session involves a student and a tutor, but the platform serves two more people who are never in the room. A parent is paying and wants to know it is working. A school or administrator is responsible for scheduling, coverage and outcomes across many students at once.

Each of those four needs a different view of the same lesson, and only one of them is the person being taught.

Who the platform serves

In the lesson

  • Students
  • Tutors

Around the lesson

  • Parents
  • Schools and administrators

The domain model

Modules shaped like the business, not the framework.

The backend is organised into domain modules rather than technical layers, so scheduling, attendance or reporting is one place in the codebase instead of a slice through four. The model has to hold both one-to-one tutoring and small-group sessions without treating a group as a special case bolted onto an individual lesson.

Domain areas

People

  • Students
  • Tutors
  • Parents
  • Schools
  • Administrators

Teaching

  • Subjects
  • Groups
  • Class sessions
  • Meetings
  • Attendance

Around it

  • Scheduling
  • Announcements
  • Insights
  • Tagging

Groups and individual sessions share the same session model. A tutor’s calendar, an attendance record and a parent’s view of progress should not need to know which kind a lesson was.

The lesson itself

Video embedded in the product, not linked from it.

Live sessions run inside the platform through embedded video rather than by sending a link to an external meeting tool. That is a deliberate product decision with an architectural consequence: the platform owns the session, so it knows who joined, when, and for how long.

Why embedded

External meeting link

  • Platform has no view of the session
  • Attendance is self-reported
  • Joining is a separate product
  • No link between session and record

Embedded video

  • Session belongs to a class record
  • Attendance observed
  • One place for students to be
  • Scheduling and joining are the same flow
Attendance stops being something a tutor remembers to record and becomes something the system observes.

Scheduling and calendars

The coordination problem underneath tutoring.

Scheduling has to satisfy a tutor’s availability, a student’s timetable and a parent’s expectations at once, and then survive changes to any of them. Sessions synchronise to external calendars so a tutor is not maintaining their availability in two places and reconciling it by hand.

Session lifecycle

  1. Session scheduled
  2. Calendar synchronised
  3. Reminders sent
  4. Session takes place
  5. Attendance recorded
  6. Progress and insights updated
Each transition is a record rather than a status field, so a parent asking what happened to a lesson can be answered.

Scheduled background work handles what should not happen inside a request: reminders, calendar synchronisation and recurring session generation.

Separate applications per role

A tutor and an administrator do not share a screen.

Tutors and administrators have their own applications against the same API. A tutor needs today’s sessions, their students and a way into the classroom. An administrator needs coverage, scheduling across many tutors, and reporting. Combining those into one interface with hidden sections serves neither.

Clients

  1. API One domain model and permission set
    1. Tutor application Sessions, students, classroom
    1. Administrative application Scheduling, coverage, reporting
    1. Public site Discovery and enrolment
One API, role-specific applications, so each surface can be designed for the job it actually does.

Insights and reporting

Answering the question a parent is actually asking.

The question behind a tutoring subscription is whether it is working. Answering it means aggregating attendance, session history and progress across time rather than showing a list of past lessons, which is a reporting concern separate from the operational data it reads.

What reporting draws on

  • Attendance records
  • Session history
  • Subject and group context
  • Tagging for categorisation

Engineering scope

What I worked on.

  1. Administrator, teacher and student dashboards
  2. Scheduling and classroom-management workflows
  3. Learning and tutoring operations
  4. Embedded Jitsi live video sessions
  5. Company website and core platform delivery

Why these decisions mattered

The trade-offs behind the platform.

  • Embedded video, not external links

    Decision
    Live sessions run inside the platform.
    Why
    The platform can only record attendance and tie a session to a class record if it owns the session.

  • One session model for groups and individuals

    Decision
    Group and one-to-one lessons share a model.
    Why
    Calendars, attendance and reporting should not each need to know which kind a lesson was.

  • Domain modules over technical layers

    Decision
    The backend is organised by domain area.
    Why
    A change to scheduling is one place rather than a slice through four.

  • External calendar synchronisation

    Decision
    Sessions sync to tutors’ own calendars.
    Why
    A tutor maintaining availability in two systems will reconcile them wrongly.

  • Role-specific applications

    Decision
    Separate tutor and administrative clients.
    Why
    One interface with hidden sections serves neither role well.

  • Background work for anything periodic

    Decision
    Reminders, sync and recurrence run on schedules.
    Why
    None of it belongs inside a request, and all of it has to happen whether anyone is logged in or not.

Impact

What the platform holds together.

Scheduling, live teaching, attendance and reporting operate on the same records, so a parent’s question about progress is answered from what the system observed rather than from what someone remembered to enter.

Technology

The technical surface.

  • Role-based dashboards
  • Scheduling
  • Jitsi
  • Live learning workflows

Next: Ask People Team

Back to all work Start a conversation