The second list: what school districts ask after the demo

A district evaluation looks like it has one decision in it. It has two.

The first is whether teachers want your product. That's won in a demo, a pilot, a conference hallway, one teacher telling another. It's the decision most product teams are built to win.

The second is whether the district can actually deploy it. That one gets made by four or five people who weren't at the demo: an integration lead, an IT director, a data privacy officer, an accessibility coordinator, a business manager. Each works from a checklist you've never seen.

They rarely say no. They say not this year, which is the same thing with softer edges and no useful feedback attached.

Here's that second checklist, in the order a district hits it.

Gate 1: Can it get the right people in?

Before a single student uses your product, someone has to answer three questions. Who are the students? Which class are they in? Who teaches it?

Those answers live in the district's student information system, and it isn't yours. It changes all day. It's authoritative in a way your database will never be. Your job is to mirror a moving target you can't write to.

Districts will offer you one of a handful of routes:

Route	What it is	Freshness
OneRoster	A REST API or a nightly CSV drop, in a standard format	Nightly, usually
Clever	A sync layer sitting between thousands of districts and their apps	Nightly
ClassLink	Similar, often exposing OneRoster directly	Nightly
LTI 1.3 launch	Roster context arrives with the click	Real time, but narrow

Most districts of any size run at least two of these for different products, and they'll assume you know the difference.

What this gate really tests is whether your data model can hold a school. Not a generic org, user and group. The actual thing: a district containing schools, a school year containing terms containing grading periods, courses with sections, sections with two teachers and a push-in specialist, a student who transfers in March and needs their work to follow them.

If your schema can't express that, no integration will save you. You'll spend the pilot writing translation layers that quietly lose data.

Read next: the data model of a school and OneRoster, honestly.

Gate 2: Can everyone sign in on the first morning?

Rostering tells you who exists. Authentication decides how they get in, and in a school those are genuinely different problems, because the same child arrives through different doors on different days.

A ninth grader might reach you through a Clever portal on Monday, an LTI launch from inside Canvas on Tuesday, and a Google sign-in on a Chromebook on Wednesday. That's one student and three identifiers. If your account model doesn't resolve them into one person, you'll find out when a teacher reports that half the class lost their work.

Two specifics that catch teams out:

• A lot of elementary students have no email address. That's district policy, not an oversight. If email is your primary key or your password reset path, you've designed K-5 out of your product.
• An LTI launch can arrive with no name and no email, because the district set the privacy level that way. Your tool still has to run, and still has to attach the work to the right person on the way back.

Read next: SSO for schools.

Gate 3: The privacy review

This is the gate that kills deals, and the one product teams are least ready for, because it isn't a feature request. It's a review of how your system is built, run by someone whose job is to say no to anything that can't be explained.

The federal floor is FERPA and COPPA.

FERPA's school official exception is how a vendor is allowed to touch education records at all. It commits you to operating under the district's direct control, for one stated purpose, with no redisclosure, and destruction when the contract ends. Those are architectural constraints, not contract language.

COPPA governs under-13s. Its 2025 Rule amendments, in force since April 2026, added a written security programme, a publicly posted retention schedule, and an end to keeping children's data indefinitely.

On top of that sit more than a hundred state statutes. Only a few change engineering, and you can spot them by asking whether the law contains:

1. A clock. New York gives you seven calendar days to notify a district of a breach. Illinois gives thirty.
2. A named framework. New York's Education Law 2-d wants a plan aligned to the NIST Cybersecurity Framework.
3. A right someone can exercise. Which means your product has to produce one student's record and correct it, on request, with an audit trail.

One thing worth knowing early: districts increasingly work from the National Data Privacy Agreement rather than their own paper. Sign it once with Exhibit E, the general offer of privacy terms, and other districts in that state alliance can adopt it without renegotiating. Teams who don't know this sign fifty agreements instead of one.

Read next: FERPA for engineers and passing a district security review.

Gate 4: Accessibility, and it has a date on it

Accessibility in a district was always a legal obligation. What changed is the temperature.

The ADA Title II web rule makes WCAG 2.1 Level AA a legal requirement for public entities, with compliance dates of April 2026 for larger ones and April 2027 for smaller entities and special district governments. That's where a lot of school districts sit.

So districts now ask a question they used to skip, and they want evidence: a VPAT, completed, which makes it an Accessibility Conformance Report.

Here's the counterintuitive part. A report that says Supports on every line reads as a vendor who didn't test. Reviewers have never seen a complex interactive product that fully supports every criterion. An honest report with several Partially Supports, a named defect and a remediation date is more persuasive, because it's the only kind that ever turned out to be true.

If you build interactive content, this is the expensive gate. A slider that changes a graph, a drag-and-drop construction, a simulation with live readouts: each needs a keyboard path, an announced state, and a text alternative that carries the same information rather than the word "chart".

Read next: accessibility with a deadline.

Gate 5: Money, paperwork and the calendar

The last gate is the one engineers assume is somebody else's problem. It's where more deals stall than any technical failure.

Districts spend from specific funds with specific rules. Title IV-A can pay for your product, but no more than 15% of the technology share may go to devices and infrastructure. E-Rate, which people reach for constantly, funds connectivity and not courseware. The federal relief money that floated a lot of EdTech purchasing had to be obligated by September 2024, so anything sold against that line is now being re-justified against a general fund that never grew.

The calendar matters as much as the fund:

• Most districts close a fiscal year on 30 June. A quote issued in May and a purchase order cut in July are two different budget years, and nobody can bridge that for you.
• Board approval has dates. Professional learning has dates.
• Spring state testing is a window where nothing may change at all.

And one thing that saves entire quarters: a district can often buy through a cooperative purchasing vehicle like Sourcewell, BuyBoard, TIPS or NASPO ValuePoint without running its own procurement. One award can serve hundreds of districts. Teams who don't know this run the same bid over and over and call it a long sales cycle.

Read next: the anatomy of a US school district.

What to build first

If you're early and have to sequence this, order by cost of reversal rather than by urgency.

1. The data model. Cheap now, ruinous later. Everything else is downstream of whether your schema can hold a school year.
2. Identity resolution. Decide today that one human has many identifiers and one internal id, and that the id survives a SIS migration.
3. Data minimisation and retention. Deciding what you won't collect, and writing the deletion job that actually runs, is easier before there's data to migrate.
4. Accessibility of your core interaction. The one component your product is built around. Retrofitting a keyboard path into a mature canvas widget costs several times what building it in did.
5. The review pack. Assemble it while you build. It's a filing job during construction and an archaeology project afterwards.

None of this makes a product good. Teachers still have to want it. But the second list decides whether the teachers who want it get to keep it, and unlike the first list, almost all of it can be answered before anyone asks.