If you run a tutoring service, a music school, or a language studio, you know the drill at the start of every term.
Does this tutor teach the right subject? Can they handle this student's level? Do their available hours actually overlap with the family's? Does this lesson collide with something already on the calendar?
Do that once per student and it's fine. Do it for a full roster and it's a puzzle — one you rebuild every term.
And the records you're handling are student names and contact details, often for minors.
Shiftaru was built to solve both — the matching complexity and the privacy.
🔧 Note
Shiftaru is in active development. Right now you can try the free practice mode (sample data, no signup).
👉 https://shiftaru.com
Why student-tutor matching becomes a term-long puzzle
Placing a single student means checking several things at once:
- Can this tutor teach the student's subject, instrument, or language?
- Can they handle the student's level (grade, exam tier, proficiency)?
- Do the student's and tutor's preferred times actually line up?
- Does the lesson collide with anything already booked?
Now do that for the whole roster.
The trap is the same one every scheduler hits: one change ripples through everything else. A tutor drops a Tuesday slot and three other students have to move. Last term's assignments don't transfer, so you start over from close to zero.
It's heavy because the constraints are interlocking, not because you're doing it wrong. (See Part 1.)
Shiftaru schedules with your real-world rules
Feed Shiftaru the same conditions and it matches automatically:
- Subject / instrument / language — students are matched only to tutors who teach it
- Preferred times — up to 10 time preferences per student, placed at the exact requested time (with breaks reserved)
- No double-booking — overlapping lessons are prevented automatically
- Workload balance — spread lessons across your tutors, or concentrate them on a few. Your call.
Hundreds of students resolve in seconds. "A tutor is out this week, rebuild the timetable" takes one click.
(The matching engine itself is explained in Part 2.)
Level is a hard constraint, too
Subject alone isn't enough. Assigning an algebra student to a tutor who only covers elementary arithmetic is worse than assigning nobody — you've filled the slot and hidden the problem.
So in Shiftaru, both subject and level are hard constraints. A tutor who doesn't cover the student's level is removed from the candidate pool — even if the subject matches, even if their calendar is wide open. They will not be assigned.
When a student can't be matched, Shiftaru shows the reason. Which means you get something more useful than a schedule: you get a precise read on which subject-and-level combination you're short on, before the term starts.
And your student data never leaves the browser
Schools hold student names, guardian contact details, sometimes grades and lesson notes — frequently for minors. That's a category of data you want to be careful with by default, not after an incident.
The student data you load into Shiftaru is processed entirely inside your own browser. It is never sent to our servers. Close the tab and it's gone. The finished timetable is saved as a file you control.
We can't leak your student list, because we never receive it. (Details in Part 3.)
Summary
- Matching becomes a term-long puzzle because subject, level, and time preferences all interlock
- Shiftaru matches automatically using your actual rules (hundreds of students, seconds)
- Subject and level are hard constraints — a mismatched tutor is never assigned
- Student data (including minors') stays in your browser and is never transmitted
Complexity handled by the engine. Privacy handled by the architecture. Both, at once.
- ▶ https://shiftaru.com — free practice mode, no signup
- ▶ Read more: Shiftaru Blog