Vidyora: how we built an AI-powered LMS for a coaching network that ran on WhatsApp and photocopiers

The first message came in on a Sunday evening. Vidyora's founder, who runs a coaching group with centres across several Uttar Pradesh towns, wanted to know if we could "make an app like the big edtech ones, but for us." He attached a screenshot of a WhatsApp group with four hundred unread messages. Most of them were PDFs.

On the call the next morning, the real problem came out in pieces. His teachers spent two or three evenings a week building test papers by hand — copying questions from old books, retyping them, formatting them, then photocopying hundreds of copies. Answer sheets came back in bundles that took a week to mark. Students who missed a class had no way to catch up except borrowing a friend's notebook. And parents, who were paying fees in instalments, called the centre manager every time they wanted to know how their child was doing.

He had tried two off-the-shelf LMS products. Both assumed students had laptops and good Wi-Fi, both were English-only, and neither did anything about the thing that was eating his teachers' time: making and marking tests.

We asked for a half-day workshop at their largest centre, and asked that three people be in the room besides the founder: a senior teacher, a centre manager, and the person who handled fees. Our side brought our engagement lead, a product designer and an engineer who had built our earlier assessment work.

We spent the first hour not talking about software at all. Each person walked us through their week on the whiteboard. The teacher's week was dominated by paper-setting and marking. The centre manager's week was attendance registers, timetable clashes and phone calls. The fees coordinator kept a ledger, a spreadsheet and a WhatsApp chat per family, and none of the three agreed with each other.

Then we asked the question that reframed the project: "If this worked perfectly a year from now, what would be different on a Monday morning?" The answers were specific. Teachers would walk in with papers already made. Students who missed class would have watched it the night before. The manager would know which batches were slipping before the monthly test told him. Parents would stop calling.

That list became our north star. It was not "an app"; it was four connected products — for students, teachers, parents and the business — sharing one data model.

Discovery is where most of the real requirements hide, so we went to them. Our designer and engagement lead spent two weeks across three centres of different sizes: sitting in classes, watching teachers set papers, and — with parents' permission — interviewing students about how they studied at home.

Three findings changed the design. First, a large share of students shared a phone with a sibling or parent, and many had it only in the evening. Anything that needed a live connection at a fixed time would fail them. Second, most students were far more comfortable reading explanations in Hindi, even when the exam itself was in English. Third, teachers did not want AI to write their papers for them — they wanted a first draft they could fix in ten minutes, in their own style, with questions they trusted.

We also found things we had not been told about: a centre that ran two batches in one room with a partition, a teacher who kept her best questions in a notebook she would not share, and a fee structure with seven different instalment plans.

The founder's original wish list had more than sixty items. A product that tries to do sixty things in its first release usually does none of them well, so we ran a prioritisation session where every feature had to answer one question: which Monday-morning goal does this move?

Some ideas were cut outright — a social feed for students, a built-in chat between students, and a custom video-conferencing system (we integrated an existing one instead). Others were deferred to a second phase, including a full content marketplace and AI-generated video lessons. What remained was thirty features that each traced back to a goal someone had said out loud in that first workshop.

We designed the student app first, because it had the hardest constraints. Our designer set a rule: every core screen had to work on a budget Android phone, in Hindi, with one thumb, on a patchy connection. That ruled out heavy animations and dense dashboards, and it pushed us towards a single "Today" screen — what to watch, what to practise and what is due — instead of a menu of modules.

The teacher dashboard went the other way. Teachers used it on a laptop or a centre desktop, often while preparing for class, so it could be information-dense. The centrepiece became the paper generator: pick the chapter, difficulty and question mix, get a draft paper, then edit, reorder or swap any question before exporting.

Parents got the simplest product of all. Most parents did not want another app, so we made WhatsApp the primary channel: a weekly progress summary, test results and fee reminders, with the parent app there for those who wanted more detail.

We tested clickable prototypes with students and teachers at two centres before writing production code. Two rounds of testing changed a lot: the student home screen lost half its buttons, and the paper generator gained a "replace this question" action that teachers used constantly.

We staffed Vidyora as one team rather than separate design, web, mobile and AI groups handing work to each other. Everyone joined the same weekly demo with the client, and the AI engineer sat in the teacher-dashboard stand-ups, because the paper generator was as much a UX problem as a model problem.

Every project has a handful of decisions that are expensive to reverse. We wrote each one down with the options we considered and why we chose what we did, and shared them with the client before committing. These were Vidyora's.

Here is everything that shipped in the first full release, grouped the way the product is organised. Each feature traces back to one of the Monday-morning goals from the first workshop.

We built in two-week sprints with a demo to the client at the end of each one — on real phones, not slides. The AI features were built alongside an evaluation set of real papers and answer sheets from the centres, so every change to prompts or models was scored before it reached a teacher.

The hardest part was not the AI. It was the fee module: seven instalment plans, sibling discounts, scholarships and part-payments that had to reconcile exactly with the fees coordinator's ledger. We imported two years of history and did not go live until the numbers matched to the rupee.

We did not launch everywhere at once. Vidyora went live first at a single centre for three weeks, with our engagement lead on site for the first days and a daily check-in after that. Teachers generated their first AI papers under supervision, and we watched how students actually used the app in the evenings.

The pilot surfaced problems no prototype could: a batch of phones with so little storage that offline downloads failed, a teacher who needed Sanskrit characters in questions, and a parent notification that went out at 6 a.m. Each was fixed before the next wave. The remaining centres were rolled out in two waves over the following weeks, each with a half-day training session for teachers and managers.

Teachers adopt AI when it respects their judgement. The paper generator succeeded because it produced a draft the teacher owned, not a finished paper they had to trust blindly. The answer-sheet evaluator succeeded because it showed its confidence and sent uncertain answers to the teacher instead of guessing.

Offline is not an edge case. For many students, offline was the main way they used the app, and designing for it first made the whole product faster for everyone.

Finally, the unglamorous modules — fees, attendance, timetables — are what made the platform indispensable to the business. The AI got people talking; the operations modules made sure nobody wanted to go back to the old way.