Projects LessonLynx case study
Scheduling and invoicing for freelance language tutors, built by a tutor who needed it first.
The real app, on a demo account with made-up students.
I've taught English online since 2021. My whole teaching business lived in one Google Sheet: who is booked when, which lessons happened, and who still owes money.
Sometimes weeks went by before I checked who hadn't paid, and I'd bill parents late. So I built the tool I wanted to open every morning. I was the first user, which meant I knew which problems were real.
I looked for a tool built for this and found nothing that fit how I actually teach. Most tutors I know still use spreadsheets, and years of doing that taught me how easy the mistakes are. So I made it a test of my design, product and coding skills at once.
What LessonLynx does, in the order a tutor uses it.
Also: Google sign-in · light & dark mode · pause a student without losing history · in-app bug reports
The first version was a React Native app for a university exam. Using it every day showed me what I liked and what was missing, and some features were beyond what I could build in React Native at the time. So I started again on the web, which I know better, with better planning and a cleaner architecture. One day both apps could share the same backend, so a tutor sees the same data on phone and laptop. Read about the mobile app and my thesis →
A Next.js app on Vercel loads each page's data on the server and generates invoice PDFs on demand. Supabase provides the PostgreSQL database, sign-in and private file storage. Every tutor's data is isolated inside the database itself, with row-level security.
What I chose, what I gave up for it.
Why: as one person I needed a database, sign-in and file storage without building a backend. Row-level security means the database itself only returns a tutor's own rows.
Trade-off: I depend on one vendor, and the safety rules live in the database, so I review them carefully.
Why: a weekly template fills in each week as it comes up. Moving one week's lesson is then just editing an ordinary lesson, with no special exception rules.
Trade-off: more rows, and the generator must never create duplicates. I learned that one the hard way.
How a month runs in LessonLynx. TapPress a step or let it play.
01 · Set a regular slotSet a student's regular time once and every future week fills in by itself.
01 · Set a regular slotSet a student's regular time once and every future week fills in by itself.
Illustration in the app's own colors. Demo names, made-up amounts.
For tutors east of UTC, some dates landed on the day before. Dates were being converted to UTC when saved. Now all date maths works in local calendar days.
Learned: a calendar date is not a timestamp.
Editing one week's recurring lesson detached it from its pattern, so the generator saw a gap and filled it again. Two lessons, same week. Edited lessons now stay linked to their pattern.
Learned: test edits, not just creation.
"Time to invoice" counted lessons, not billing units, so a student with long lessons never reached it. I spotted it within hours of release and moved the rule into one shared helper.
Learned: business rules belong in one place.
The direction was mine from the start. LessonLynx began as something I needed, and as the user base grows, I'm happy to shape it around feedback from real users.
My tools are Next.js, Supabase and Claude Code. Before a feature is built, I think through how it fits the architecture and the data. Then I read and review the code, and I test it against a real database, including checks that tutors can never see each other's data.
Time saved and forecasting are from my own teaching business.
The repository is private because LessonLynx has real users. I'm happy to walk you through the code in an interview.
I'm looking for my first role as a junior full-stack or backend developer, remote or in Belgrade. Let's talk.