← All projects

Jan 2026 to Sep 2026

Walketalk

Full LMS for an English academy that only taught 1-to-1 in person: bookings, payments, a student classroom, and progress tracking. It opened their online business. Solo full-stack.

Role
Freelance full-stack developer
Period
Jan 2026 to Sep 2026
Client
Walketalk

Problem

The academy only taught in person, one student at a time. Schedules were agreed over WhatsApp, payments came in by bank transfer with no automatic balance or expiry control, and student progress lived nowhere but the teacher memory. There was no online modality, no practice material between classes, and no record of what had been covered.

My role

Complete solo full-stack development: product, architecture, database, backend, frontend, integrations, design, deployment, and QA. Direct communication with a non-technical client, including scope definition, expectation management, and functional and technical documentation.

Result

Version 1.0 live in production with real users. The academy now runs online for the first time on a single system: card payments for session packages, enrollments and bookings on aggregated availability, automatic Google Calendar publishing with Google Meet links, management of balance, expiries, and rescheduling windows, and a classroom where students take a placement test, work through exercises, and read the summary of every class.

Stack

  • Next.js
  • React
  • TypeScript
  • Tailwind
  • Prisma
  • PostgreSQL
  • Stripe
  • Google Calendar API
  • Vercel

Summary

Walketalk is the LMS of an English academy that until then only taught in person, one student at a time. The platform did not digitize an existing process: it built the online side of the business end to end, from the sale to the classroom.

One system covers all three sides of the operation. Students buy, book, and study. Teachers publish their availability, teach, and leave a record of every class. Admins enroll students into recurring slots, reassign teachers, grant make-up classes, handle refunds, and watch the business metrics.

The classroom

  • A CEFR placement test that positions the student before the first class.
  • Self-correcting grammar exercises and videos assigned by the teacher, student by student.
  • A written summary from the teacher after each class, visible to the student.
  • A full class history, with balance and expiry dates always in sight.

Bookings and payments

  • Session packages or single classes paid by card, with tax calculated at checkout.
  • Enrollment in a fixed weekly slot with a specific teacher, plus one-off bookings on aggregated availability: the student picks a time slot, not a teacher.
  • Every class publishes itself to Google Calendar, with a Google Meet link and an email invitation.
  • Credit-based balance with per-credit expiry and FIFO consumption, three-day rescheduling windows, and automatic right-of-withdrawal eligibility.

Technical decisions

The platform is the single source of truth: Google Calendar is used purely as a publishing channel, while availability, enrollments, and bookings are computed in the database. Everything is stored in UTC with real multi-time-zone support (teachers set availability in their local time, students read it in theirs), and every automated process is idempotent: unique indexes on weekly class generation, deduplication of payment webhooks, and retries with backoff on Google API calls.

Hiring a full-stack or frontend developer for your remote team? Let's talk.

Contact me