Back to Blog
Case Study

How We Built an AI-Powered EdTech Platform in 8 Weeks

Sophylabs Engineering
7 min read

Eight weeks. That's how long it took to go from kickoff to a live, subscription-enabled, AI-powered EdTech platform with real users and real payments. Not a prototype. Not a landing page with a waitlist. A working product.

We're going to skip the inspirational narrative and talk about what actually happened. The architecture decisions, the trade-offs, the timeline, and the parts that were harder than expected. If you're a founder evaluating MVP development companies, this is what the process looks like when it works.

The Problem Sophyspark Came In With

Sophyspark's founder had a clear vision: an AI-powered platform that generates personalized educational content for children, with subscription tiers for parents and educators. The requirements were specific.

  • -AI-generated educational content. Personalized stories, activities, and visual materials generated on demand based on the child's age, interests, and learning goals.
  • -Investor-ready MVP. Not a demo, but a product that could onboard real users, process real payments, and demonstrate real engagement metrics for an upcoming fundraise.
  • -Fixed timeline, fixed budget. Eight weeks, no extensions. The fundraise timeline was immovable, and the budget was set. We needed to deliver a complete product, not a partial one.
  • -Real users and real payments. The platform needed to support user registration, subscription management through Stripe, and a parent dashboard for monitoring usage and content.

Weeks 1-2: Architecture First, Code Second

We spent the first two weeks making decisions, not writing features. This is the part most founders want to skip, and it's the part that saves the most time later.

The key questions we resolved before writing a line of product code:

  • -Where does AI generation happen? Client-side was out. The latency for image generation (Google Imagen) made synchronous requests impractical. We designed a server-side queue with realtime status updates pushed to the client.
  • -How do we handle authorization with subscription tiers? Supabase Row Level Security (RLS) policies tied to subscription status. Free users see limited content. Paid users get full generation access. The authorization logic lives in the database, not the application code.
  • -What's the Stripe integration model? Webhooks as the source of truth. Stripe tells us when a subscription starts, renews, or cancels. We never poll. The database state always reflects the latest webhook event.
  • -How do we handle Google Imagen latency? Image generation takes 5 to 15 seconds. We built an async queue that processes requests in the background and pushes realtime status updates through Supabase's built-in realtime channels.

The Stack Decision (and Why We Made It)

Every technology choice was driven by the 8-week deadline. We chose tools that eliminated infrastructure work so we could focus entirely on product features.

  • -Next.js for the frontend. Server-side rendering for SEO (critical for an EdTech product that needs organic discovery), API routes for backend logic, and a deployment pipeline through Vercel that eliminated DevOps overhead.
  • -Supabase for auth, database, and realtime. PostgreSQL with Row Level Security, managed authentication (email, Google OAuth), and built-in realtime subscriptions. This replaced what would have been three separate services and weeks of integration work.
  • -Google Imagen AI with async queue. Image generation requests go into a server-side queue. When generation completes, the result is stored in Supabase Storage and the client receives a realtime notification. No polling, no loading spinners that last 15 seconds.
  • -Stripe for billing. Checkout sessions for initial subscriptions, customer portal for management, and webhooks as the single source of truth for subscription state. We never store payment details. Stripe handles everything PCI related.

Weeks 3-6: The Build

With architecture locked, the build phase moved fast. We ran weekly demos with the founder, which served two purposes: validating that we were building the right thing, and surfacing misalignments before they became expensive.

By the end of week 6, the platform had:

  • -Complete auth flow. Email and Google OAuth registration, email verification, password reset, and session management through Supabase Auth.
  • -Stripe checkout and subscription management. Three subscription tiers, upgrade/downgrade flows, cancellation handling, and a customer billing portal.
  • -Full AI content generation pipeline. Text content generated on demand, images queued and processed asynchronously, and results delivered through realtime updates.
  • -Parent dashboard. Content library, generation history, child profile management, and subscription status. Everything a parent needs to manage their account in one place.
  • -Realtime updates. When AI content finishes generating, the parent sees it appear in their dashboard without refreshing. This small detail made the product feel polished and responsive.

Weeks 7-8: Polish, Testing, and Launch

The final two weeks were dedicated to structured QA, performance optimization, and launch preparation. We ran end-to-end tests across the entire user journey: registration, subscription, content generation, dashboard interaction, and cancellation.

Performance tuning focused on the AI generation pipeline, where we optimized queue processing and reduced average delivery time from 12 seconds to 7 seconds. We also implemented caching for frequently requested content types, which reduced AI API costs by approximately 30%.

The platform launched on schedule. No deadline extension. No "soft launch" that's really a delayed launch with a different name.

The Results

What shipped after 8 weeks:

  • -100% automated content pipeline. No manual content creation. Every piece of educational material is generated by AI based on the child's profile and learning goals.
  • -Live subscriptions processing real payments. Stripe integration handling recurring billing, upgrades, downgrades, and cancellations without manual intervention.
  • -Investor-ready product. Real users, real engagement data, and a working revenue model. The founder walked into investor meetings with a live product, not a pitch deck with mockups.

What This Actually Takes

An 8-week MVP build is not magic. It's the result of specific conditions and deliberate choices. Here's what makes it possible.

  • -Senior engineers with 12+ years of experience. Junior developers can't make the architectural decisions required in week one. The speed comes from engineers who have built similar systems before and know which shortcuts are safe and which will cost you later.
  • -Fixed scope and fixed price. For a build like this, the budget typically falls between $15,000 and $25,000. That covers architecture, development, QA, and launch support. No hourly billing, no surprise invoices, no scope creep.
  • -Direct communication. No project managers relaying messages between you and the engineers. You talk directly to the people writing the code. Questions get answered in hours, not days.
  • -Architecture that doesn't need a rebuild. The MVP is built on the same stack and patterns you'll use at scale. When you hire your first engineer, they inherit clean code and a solid foundation, not technical debt that needs to be rewritten before anything new can be built.

Ready to Build Your MVP in 8 Weeks?

If you have a clear idea, a defined budget, and a deadline that matters, this is exactly the kind of build we do best. Let's have a conversation.

Free 30-minute call | No commitment