What Problem Were We Solving and What Did the Founder Need?
Over 18 months we took an EdTech platform from a founder's wireframe to 250,000 daily active users. The app now handles 2,000+ concurrent video streams and chews through 50,000 quiz submissions an hour, all on a $4,200/month infrastructure bill. What follows is every architectural call we made, what it cost, and where we got it wrong.
The founder showed up with a very specific gap to fill: CA exam prep for 250,000+ students. The platforms students already used were either pricey (Unacademy ran $200+/year) or just painful to use on a cheap Android phone. The brief itself was tight. Build a mobile app with live classes, recorded lectures, AI-powered quizzes, and doubt resolution. Price point, $50/year. Budget, $40K for the MVP. Timeline, 12 weeks.
Statista valued the global EdTech market at $185 billion in 2025, growing at 13.6% CAGR. Honestly, none of that mattered to this founder. What mattered was 250K students in one exam category who the existing tools had let down. And that narrow focus is usually what separates education software development projects that work from the ones that stall. A defined audience. A pain point you can actually measure.
We spent two weeks on a discovery sprint before anyone wrote a line of code. Interviewed 40 students. Mapped how they actually study day to day. The numbers were telling: 73% studied on phones with under 4GB RAM, 62% fought with patchy internet, and 89% preferred quiz-based revision over sitting through video. Those three facts ended up driving nearly every architectural decision we made later.
So if you're a CTO sizing up something similar, an edtech app development project with video, quizzes, and real scale ambitions, this walks through what actually happened. Not the cleaned-up marketing version.
What Architecture Decisions Made 250K DAU Possible?
HolonIQ reported that 72% of EdTech startups that failed to scale blamed technical architecture as the main bottleneck (2024 EdTech Intelligence Report). We had no intention of joining that group. So here's the real stack, no hand-waving.
Frontend: Flutter with BLoC pattern. One codebase, both iOS and Android. We picked Flutter over React Native for a single reason. Performance on cheap hardware. Our research had shown 73% of students on phones with under 4GB RAM, and Flutter's compiled Dart code beat React Native's JavaScript bridge by 30-40% on those devices in our own benchmarks. BLoC kept state predictable across 200+ screens. Hot reload alone probably saved us 3 weeks over the first 6 months of iteration.
Backend: Node.js + Express (API) and Python FastAPI (quiz engine + ML). The API server ran auth, course management, payments, and user profiles. The quiz engine lived on its own, Python, because the adaptive learning algorithm leaned on scikit-learn for spaced-repetition scoring. Splitting those two apart was the smartest move we made all project. When quiz traffic jumped 10x during exam season, we scaled the Python service on its own and never touched the main API.
Data layer: PostgreSQL + Redis + S3. PostgreSQL held user data, course catalogs, and subscription records. Redis took session caching, real-time leaderboards, and the quiz scoring queues. S3 stored every video file, north of 12TB by month 12. We went with PostgreSQL over MongoDB because education data is relational to its bones. Students belong to courses. Courses have chapters. Chapters have quizzes, and quizzes have questions with analytics attached. That's a relational model, plain and simple.
Video: Agora SDK (live) + HLS via CloudFront (recorded). Live streaming ran on Agora for the interactive sessions, up to 500 concurrent viewers at sub-300ms latency. Recorded lectures got transcoded to HLS and served off CloudFront. This split mattered a lot. Agora bills per-minute for live streaming, and pushing recorded content through a CDN instead cost 90% less than routing everything through Agora.
Real-time features: WebSocket for quiz battles and doubt chat. Firebase Auth handled login with custom JWT tokens for our API. Razorpay ran subscriptions for the Indian market. Push notifications went out through Firebase Cloud Messaging, sitting behind a custom targeting layer that tuned nudges to each student's study pattern.
Why Flutter specifically? It cut build cost by 40% against going native. One team of 4 developers instead of two teams of 3. And hot reload meant we could put a UI change in front of real students in 30 seconds, not rebuild-and-redeploy. For edtech platform development, where you're reworking UX every week, that kind of speed compounds fast.
How Much Did It Actually Cost From MVP to 250K Users?
Per Deloitte's 2024 Technology Budgets survey, the average SaaS startup lowballs its infrastructure costs by 2.5x over 18 months. We tracked every dollar to avoid exactly that. Here are the real numbers from this edtech app development project.
MVP Phase (0-10K users, months 1-4): $40,000 in development (4 developers, 12 weeks, blended $25/hr) plus $400/month for infrastructure, a single DigitalOcean droplet, managed PostgreSQL, S3 storage, and an Agora starter plan. First-year total for the phase, $44,800. What the MVP shipped with: auth, course catalog, a recorded-only video player, a basic quiz engine, and Razorpay payments.
Growth Phase (10K-50K users, months 5-10): $25,000 more in feature work. Live streaming via Agora. Real-time doubt resolution over WebSocket chat. Gamification, so XP points, streaks, leaderboards. Plus push notification campaigns. Infrastructure climbed to $1,200/month once we added Redis, scaled the database, and started paying real Agora bills. Phase total, $39,400.
Scale Phase (50K-250K users, months 11-18): $35,000 in performance engineering. Database read replicas. CDN optimization. App size reduction. An adaptive quiz engine with ML, and an automated video transcoding pipeline. Infrastructure peaked at $4,200/month. Phase total, $85,400.
18-month all-in: roughly $170,000. That number covers development, infrastructure, and ongoing maintenance. It does not cover content creation (the founder's own team handled that) or any marketing.
Planning a similar platform? We can scope your MVP in a 30-minute call.
Here's the economics that made it pencil out. At 250K DAU with a 12% paid conversion, the platform landed around 30,000 paying subscribers at $50/year. So $1.5M ARR against $170K of total investment and $50K/year in ongoing infrastructure. Revenue grew 25x while infrastructure costs grew 10x. The founder broke even by month 9. The real insight? Build for scale starting around month 6, not month 1. We didn't over-build the MVP, but we did design the data layer to absorb 10x growth right from the start.
What Were the Three Biggest Technical Challenges?
Gartner's 2024 report on application scaling found that 68% of performance issues in growing apps trace back to three places: media delivery, database contention, and client-side bloat. We hit all three. Here's how we fixed each.
Challenge 1: Video streaming costs blew up at 5K concurrent viewers. Agora bills per-viewer-minute on live streaming. At 5,000 concurrent viewers in a 90-minute live class, one session cost $180. Three sessions a day meant $540/day on video alone. Our fix was to move ALL recorded content to HLS via CloudFront. Agora live streaming got reserved strictly for the interactive stuff, classes where the instructor was fielding questions, running polls, or working through problems live. Recorded lectures, which made up 85% of watch time, ran off the CDN for a fraction of the price. Monthly video costs fell from $16,200 to $2,400.
Challenge 2: the quiz engine fell over under exam-season load. In the peak prep weeks the platform was processing 50,000 quiz submissions an hour. Each one fired a PostgreSQL write (the answer record), a read (the correct-answer lookup), a score calc, and a leaderboard update. At that volume, PostgreSQL row locks pushed response times from 200ms up past 3 seconds. The fix was to make Redis the real-time scoring layer. Answers got validated and scored entirely in Redis, and a background worker batch-wrote results to PostgreSQL every 5 minutes for persistence and analytics. Response time dropped back to 90ms. Students noticed nothing, except that the app felt quicker.
Challenge 3: app size and crashes on budget phones. The first Flutter APK weighed 45MB. On a 32GB device where the OS and other apps had already eaten 20GB, students simply couldn't install it. Crash rate on phones with under 3GB RAM sat at 2.1%. The fix came in three parts. First, deferred components in Flutter, so screens a user hadn't opened yet never loaded into memory. Second, an image compression pipeline serving WebP at 60% quality, visually the same but 70% smaller. Third, a rewritten video player that aggressively releases memory when minimized. APK size dropped to 28MB. Crash rate fell to 0.3%. The Google Play rating climbed from 3.8 to 4.6 stars inside two months.
With hindsight, every one of these was avoidable. But we didn't launch with 250K users. We launched with 200. The architecture that holds up at 200 is not the one that holds up at 250K. Building for where you are now while quietly preparing the data layer for where you're headed, that's the real skill in custom development.
What Would We Do Differently If We Started Today?
An honest retrospective earns more trust than a polished case study ever will. McKinsey's 2024 engineering leadership survey found teams who documented their mistakes cut repeat failures by 62%. So here's what we'd do differently.
We'd reach for Supabase instead of a custom auth + API layer. We burned roughly $15,000 and 4 weeks hand-rolling authentication, row-level security policies, and a REST API from scratch on Node.js. Supabase hands you PostgreSQL, auth, real-time subscriptions, and auto-generated APIs out of the box. For an MVP, that's a month back. We'd still split the quiz engine off as its own FastAPI service, since Supabase doesn't replace custom business logic, but the boilerplate it saves is huge.
We'd wire up analytics on day one. We didn't add Mixpanel until 50K users (month 8), which meant 7 months of behavioral data gone. We had no read on which features drove retention, where screens leaked users, or which quiz formats actually taught better. By the time the data showed up, we'd already shipped three features nobody touched. That was $8,000 of wasted dev time. Analytics from day one would have paid for itself by month 3.
We'd bring on a dedicated QA engineer from month 3. Manual testing dragged on us. Two developers were sinking about 6 hours a week each into manual regression, so 12 developer-hours a week, $600/week at our rates. An automated suite plus a QA engineer would have run $2,500/month and saved $2,400/month in developer time, catching bugs sooner on top. In hindsight the math was obvious.
What we would NOT change. Flutter was right. PostgreSQL was right. Launching an MVP with 4 core features instead of 15 was right. The founder wanted everything at once, and we pushed back hard on scope. The MVP went out with auth, video, quizzes, and payments. Nothing more. That discipline is exactly what let us hit the 12-week deadline and start hearing from real users before month 4.
The team that built this is taking new projects. Start with a paid pilot sprint.
How Can You Build Something Similar?
The World Economic Forum projects global EdTech spending will reach $400 billion by 2028. If you're planning a learning management system development project, here's the phased framework we'd recommend, drawn straight from what we learned.
Phase 1, MVP (weeks 1-12, budget $30K-$50K): Build only the core value proposition. For an education app that's user authentication, a course catalog with video playback (HLS, not live), a quiz engine with basic analytics, and payments (Stripe or Razorpay, depending on your market). Skip gamification. Skip live streaming. Skip AI for now. Ship it, get 500 users, and find out what they actually want. Most founders wildly overestimate how many features they need at launch. You need one feature that works perfectly. Not ten that half-work.
Phase 2, Growth features (months 4-8, budget $20K-$35K): Now you've got real user data, so build off what students actually use. For us the top three asks were live classes (Agora SDK), doubt resolution (WebSocket chat), and study streaks (gamification). If users aren't asking for a feature, don't build it. This phase also brings in push notification infrastructure and some basic A/B testing. Revenue should start showing up here. If it doesn't, fix your pricing model before you build anything else.
Phase 3, Scale (months 9-18, budget $30K-$50K): Performance engineering, infrastructure work, and the AI-powered features. This is where CDN delivery, Redis caching, database read replicas, adaptive learning algorithms, and automated content pipelines come in. A realistic all-in budget to reach 100K+ users lands at $80K-$135K across the three phases.
Or you bring in a dedicated build-partner team and ship continuously, with the scope flexing quarter to quarter as revenue comes in. That route works well when you've got a technical co-founder steering the day-to-day. No long lock-in, no big upfront hit, and the team size moves with the business instead of against it.
Every EdTech platform comes down to one decision first. Build the MVP that proves the model. We can have your first sprint running inside 2 weeks. Talk to the team that built this.
