HowWeBuildanEdTechPlatformThatScalesto250KDailyUsers

This is the playbook we build with our team when an education business needs a real learning app, not a video catalog. The numbers above are how a build like this usually shapes up. One of these platforms, Youth Pathshala, runs at 250K+ daily active users today. The rest of this page is the engineering underneath that, the calls we made, the trade-offs, and the things we got wrong early and fixed.

The Problem We Keep Seeing

An education business ends up with its content scattered. Lectures live in one app. Test series in another. Study notes on a third. Students bounce between logins, lose their place, and quietly give up. The content was never the problem. The experience was broken, and a broken experience reads as a bad product even when the teaching is excellent.

Connectivity makes all of it worse. A big slice of the audience studies from places where the mobile network is unreliable. Video buffers forever. A download dies at 80 percent and starts over. On a 2G connection the course catalog will not even load. So the app has to work offline first. Not offline as a nice-to-have you add in version three, but offline baked into the data layer from the first commit.

And then there is retention, which is its own problem. A student watches a lecture once and never comes back. Without anything to pull them into review, what they learned starts fading within a week. So the brief is rarely subtle. Put everything in one place. Make it work on a bad network. And give the app a reason to nudge people back before the knowledge leaks out. That last one is what turns a content app into a learning app.

How We Build It

One cross-platform app in Flutter, with a Node.js API and PostgreSQL behind it on AWS. The whole thing is designed around a single rule: assume the network will fail. Video streams over HLS with adaptive bitrate, but every lecture can also download in the background for offline viewing. A student's progress queues up locally and syncs the moment a connection comes back. Nothing is lost when the signal drops, which on these networks happens constantly.

Live classes run on WebRTC, and when bandwidth falls under 500kbps the session drops to audio-only instead of freezing. The spaced-repetition engine is modeled on the Ebbinghaus forgetting curve, and it fires review prompts at the intervals where memory is about to slip. The student does not have to decide when to review. The app decides, per topic, per person.

The single Flutter codebase is not just a budget call. It means a feature ships to iOS, Android, and web on the same day. No iOS-first, Android-later split. No platform-specific feature gaps that drive support tickets. Our team kept shipping from one repository the whole way through, which is a big part of how a small team kept the velocity it did.

The Decisions That Mattered

Flutter over React Native was the first real argument. We weighed both on three things that actually mattered here: how clean offline persistence is, how fast we can build custom learning UI, and how painful long-term maintenance gets. Flutter won on all three for us. Sqflite and Hive made offline-first straightforward instead of a fight. And the widget system let us build progress rings, interactive quizzes, and drag-and-drop exercises noticeably faster than doing the same work twice in native views.

Video delivery was the second call, and we went with HLS over DASH. Broader device support, simpler to wire to CloudFront, fewer surprises. Each lecture gets encoded into four quality tiers (240p, 480p, 720p, 1080p) and the player switches on the fly as bandwidth moves. On a 2G connection a student still gets watchable 240p instead of a spinning loader. Ugly is fine. Frozen is not.

For the data store we picked PostgreSQL over a document database, and the reason is boring and correct. Course data is deeply relational. Students enroll in courses. Courses hold modules. Modules hold lessons. Lessons have prerequisites. Forcing that into a document model would have meant denormalization headaches and stale data everywhere. PostgreSQL gives us the relational backbone, and JSONB columns hand us flexibility exactly where we want it, like quiz configs and dynamic content blocks, without giving up integrity on the parts that need it.

Push notifications run on Firebase Cloud Messaging with a scheduling layer we wrote on top. The spaced-repetition engine does not blast generic reminders. It tracks each student's curve per topic and times the review prompt for the window where retention data says the memory is starting to go. This is not a nightly cron firing the same message at everyone. It is a per-student, per-topic notification graph, and that distinction is the whole point.

What Gets Built

What the Build Is Engineered to Do

These are the design targets we hold the system to, the engineering it takes to make a learning app fast and dependable on a bad network at scale. The daily-active-users figure is the real, measured result from Youth Pathshala. The rest describe the architecture, not a specific client's revenue.

Build It, or Use Moodle?

Build a custom platform, or stand up Moodle? Every EdTech founder hits this question early. The honest answer comes down to your scale, how distinctive your learning experience needs to be, and how much energy you are willing to spend fighting a platform that was not built for your students. Here is the comparison, costs as market context.

So when does a custom build actually make sense? When the learning experience is the product. Teachable is great if you are one instructor selling a course. It is the wrong tool the moment you need offline learning, adaptive review paths, your own branding without a platform's logo on it, and the freedom to build features no SaaS template will ever ship. A hosted tool also takes a cut of every sale and caps how far you can push the experience, which starts to bite hard at scale.

The offline-first pattern is not unique to education, either. We have pointed the same shape of architecture at healthcare apps for rural clinics, at fleet tracking where the GPS device loses signal out in the field, and at field tools used where the network is patchy on a good day. If your core differentiator depends on something the off-the-shelf platforms simply do not do, a custom build is the path that does not box you in later.

What We've Learned Building These

Offline-first is not a feature you add later. We built the whole data layer assuming the network would be down. Every response caches locally. Every action queues for sync. That cost us a couple of weeks up front in the architecture phase, and it is the single reason the app works at all for students on bad connections. Trying to retrofit offline onto an online-first app is not a patch. It is a rewrite, and a miserable one.

Encoding quality beats raw streaming speed, which caught us out at first. We tuned early for fast delivery and let the encoding presets slide. Then students started complaining that the text on lecture slides looked blurry, even at 720p. We moved to a custom profile that favors sharpness over compression. Storage went up a bit. The complaints went away completely. For a lecture slide full of equations, sharp matters more than small.

Spaced repetition only works if the nudges feel useful, not naggy. Our first cut fired four or five review reminders a day. Uninstalls jumped. We pulled it back to two a day at most, grouped by subject, with a snooze for topics a student already feels solid on. Uninstalls dropped back to normal, and engagement with the prompts went up, because people stopped fearing their notification tray. The lesson is dull and true. Respect the user's attention or lose the user.

Flutter web needs real attention to load fast. Our first web build was 4MB, and on a slow line that is eight or ten seconds of staring at nothing. We deferred non-critical routes, lazy-loaded the heavy widgets, and tree-shook the Material icons we were never using. The bundle came down to 1.2MB and first meaningful paint slid under three seconds on 3G. None of it is glamorous. All of it is the difference between a student waiting and a student leaving.

Frequently Asked Questions

What a Build Like This Costs in the Market

For planning, a complete customer-facing EdTech app of this shape sits in the $80,000 to $140,000 range in the market right now. Roughly, the Flutter mobile and web work is the biggest slice, the backend API and database is the next, and then video infrastructure, design, and cross-device QA fill in the rest. Running it tends to start at a few hundred dollars a month and climb toward $800 to $1,500 once you are at hundreds of thousands of daily users, with video storage and streaming as the heaviest cost. These are market ranges to budget against, not a Geminate Solutions quote. Your real number depends on how much content you serve and how custom the learning experience gets.

The more useful way to think about it is against the cost of not building it. If students keep dropping off because the content is scattered across three apps and nothing works on their network, that churn is the real bill you are already paying. A build like this is what turns a content library into a product students open every day. Whether the math works for you is exactly the conversation we would rather have up front than oversell.

Why Teams Bring This to Us

A learning app like this needs Flutter, real-time video, and offline-sync experience living in the same heads, and that mix is hard to assemble in a hurry. More often the issue is not skill at all. The in-house team knows education cold but is already flat out on content and the core business, and pulling them onto a full mobile build would stall everything else for months. Building it with our team lets the business keep moving while the platform gets built in parallel, by people who have shipped this exact shape of thing before.

Time to launch is usually the real driver. In EdTech the audience moves, and every month without an app that works offline is another month of students lost to whatever does work on their phone. We build with you as a product partner, not a code shop taking a spec over the wall. That is why offline pre-fetch, or the way the review prompts got capped at two a day, often comes from a suggestion on our side. We have watched which features actually keep learners coming back across the products we have built, and we would rather tell you than wait to be asked.

Related Resources

• EdTech Solutions by Geminate SolutionsFull overview of our education technology work
• EdTech App Development Cost GuideMarket pricing breakdown for education platforms
• Education Exam Preparation Case StudyAnother EdTech build with test series and analytics
• Virtual Classroom Platform Case StudyLive class infrastructure and student engagement
• Custom Software Development ServicesHow we build and ship products with our team