SaaS Development for Edtech: Building for Schools and Students

September 2nd. That's the day most edtech products break. Not because the code is bad. Because 80% of annual user onboarding happens in a 3-week window when schools start, and products built for steady-state usage collapse under the load.

We've built education software that serves schools, students, and administrators. The technical challenges aren't where you'd expect. Multi-tenant architecture and accessibility compliance are table stakes. The real challenges are seasonal usage spikes, procurement cycles that take 6 months, and the fact that your users range from 8-year-olds to 65-year-old administrators with wildly different technical literacy.

Edtech is one of the few verticals where the buyer (school administrator), the user (teacher/student), and the payer (school district/parent) are three completely different people with three completely different priorities. That shapes every product decision.

Key Takeaways > - Multi-tenant architecture with school-level data isolation is non-negotiable for selling to districts. > - WCAG 2.2 AA accessibility compliance adds 15-20% to development time but opens the public school market. > - Build for September. Your infrastructure needs to handle 10x normal load for 3 weeks every year.

Multi-Tenancy: One Product, Thousands of Schools

Every edtech SaaS product that sells to more than one school needs multi-tenant architecture. Each school (or district) needs isolated data, customizable settings, and the guarantee that one school's data is never visible to another.

The three-tier hierarchy: - District level: Administrative oversight, cross-school reporting, billing, and user management - School level: School-specific configuration, teacher management, class rosters - Classroom level: Individual class data, student records, assignments, grades

This hierarchy affects your database schema, your permission system, and your API design. A teacher in School A should never see students from School B, even if both schools are in the same district. An administrator should see aggregate data across schools without seeing individual student records (FERPA compliance).

Our architecture approach:

Schema-per-tenant isolation at the district level. Each district gets its own PostgreSQL schema with identical table structures. Within a schema, school and classroom separation is handled through row-level security policies.

This gives you strong data isolation (a bug in one district can't leak data to another) while keeping infrastructure costs manageable. Separate databases per district is overkill for most edtech products and makes cross-district analytics nearly impossible.

The migration challenge nobody warns you about:

When you add a new feature, you need to run database migrations across every tenant schema. With 200 districts, that's 200 migrations. If migration #147 fails, you need rollback procedures for 146 successful migrations and a fix for the remaining 54.

We handle this with idempotent migrations and a migration runner that processes tenants in parallel with circuit-breaker logic. If 3 consecutive migrations fail, the runner stops and alerts the team. This took 2 weeks to build and has saved us from 4 potential outages.

Accessibility: Not Optional in Education

WCAG 2.2 AA compliance isn't a nice-to-have in edtech. It's a legal requirement for products sold to public schools under Section 508 of the Rehabilitation Act and similar EU regulations. Beyond legality, 15% of students have some form of disability. Your product needs to work for all of them.

What WCAG 2.2 AA requires in practice:

- Keyboard navigation. Every interactive element must be reachable and operable with a keyboard alone. No mouse-only interactions. This affects dropdown menus, modals, drag-and-drop features, and custom components. - Screen reader compatibility. Proper semantic HTML, ARIA labels, live regions for dynamic content, and meaningful alt text for every image. We test with VoiceOver (Mac/iOS) and NVDA (Windows). - Color contrast. Minimum 4.5:1 ratio for normal text, 3:1 for large text. Your design system needs to pass these ratios in every theme, including dark mode if you offer it. - Focus management. Visible focus indicators on every interactive element. When a modal opens, focus moves to the modal. When it closes, focus returns to the trigger element. - Text scaling. Content must remain usable at 200% zoom. No text truncation, no overlapping elements, no horizontal scrolling on text-heavy pages. - Motion reduction. Respect the prefers-reduced-motion media query. Animations that convey information need static alternatives.

Engineering time impact: Accessibility adds 15-20% to development time when built in from the start. Retrofitting accessibility into an existing product costs 30-50% more because you're reworking component architecture, not just adding ARIA labels.

Our contrarian take on edtech accessibility: most products treat it as a compliance checkbox and stop at the minimum AA requirements. The products that win in education go further. Large click targets for young students, dyslexia-friendly font options, high-contrast modes, and simplified interfaces for users with cognitive disabilities. These features don't just satisfy compliance - they make the product better for everyone.

Seasonal Usage: Building for September

Edtech traffic patterns look nothing like standard SaaS. Standard SaaS has relatively steady usage with gradual growth. Edtech has massive seasonal spikes.

Typical annual usage pattern: - June-July: Procurement. Administrators evaluate, demo, and purchase. Low product usage but high marketing site traffic. - August: Setup. Teachers configure classes, import rosters, customize settings. Moderate but rapidly growing usage. - September (first 3 weeks): Peak. 80% of annual user onboarding. 5-10x normal daily active users. Every user is new, confused, and hitting support simultaneously. - October-May: Steady state. Gradual daily usage with weekly peaks on Monday/Tuesday. - June (again): Drop-off. Summer begins. Usage drops 70-80%.

Infrastructure implications:

Auto-scaling is mandatory. Your infrastructure needs to handle the September spike without manual intervention. We deploy on AWS with auto-scaling groups that scale based on CPU utilization and request count. The scaling policy is aggressive - scale up at 50% CPU, scale down at 25%. The cost of over-provisioning during September is trivial compared to the cost of downtime during the most critical onboarding window.

Database performance during spikes:

The September spike isn't just more users - it's more write-heavy operations. Roster imports, account creation, initial configuration. Your database needs to handle bulk inserts and concurrent writes that don't exist during steady-state usage. We pre-provision database capacity in August and add read replicas for the reporting queries that administrators run while teachers are onboarding.

Onboarding flow design:

Your onboarding flow is the most critical UX in the product, and 80% of users will experience it in the same 3-week window. It needs to be fast (under 5 minutes from login to first productive action), self-service (your support team can't handle 10,000 simultaneous onboarding questions), and recoverable (users who abandon midway need to pick up where they left off, not start over).

We build onboarding as a persistent state machine. Each step is saved to the database. Users can close the browser, come back 3 days later, and resume at the exact point they stopped. This reduces support tickets by roughly 40% during the September rush.

FERPA and Student Data Privacy

FERPA (Family Educational Rights and Privacy Act) protects student education records. If your product is used in US schools, FERPA compliance is required.

What FERPA means for your code:

- Data minimization. Collect only the student data you need. Don't ask for information that isn't directly relevant to the product's function. - Access controls. Parents must be able to review and request corrections to their child's data. Your product needs a parent-facing interface (or an export function for school administrators to share). - Consent management. Schools (acting in loco parentis) can consent to data collection for educational purposes, but parents can opt out. Your system needs per-student opt-out capabilities. - Data deletion. When a student leaves a school or a school stops using your product, their data must be deletable. Not archived - deleted. This affects your backup strategy. - Directory information exceptions. Some student information (name, grade level) can be shared more broadly. Your permission system needs to distinguish between directory information and protected education records.

Student Data Privacy Agreements (SDPAs):

Many US states require specific data privacy agreements between edtech vendors and school districts. California's Student Privacy Pledge, New York's Education Law 2-d, and similar state-level regulations add requirements beyond FERPA.

The practical impact: budget 2-3 weeks for FERPA-related engineering (access controls, data deletion workflows, consent management, audit trails) and EUR 3k-5k for legal review of your privacy policy and data processing agreements.

The Procurement Problem

Selling to schools is slow. Painfully slow. The procurement cycle runs from January (budget planning) through June (purchase orders). If you miss the June buying window, you wait 12 months.

This doesn't directly affect your engineering, but it affects your product strategy.

What procurement buyers care about: - Integration with existing systems (SIS, LMS, Google Classroom, Clever) - Data portability and export capabilities - Accessibility compliance documentation - FERPA/privacy compliance documentation - Single sign-on through the school's identity provider

Integration costs:

- Clever (roster sync): EUR 3k-5k for integration, required for most US school districts - Google Classroom: EUR 2k-4k for assignments and grade sync - LTI (Learning Tools Interoperability): EUR 3k-5k for LMS integration - SIS (Student Information System) data import: EUR 2k-4k per SIS vendor (there are dozens)

Budget EUR 10k-15k for the integrations that your target market requires. This is non-negotiable development. A product without Clever integration is invisible to US school district procurement.

Tech Stack for Edtech

Our standard edtech stack:

Frontend: Next.js with TypeScript. Server-side rendering for SEO (important for organic discovery by teachers), React for interactive components. Tailwind CSS with a custom component library that enforces accessibility standards.

Backend: Node.js API with PostgreSQL. Schema-per-tenant for data isolation. Redis for session management and caching (critical during September spikes).

Infrastructure: AWS with auto-scaling groups. CloudFront CDN for static assets (teachers in rural schools have slow connections - CDN reduces load times by 40-60%). S3 for file storage (student submissions, resources).

Auth: Clever SSO for student/teacher login (most US schools use Clever as their identity provider), plus Clerk for direct authentication. Supporting both adds 3-4 days of engineering.

Monitoring: DataDog or similar for application performance. Custom alerts for the September spike window: if response times exceed 500ms or error rates exceed 0.5%, the team gets paged immediately.

Cost Breakdown for an Edtech MVP

Total cost for an edtech SaaS MVP: EUR 70k-110k.

- Product scoping and design: EUR 8k-12k - Multi-tenant architecture: EUR 10k-15k - Core features: EUR 20k-30k - Accessibility compliance: EUR 8k-12k - Integrations (Clever, Google Classroom, LTI): EUR 10k-15k - Admin dashboard (school and district level): EUR 6k-10k - FERPA compliance (access controls, data deletion, audit): EUR 5k-8k - Infrastructure and auto-scaling setup: EUR 3k-5k - Documentation and handoff: EUR 3k-5k

This is more expensive than standard SaaS because of the multi-tenancy, accessibility, integration, and compliance requirements. There's no shortcut. Products that skip these requirements can't sell to schools.

Frequently Asked Questions

How much does it cost to build an edtech SaaS platform?

An edtech SaaS MVP costs EUR 70k-110k including multi-tenant architecture, WCAG accessibility, FERPA compliance, and integrations with school systems like Clever and Google Classroom. This is higher than standard SaaS (EUR 60k) because education has specific technical requirements that aren't optional.

Do I need WCAG compliance for an edtech product?

Yes, if you're selling to public schools. Section 508 requires accessibility for products used in federally funded institutions. Most school districts include WCAG 2.2 AA compliance in their procurement requirements. Beyond compliance, 15% of students have disabilities. Building accessible products is the right thing to do and expands your market.

How do I handle the September usage spike?

Auto-scaling infrastructure, pre-provisioned database capacity, and an onboarding flow designed for mass simultaneous use. We configure auto-scaling to begin increasing capacity in late August based on historical patterns. The onboarding flow must be self-service and recoverable (users can stop and resume later) because your support team can't handle thousands of simultaneous questions.

What integrations are required for selling to US schools?

Clever (roster synchronization) is the most critical - most US districts use it as their identity provider. Google Classroom integration is expected for assignment and grade sync. LTI compliance allows integration with any LMS. Budget EUR 10k-15k for these core integrations.