HowWeBuiltanEdTechPlatformThatScaledto250KDailyUsers

In 18 months, we took an EdTech platform from a founder's wireframe to 250,000 daily active users. The app handles 2,000+ concurrent video streams, processes 50,000 quiz submissions per hour, and runs on a $4,200/month infrastructure bill. Here's every architectural decision, cost, and mistake along the way.

The founder came to us with a specific gap in the market: CA exam preparation for 500,000+ students. Existing platforms were either expensive — Unacademy charged $200+/year — or had terrible UX on budget Android devices. The brief was clear. Build a mobile app that delivers live classes, recorded lectures, AI-powered quizzes, and doubt resolution. Price point: $50/year. Budget: $40K for MVP. Timeline: 12 weeks.

Statista valued the global EdTech market at $185 billion in 2025, growing at 13.6% CAGR. But market size didn't matter to this founder. What mattered was 500K students in a specific exam category who were underserved by existing tools. That's the kind of focus that makes education software development projects succeed — a defined audience with a measurable pain point.

We ran a two-week discovery sprint before writing any code. Interviewed 40 students. Mapped their daily study routines. Found that 73% studied on phones with under 4GB RAM, 62% had inconsistent internet, and 89% wanted quiz-based revision over passive video watching. Those three data points shaped every architectural decision that followed.

If you're a CTO planning something similar — an edtech app development project with video, quizzes, and scale ambitions — this case study walks through what actually happened. Not the marketing version.

HolonIQ reported that 72% of EdTech startups that failed to scale cited technical architecture as the primary bottleneck (2024 EdTech Intelligence Report). We weren't going to be one of them. Here's the real stack — no hand-waving.

Frontend: Flutter with BLoC pattern. One codebase for iOS and Android. We picked Flutter over React Native for one reason: performance on low-end devices. Our user research showed 73% of students used phones with under 4GB RAM. Flutter's compiled Dart code outperformed React Native's JavaScript bridge on those devices by 30-40% in our benchmarks. BLoC kept state management predictable across 200+ screens. Hot reload saved us roughly 3 weeks during the first 6 months of iteration.

Backend: Node.js + Express (API) and Python FastAPI (quiz engine + ML). The API server handled auth, course management, payments, and user profiles. The quiz engine was a separate service — Python because the adaptive learning algorithm used scikit-learn for spaced repetition scoring. Splitting these into two services was the best decision we made. When quiz traffic spiked 10x during exam season, we scaled the Python service independently without touching the main API.

Data layer: PostgreSQL + Redis + S3. PostgreSQL stored user data, course catalogs, and subscription records. Redis handled session caching, real-time leaderboards, and quiz scoring queues. S3 stored all video files — over 12TB by month 12. We chose PostgreSQL over MongoDB because education data is deeply relational: students belong to courses, courses have chapters, chapters have quizzes, quizzes have questions with analytics. That's a relational model.

Video: Agora SDK (live) + HLS via CloudFront (recorded). Live streaming used Agora for interactive sessions — up to 500 concurrent viewers with sub-300ms latency. Recorded lectures were transcoded to HLS format and served through CloudFront CDN. This split was critical. Agora charges per-minute for live streaming. Serving recorded content through a CDN cost 90% less than routing everything through Agora.

Real-time features: WebSocket for quiz battles and doubt chat. Firebase Auth handled authentication with custom JWT tokens for our API. Razorpay managed subscriptions for the Indian market. Push notifications went through Firebase Cloud Messaging with a custom targeting layer that personalized nudges based on study patterns.

Why Flutter specifically? It saved 40% in build cost versus native. One team of 4 developers instead of two teams of 3. And the hot reload workflow meant we could test UI changes with real students in 30 seconds instead of rebuilding and redeploying. For edtech platform development where you're iterating on UX weekly, that speed compounds.

According to Deloitte's 2024 Technology Budgets survey, the average SaaS startup underestimates infrastructure costs by 2.5x over 18 months. We tracked every dollar. 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 for 12 weeks at blended $25/hr) plus $400/month in infrastructure (single DigitalOcean droplet, managed PostgreSQL, S3 storage, Agora starter plan). Total first-year cost for this phase: $44,800. The MVP had: auth, course catalog, video player (recorded only), basic quiz engine, and Razorpay payments.

Growth Phase (10K-50K users, months 5-10): $25,000 in additional feature development — live streaming via Agora, real-time doubt resolution with WebSocket chat, gamification (XP points, streaks, leaderboards), and push notification campaigns. Infrastructure climbed to $1,200/month as 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, adaptive quiz engine with ML, and automated video transcoding pipeline. Infrastructure hit $4,200/month at peak. Phase total: $85,400.

18-month all-in cost: approximately $170,000. That covers development, infrastructure, and ongoing maintenance. It doesn't include content creation (the founder's team handled that) or marketing.

The economics that made this work: at 250K DAU with a 12% paid conversion rate, the platform generated roughly 30,000 paying subscribers at $50/year. That's $1.5M ARR against $170K total investment and $50K/year in ongoing infrastructure. Revenue grew 25x while infrastructure costs grew 10x. The founder broke even by month 9. Building for scale from month 6 — not month 1 — was the key insight. We didn't over-engineer the MVP, but we designed the data layer to handle 10x growth from the start.

Gartner's 2024 report on application scaling found that 68% of performance issues in growing apps trace back to three areas: media delivery, database contention, and client-side bloat. We hit all three. Here's how we solved each one.

Challenge 1: Video streaming costs exploded at 5K concurrent viewers. Agora bills per-viewer-minute for live streaming. At 5,000 concurrent viewers watching a 90-minute live class, a single session cost $180. Three sessions daily meant $540/day just for video. The fix: we moved ALL recorded content to HLS streaming via CloudFront. Live streaming through Agora was reserved strictly for interactive sessions — classes where the instructor took questions, ran polls, or did live problem-solving. Recorded lectures (which accounted for 85% of watch time) ran through the CDN at a fraction of the cost. Monthly video costs dropped from $16,200 to $2,400.

Challenge 2: Quiz engine performance collapsed under exam-season load. During peak exam prep weeks, the platform processed 50,000 quiz submissions per hour. Each submission triggered a PostgreSQL write (answer record), a read (correct answer lookup), a score calculation, and a leaderboard update. At that volume, PostgreSQL row locks caused response times to spike from 200ms to 3+ seconds. The fix: Redis became the real-time scoring layer. Quiz answers were validated and scored entirely in Redis. A background worker batch-wrote results to PostgreSQL every 5 minutes for persistence and analytics. Response time dropped back to 90ms. Students didn't notice any change except that the app got faster.

Challenge 3: App size and crash rates on budget devices. The initial Flutter APK weighed 45MB. On devices with 32GB storage (where 20GB was already used by the OS and other apps), students couldn't install it. Crash rate on devices with under 3GB RAM sat at 2.1%. The fix was three-fold. First, we implemented deferred components in Flutter — screens the user hadn't visited yet weren't loaded into memory. Second, we built an image compression pipeline that served WebP at 60% quality (visually indistinguishable, 70% smaller files). Third, we rewrote the video player to release memory aggressively when minimized. APK size dropped to 28MB. Crash rate fell to 0.3%. Google Play Store rating went from 3.8 to 4.6 stars within two months of these fixes.

Every one of these problems was avoidable with hindsight. But we didn't have 250K users on day one. We had 200. The architecture that works at 200 users isn't the architecture that works at 250K. Building for the current scale while preparing the data layer for the next scale — that's the actual skill in custom development.

Honest retrospectives build more trust than polished case studies. McKinsey's 2024 engineering leadership survey found that teams who documented their mistakes reduced repeat failures by 62%. Here's what we'd change.

We'd use Supabase instead of a custom auth + API layer. We spent roughly $15,000 and 4 weeks building authentication, row-level security policies, and a REST API from scratch on Node.js. Supabase gives you PostgreSQL, auth, real-time subscriptions, and auto-generated APIs out of the box. For an MVP, that's 4 weeks saved. We'd still break out the quiz engine as a separate FastAPI service — Supabase doesn't replace custom business logic — but the boilerplate savings are massive.

We'd implement analytics on day one. We added Mixpanel at 50K users (month 8). That means we lost 7 months of behavioral data. We had no idea which features drove retention, which screens had drop-off, or which quiz formats produced better learning outcomes. By the time we had data, we'd already built three features that nobody used. Those cost $8,000 in wasted development time. Analytics from day one would have paid for itself by month 3.

We'd hire a dedicated QA engineer from month 3. Manual testing slowed us down. Two developers spent roughly 6 hours per week on manual regression testing. That's 12 developer-hours per week — $600/week at our rates. An automated test suite with a dedicated QA engineer would have cost $2,500/month but saved $2,400/month in developer time while catching bugs earlier. The math was obvious in retrospect.

What we would NOT change: Flutter was the right call. PostgreSQL was the right call. Starting with an MVP that had 4 core features instead of 15 was the right call. The founder wanted to build everything at once. We pushed back hard on scope. The MVP launched with auth, video, quizzes, and payments. Nothing else. That discipline is what let us hit the 12-week deadline and start getting real user feedback before month 4.

The World Economic Forum projects that 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 based on what we learned.

Phase 1 — MVP (weeks 1-12, budget $30K-$50K): Build only the core value proposition. For an education app, that means: user authentication, course catalog with video playback (HLS, not live streaming), quiz engine with basic analytics, and payment integration (Stripe or Razorpay depending on market). Skip gamification. Skip live streaming. Skip AI features. Ship it, get 500 users, and learn what they actually want. Most founders overestimate how many features they need for launch. You need one feature that works perfectly, not ten that work partly.

Phase 2 — Growth features (months 4-8, budget $20K-$35K): Now you have user data. Build based on what students actually use. For us, the top three requests were: live classes (added Agora SDK), doubt resolution (WebSocket chat), and study streaks (gamification). If your users don't ask for a feature, don't build it. This phase also includes push notification infrastructure and basic A/B testing. Revenue should start in this phase — if it doesn't, revisit your pricing model before building more.

Phase 3 — Scale (months 9-18, budget $30K-$50K): Performance engineering, infrastructure optimization, and AI-powered features. This is where you add CDN delivery, Redis caching, database read replicas, adaptive learning algorithms, and automated content pipelines. The total realistic budget to reach 100K+ users: $80K-$135K across all three phases.

Alternatively, start with a 3-person augmented team at $9K-$15K/month and build continuously. This works well if you have a technical co-founder who can direct the team's daily work. The augmented model lets you adjust team size quarterly based on revenue — no long-term commitments, no large upfront investment.

Every EdTech platform starts with one decision: build the MVP that proves the model. We can have your first sprint running within 2 weeks. Talk to the team that built this.