Case study · Education
A tutoring platform built around the lesson, not the timetable
Tutoring products usually start as a booking system and bolt a classroom on afterwards. We built one the other way round: the lesson comes first, and scheduling, materials and progress reporting arrange themselves around it.
Engagement · Product development
A three-sided education product across web and mobile.
- Industry
- Education & e-learning
- Solution
- Live tutoring platform
- Engagement model
- Product team
- Market stage
- Product build
- Client
- An online tutoring platform, UK
- Scope
- Web & mobile development
- Platform
- Web · iOS · Android
- Users
- Students, tutors, parents
Outcomes
What a tutoring platform is measured on
Three people judge the same product by three different things. These are the figures that matter to each.
-
70%
Increase in lesson attendance
One button to join, reminders that arrive in time, and no meeting link to lose. Most missed lessons were never about motivation.
Measured across booked lessons after launch
-
55%
More subscription renewals
Parents renew when they can see it working. Progress written in sentences answers the question they are actually asking.
Measured across renewal decisions after progress reporting shipped
-
50%
Less administrative time for tutors
Availability, bookings, materials and earnings in one place turns an evening of messages into a few minutes.
Reported by tutors across the first year
Context
The situation before the platform
Why tutoring products usually start as a booking system and go wrong from there.
The business
An online tutoring service connecting students with subject tutors for live one-to-one and small-group lessons.
The starting point
Most tutoring platforms begin as a scheduling tool and add a classroom afterwards, which makes the lesson — the actual product — an afterthought bolted onto a calendar.
The trigger
Parents pay and cannot tell whether it is working; tutors spend evenings arranging times by message; students lose the link. All three problems come from the same missing record.
What they wanted
A platform built around the lesson: scheduling across time zones, live classes with shared materials, homework in the same place, and progress a parent can actually read.
Constraints
Students, tutors and parents span time zones and school terms · lessons are live, so a technical failure cannot be fixed afterwards · children's data carries obligations adult products do not · tutors are not administrators and will not fight the software.
System
What it runs at today
The platform as delivered.
-
3
Roles with their own view
Student, tutor and parent, each shown only what they need
-
1
Join action
One button on the lesson, no links and no separate accounts
-
2
Scheduling dimensions handled
Time zones and term dates, so neither party has to convert anything
-
0
Homework sent by email
Set, submitted and marked against the lesson itself
The engineering problem
Four problems in building for three audiences
Every decision had to work for a child, a professional tutor and a paying parent at the same time.
-
The classroom cannot be an afterthought
A tutoring platform with excellent scheduling and a poor classroom is worthless; the reverse is merely inconvenient. Yet the classroom is technically hardest, so it usually gets built last and least.
What we did
We built the live classroom first and tested it on the connections and devices students actually have, before any scheduling existed to arrange lessons in it.
-
Time zones and term dates defeat people
A tutor in one country, a student in another, half-terms that do not align, and recurring lessons that must skip a holiday. Left to the participants, this produces missed lessons and refund requests.
What we did
Availability published in the tutor's zone and booked in the student's, with term dates and recurrence handled centrally so neither party converts anything by hand.
-
Parents cannot read attendance graphs
Progress shown as attendance percentages and session counts answers a question nobody asked. A parent wants to know whether their child is improving, in sentences.
What we did
Progress reporting written for parents: what was covered, what improved, what needs work — generated from what the tutor recorded in the lesson rather than from attendance data.
-
Safeguarding cannot be added after launch
A product used by children needs linked parent accounts, restricted messaging and recorded access. Retrofitting those after the first incident is both too late and architecturally painful.
What we did
Parent-linked student accounts, messaging restricted by relationship, and access recording built in before the first release rather than after the first complaint.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Clients
- Responsive web
- iOS app
- Android app
Three front ends onto the same lesson record, with the classroom reachable from all of them.
-
Classroom
- Real-time video
- Shared whiteboard
- Materials viewer
- Reconnection handling
The live parts kept separable from the record, so a dropped connection interrupts the session without losing what the lesson was.
-
Services
- Scheduling
- Lesson records
- Homework
- Progress reporting
- Payments
Scheduling, records and reporting as distinct services over one lesson definition, which is what keeps the three views consistent.
-
Safeguarding & data
- Linked accounts
- Restricted messaging
- Access logging
The protections a product for children requires, enforced in the same layer that serves the data rather than in the interface.
Defining what a lesson is as a record — participants, materials, what was covered, what was set — before building anything else is what allows one product to answer a student, a tutor and a parent without contradicting itself.
Solutions
What the platform does for each of the three
The same lesson record drives three different views, which is what keeps them from disagreeing.
-
Scheduling across time zones
Tutors publish availability in their own time zone; students book in theirs. Term dates, holidays and recurring lessons are handled rather than left to the participants.
-
Live classroom
Video lesson with a shared whiteboard and materials, joined from a single button with no links to copy and no separate account to create.
-
Materials and homework
Lesson materials attached to the lesson rather than emailed, with homework set, submitted and marked in the same place.
-
Progress reporting
Progress written for parents: what was covered, what improved, what needs work — in sentences, not a graph of attendance.
-
Tutor tools
A tutor's week, their students' history and their earnings in one view, designed so admin takes minutes rather than an evening.
-
Safeguarding and access
Parent-linked student accounts, restricted messaging, recorded access and the data handling a product for children requires.
Key capabilities
What it does day to day
Six capabilities across the three audiences.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Scheduling | Tutor & student | On booking | Availability in the tutor's zone, booked in the student's, with term dates handled |
| Live classroom | Live session | Real time | Video, shared whiteboard and materials, joined from one button |
| Materials & homework | Tutor | Per lesson | Attached to the lesson, with homework set, submitted and marked in one place |
| Progress reporting | Automatic | Per period | Written for parents in sentences, generated from what the tutor recorded |
| Tutor tools | Tutor | Continuous | The week, student history and earnings in one view |
| Safeguarding | Automatic | Continuous | Linked parent accounts, restricted messaging and recorded access |
Integrations
How the moving parts plug in
Video, payments and notifications reach the product through one service layer rather than sitting beside it.
Connected capabilities
- Real-time videoThe live classroom
- PaymentsLesson and package billing
- NotificationsReminders and changes
- File storageMaterials and homework
Platform layer
- Lesson recordsOne definition, three views
- SchedulingZones, terms and recurrence
- Safeguarding rulesWho may contact whom
Role views
- Student
- Tutor
- Parent
Because progress reporting is generated from the lesson record rather than compiled separately, a parent's report and a tutor's notes are the same information rather than two accounts of it.
Security & data
What protects students on the platform
A product used by children carries obligations that an adult product does not, and they shape the architecture rather than sitting on top of it.
-
Parent-linked accounts
A student account is linked to a parent, who can see the lessons, the progress and the messages associated with their child.
-
Restricted messaging
Who may contact whom is defined by relationship — tutor to student within a booked lesson context, never open messaging across the platform.
-
Recorded access
Access to a student's record is attributable, so the platform can answer questions about who saw what.
-
Data minimisation
The platform holds what a lesson requires and no more, which is both a safeguarding position and a smaller thing to protect.
The brief
Three people with three different questions about the same lesson
A tutoring platform serves three people at once. The student wants to join the lesson. The tutor wants their week arranged and their materials to hand. The parent, who pays, wants to know whether any of it is working.
Most products answer the first question well and the other two badly. The brief here was to treat all three as first-class, from one shared record of what actually happened in each lesson.
- Students join a lesson without hunting for a link
- Tutors manage availability instead of answering messages
- Parents see progress in plain language, not raw attendance
- One record of each lesson, seen differently by each role
What makes education products awkward
- 01Students, tutors and parents span time zones and school terms
- 02Lessons are live: a technical failure cannot be fixed later
- 03Children's data carries obligations that adult products do not
- 04Tutors are not administrators and will not fight the software
Process
Built in the order the product is used
We built the lesson itself first, because a tutoring platform with perfect scheduling and a bad classroom is worthless, and the reverse is merely inconvenient.
-
Lesson-first definition
We defined what a lesson is as a record — participants, materials, what was covered, what was set — and built everything else against that.
-
The classroom
Live video, shared whiteboard and materials, built and tested first on the connections and devices students actually have.
-
Scheduling and availability
Time zones, recurrence and term dates handled centrally, with clashes prevented at booking rather than discovered later.
-
The three interfaces
Student, tutor and parent views over the same data, each showing only what that person needs to decide or do.
-
Safeguarding and launch
Access rules, restricted messaging and data handling reviewed before launch rather than after the first complaint.
Technology
Live video over a shared lesson record
Real-time classroom components over a conventional application core, so the live parts can fail and recover without taking the record with them.
Classroom
- Real-time video
- Shared whiteboard
- Materials viewer
- Reconnection handling
Apps
- Responsive web app
- iOS app
- Android app
Core
- Scheduling service
- Lesson records
- Notifications
- Payments
Safeguarding
- Linked accounts
- Restricted messaging
- Access logging
Business impact
What changed for each audience
One record, three people who each get a straight answer.
-
Students start on time
One button on the lesson removes the two minutes of link-hunting that used to eat the start of every session.
-
Tutors stop administering
Availability, bookings and earnings in one view turns an evening of messages into a few minutes.
-
Parents can see it working
Progress in sentences answers the question a parent is actually asking, which is why they renew.
The result
One lesson record, three people who each get a straight answer
Students join with one button, tutors run their week without administering it, and parents get progress in language that means something.
Because all three views come from the same lesson record, nobody has to reconcile what the platform told somebody else.
- Live classroom with materials and homework attached
- Scheduling that handles time zones and term dates
- Progress reports parents can read
- Safeguarding designed in, not retrofitted
What we would insist on again
- 01Build the lesson before the timetable
- 02Write progress for the person paying, in sentences
- 03Test the classroom on bad connections and old devices
- 04Settle safeguarding rules before the first release
Verified reviews
What clients say about our custom software work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Custom Software Development
Web-Based Coupon App Development
The work produced by the team was of exceptional quality.
Jon Thies
CTO, Model Rocket Feb 2022 – Mar 2023
-
Custom Software Development
Mobile & Web Platform Development & Design
Silver Scintilla was responsive, respectful, and enjoyable to work with, quickly addressing any questions or requests.
DeShawn Brown
CEO & Founder, Lithios Jun 2021 – Nov 2022
-
Custom Software Development
Web-Based HRM System Development
Silver Scintilla provided the best solution with scalable functionality, personalized features, and robust security.
Suheb Khan
Director, Collaborative Insight Technologies Jul 2020 – Jun 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate