An EdTech startup had 35,000 students and a platform that would fail at 60,000. A Series A was conditional on a credible scaling plan.
A Melbourne EdTech platform connecting high school students with tutors had grown to 35,000 active users. The founders had modelled growth and identified a ceiling: the architecture would not support more than 60,000 concurrent users. A Series A investor had offered a term sheet conditional on a credible scaling plan backed by senior technical judgment.
Our fractional CTO conducted a load testing programme identifying the precise failure points: a single WebSocket server handling all real-time tutoring connections, N+1 queries in the student matching algorithm, and static asset delivery via the same servers as the application.
A three-phase scaling programme: Phase 1 horizontally scaled WebSocket infrastructure using Socket.io with Redis Pub/Sub and fixed N+1 queries. Phase 2 introduced read replicas and query caching. Phase 3 redesigned student matching as an asynchronous background job. All phases used feature flags for gradual rollout and instant rollback. The Series A narrative was rebuilt around the technical scaling thesis.
The platform now supports 280,000 active students with zero downtime events exceeding one minute over 12 months. The Series A closed at $3.2M. The founding team promoted their lead developer to CTO, marking a natural end to the engagement.
You should not rebuild working software because it cannot scale. You should understand exactly why it cannot scale and fix precisely those things. Everything else is waste.
Book a free call with a CTO who has 27 years of hands-on experience — and a track record of measurable outcomes.