Case Study

Mastering IELTS

From One-on-One Coaching to a Platform That Scaled It

I started by teaching. Every manual problem the teaching exposed became something to solve in code.

Role Founder & Technical Lead
Stack WordPress · PHP · JavaScript · React
Years Dec 2018 — Jan 2020

Teaching one-on-one doesn't scale. The admin around it scales worse.

I was coaching IELTS candidates individually. The teaching worked — students hit their target band scores and told other people. That was the problem. Every new student meant more scheduling by message, more practice material sent by hand, more scores tracked in a spreadsheet, and more time spent on coordination instead of instruction.

Scheduling by Hand

Every session booked, confirmed, and rescheduled through individual messages across time zones.

Manual Content Delivery

Practice sets and lesson material sent per student, per session, with no central library.

No Progress Visibility

Scores lived in a spreadsheet. Neither I nor the student could see a trend without me building one.

Word of Mouth Outpacing Capacity

Referrals were arriving faster than one person teaching live could absorb them.

A platform that absorbed the overhead so the teaching could grow.

I built MasteringIeltsexam.com end-to-end — hosting, UI/UX, content delivery, and the assessment engine. Nothing was outsourced, because every feature came from a problem I had personally hit the week before while teaching.

Interactive Assessments

State-driven quizzes and mock tests with real-time scoring logic and instant answer validation.

Video Lesson Delivery

Recorded lessons distributed through the site and a public YouTube channel, so material scaled past live hours.

Structured Curriculum

A central content library replacing per-student material sends, organised by band target and skill area.

Traffic & SEO Optimisation

Site architecture, page load speed, and technical SEO tuned against Google Analytics to drive organic enrolment.

The software was the smaller half of this.

Before it was a platform it was a classroom, and the thing that actually made it work was the instruction. That's the part that transfers: taking something a person finds opaque, finding the model that makes it click for them specifically, and checking that it landed.

Diagnose before teaching

Every student started with an assessment, not a lesson. You can't fix a band score without knowing which of the four skills is actually holding it down.

One model per concept

Rules don't stick; analogies do. I'd rebuild the same explanation three different ways until one matched how that student already thought.

Practice plans, not homework

Personalised plans targeting the specific weakness, with a scoring loop so progress was visible to the student rather than only to me.

Teach it back

The check on whether a concept had landed was always the same: can you now explain it to me without notes?

Unedited, and still public.

These are real Google reviews left by students. I haven't retyped them — they're screenshots, and the live listing is linked below so anyone can check them against the source.

This is why I build the way I build.

Running this taught me something no course did: the person using the software is rarely the person who specified it, and the gap between those two is where systems fail. I was the instructor, the developer, and the support desk at once, so every bad design decision came straight back to me within a day.

That's the same instinct behind CaseLog at FedEx — I was working the operation I was building for, so I already knew where it hurt. And the teaching half didn't go anywhere either: onboarding makers onto a new platform is the same job as getting a concept to land, just with a different audience.

Interested in working together?

I build real business solutions with Power Platform and web technologies. Let's talk about what I can build for your team.