An edtech founder came to me with a problem that did not feel like a technical problem at first. Her adaptive learning platform had 800 active students. A school district deal had just closed that would bring in 12,000 students over the summer. The platform worked fine for 800 users. Nobody had any idea what would happen with 12,000.
The answer, after two weeks of load analysis: several things would break, two would break catastrophically, and one of the catastrophic ones - the video delivery infrastructure - would have resulted in a bill from their CDN provider that exceeded the entire annual contract value of the district deal.
We spent six weeks before the district onboarding making targeted changes. Not a rebuild - surgical fixes to the highest-risk components. The onboarding happened on schedule. The platform held.
The district became a reference customer that led to three more district deals. The six weeks of work paid for itself in the first month.
Content Delivery: The Cost Center That Kills EdTech Margins
Video is the primary content format in most learning platforms. It is also the most expensive infrastructure cost to get wrong.
The mistakes I see most often in early-stage edtech:
Storing video files on the same storage as application data. This seems efficient until you realize video files are orders of magnitude larger than application data and have completely different access patterns. Video should be on object storage (S3 or equivalent) from day one, not on your application servers.
Serving video directly from object storage without a CDN. Your students are distributed geographically. Video served from a single S3 bucket has latency problems for students far from that region, and when 500 students try to start their lesson simultaneously at 8 AM, you get rate-limited or the costs spike unexpectedly.
Not implementing adaptive bitrate streaming. Video served as a single file fails for students with slow internet connections. HLS or DASH streaming with multiple quality levels lets the player adapt to the available bandwidth. This is a non-trivial implementation but it dramatically improves the experience for students outside metropolitan areas - which is most of them in district deals.
The right architecture for edtech video: object storage for files, CDN for delivery, adaptive bitrate for encoding, and cost tracking at the per-content-item level. The last point is often overlooked: you need to know which content is expensive to serve so you can optimize the right things.
Assessment Engines: Where EdTech Gets Technically Complex
The assessment layer is where most learning platforms reveal their architectural limitations. Early-stage platforms often build assessments as a simple quiz feature. This works for basic multiple-choice questions, but it breaks down when requirements evolve.
The common evolution path:
Phase 1: Multiple choice questions stored in a database table. Simple, works fine.
Phase 2: Question banks, where questions are tagged by topic and difficulty and randomly sampled for each student. Requires a question metadata model and sampling logic.
Phase 3: Adaptive assessment, where question difficulty adjusts based on student performance. Requires scoring algorithms (usually IRT - Item Response Theory) and a real-time feedback loop.
Phase 4: Proctored assessment, where you need to detect cheating signals. Requires webcam integration, screen monitoring, and sometimes lockdown browser features.
Each phase requires design work that is hard to retrofit if the previous phase was not built with it in mind. I have seen platforms where Phase 1 was built as a single database table with no extensibility, and the cost of adding Phase 2 features was a complete rebuild of the assessment system.
The practical recommendation: when you are building your first assessment feature, spend a week designing the question model to support the next two phases even if you are not implementing them yet. A flexible question schema, a clean separation between question storage and scoring logic, and a results model that captures enough data to support analytics - these design decisions are cheap at the start and expensive to add later.
Accessibility: A Legal and Market Requirement, Not a Nice-to-Have
Section 508 compliance in the US requires that software used by educational institutions receiving federal funding is accessible to users with disabilities. Most public school districts receive federal funding. If you are selling to districts, accessibility is not optional.
WCAG 2.1 AA is the standard. The specific requirements that affect edtech most:
Video content requires captions and, for recorded content, transcripts. If your platform has video content, every video needs captions. This is both a legal requirement and a significant content operations challenge. Automated captioning has improved dramatically but still requires human review for accuracy in educational contexts.
The application interface needs to be keyboard navigable and screen reader compatible. This affects how you build UI components, how you handle focus management, and how you structure your HTML. If you are using a component library, you need to verify that it is built with accessibility in mind - many are not.
Color contrast ratios, font sizing, and zoom support all have specific requirements that affect how you design the visual interface.
The mistake I see most often: treating accessibility as a feature to add before an enterprise sale. The right approach is to build with accessibility in mind from the start, because retrofitting it into an existing product is expensive and often incomplete.
One engagement I did involved a platform that had been operating for two years before their first district deal surfaced the Section 508 requirement. The retrofit took four months and required touching almost every component in the UI. If it had been part of the original design, it would have added two weeks.
Rostering and Integration Standards
Every school district uses a Student Information System - PowerSchool, Skyward, Infinite Campus, Clever, ClassLink. When you sell a district deal, they expect your platform to integrate with their SIS for rostering: automatically provisioning student and teacher accounts based on data from their system.
The edtech integration standard for rostering is Clever (as a middleware) or OneRoster (as a direct API standard). Clever is used by about 75% of US districts and is the easiest integration path - they pull district data and expose it to you through a normalized API. OneRoster is the underlying standard that an increasing number of districts are implementing directly.
The practical guidance: integrate with Clever as your first priority. It gives you access to the vast majority of the district market through one integration. Add OneRoster direct integration when you have a specific district that requires it and the deal size justifies the engineering investment.
Do not build your own rostering CSV import process and expect districts to use it. They will not. The district IT administrator handles dozens of vendors and has no interest in manual CSV exports for each one. Automated rostering is a sales requirement, not a convenience feature.
What Fractional CTO Engagement Looks Like in EdTech
The edtech companies that get the most value from a fractional CTO for education startup engagements tend to be in one of two situations: approaching their first significant district or enterprise deal, or preparing for a funding round where the technical scalability question will come up in due diligence.
In both cases, the core value is the same: architectural assessment, risk identification, and prioritized remediation before the deal closes. The district deal or the funding round sets a deadline, and the deadline creates focus.
The pattern I saw in the story at the top of this piece - twelve thousand users arriving in six weeks - is actually a gift. It is a concrete deadline with a concrete scale requirement. The worst situation is "we need to be able to handle more users eventually." The best situation is "we need to handle 12,000 users starting July 1st." The second one is fixable.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr