A teacher can love your product and a district can still say no. Before a purchase goes through, most US districts run edtech tools through privacy, technical and accessibility reviews. Founders who know those checks in advance close faster, because they build the answers into the product instead of scrambling for them mid-deal.
Student data privacy comes first
If your product handles student information, expect this to be the first and longest review. Districts need to know what data you collect, why, where it is stored, who can access it and how it is deleted.
- FERPA. The federal law protecting student education records. Districts will expect you to act under their direction and use student data only to provide the service.
- COPPA. If children under 13 use your product, federal rules on collecting their personal information apply.
- State laws. Many states have their own student privacy laws, such as California's SOPIPA and New York's Education Law 2-d, often with stricter requirements.
- Data privacy agreements. Many districts ask vendors to sign a standard agreement, often based on templates from the Student Data Privacy Consortium. Read one early, because it tells you exactly what your product must support.
In practice this means collecting only the data you need, never selling it or using it for advertising, encrypting it, keeping clear access logs and being able to delete a district's data completely when a contract ends.
Sign-in and rostering
Teachers will not type in class lists, and students will not remember another password. Districts expect single sign-on through the systems they already use, most commonly Google, Microsoft, Clever and ClassLink. They also expect classes and students to be created automatically from their student information system, usually through Clever, ClassLink or the OneRoster standard.
If your product cannot do this, the setup burden falls on teachers and IT staff, which is one of the most common reasons pilots never grow into contracts. We covered this in more detail in why edtech pilots stall.
Learning platform integration
If your tool is used for assignments or grades, districts will ask whether it works inside their learning management system, such as Canvas, Schoology or Google Classroom. The LTI standard is the usual way to launch a tool from inside an LMS and pass grades back. Building this early makes your product feel like part of the classroom rather than another tab to manage.
Accessibility
Public schools must serve every student, including those with disabilities, and accessibility requirements for public institutions have been tightening. Expect to be asked whether your product meets WCAG 2.1 AA and to provide an accessibility conformance report, often called a VPAT.
Accessibility is much cheaper to build in than to add later. Keyboard navigation, screen reader support, sufficient color contrast and captions for video should be part of your first design system, not a fix before a big deal.
Security questions
District IT teams often send a security questionnaire. Common questions cover where data is hosted, how it is encrypted in transit and at rest, how access is controlled internally, how often you back up data, how you handle a breach and who your subprocessors are. You do not need an enterprise security program to answer these well, but you do need real answers written down before the questionnaire arrives.
Evidence that it works
Districts increasingly ask for evidence of impact, and federal guidance under ESSA describes tiers of evidence for educational interventions. Early-stage products rarely have formal studies, but you can still show a clear logic model, usage data from pilots and outcome measures agreed with the school before the pilot started. That is why reporting belongs in your product early, not after the first renewal conversation.
What to have ready before your first district conversation
- A plain language privacy policy written for schools, plus a list of the data you collect and why.
- Single sign-on with at least Google and one rostering provider.
- A clear process for deleting a district's data on request.
- A short security summary that answers the common questions.
- An accessibility statement and a plan to reach WCAG 2.1 AA if you are not there yet.
- A pilot report template that shows usage and agreed outcomes.
We build edtech products with these requirements in mind from the first sprint. If you are preparing for district sales and want a practical view of what your product still needs, see how we work with edtech founders or get in touch.