Building an EdTech MVP That Schools Will Actually Buy

A school will buy an edtech MVP that does one classroom job well and clears about 8 checks: a data-privacy agreement, sign-in with Google or Microsoft, rostering from the school's systems, role-based access, deletion on request, accessibility, a named security contact and a paid pilot with agreed success criteria. Build those before extra features. This guide covers each one, with sources.

If you would rather have it built for you, see how RAITHub would build this below.

Why do schools say no to edtech products that teachers love?

Because the teacher who loves your product is rarely the person who signs the order. A teacher can try a free tool; a school or district buying it for whole classes brings in an IT lead, a data protection officer or privacy lead, and often a business manager or procurement office. Each has a checklist, and an MVP that only impresses in the classroom stalls at theirs.

The pattern is predictable. The demo goes well, the teacher asks for it, and then three questions arrive: where does pupil data go, how do students sign in, and how do classes get into the system without someone typing 600 names. A product that answers those in writing, with working features behind the answers, moves forward. One that answers "we're working on it" usually waits until next school year.

This post is the buyer-side companion to our guide to building a learning platform, which covers assessment, AI tutoring cost, LTI and exam-time load.

How does school procurement actually work?

It varies by country, state and school type, so treat this as a general picture. In most systems there are three stages: a teacher or department champions the product, someone with budget authority approves it, and a privacy and security review runs alongside or before the purchase.

• US districts often ask vendors to sign a student data privacy agreement, sometimes a state-wide template. The Student Data Privacy Consortium publishes shared agreements that many districts use. Purchasing thresholds and board approval rules are set locally.
• UK schools and academy trusts are told by the Department for Education to run a data protection impact assessment (DPIA) early, ideally before procurement decisions are final, and to check every contract clause before signing (DfE: procuring EdTech).
• Timing matters everywhere. Many schools plan purchases around the academic year and budget cycle, so a deal that misses the planning window can slip by months.

The practical lesson: have your privacy pack ready before the first demo, not after the teacher says yes.

General information, not legal advice; confirm how procurement and privacy law apply to you with your adviser.

What data-privacy questions will a school ask?

Expect questions about what you collect and why, who can see it, where it is stored, who your sub-processors are, how long you keep it and how you delete it. The legal basis differs by country; the engineering answers are mostly the same.

United States: FERPA and COPPA

FERPA gives parents rights over their children's education records, including "some control over the disclosure of personally identifiable information from the education records", and those rights pass to the student at 18 or on entering postsecondary education (US Department of Education, Student Privacy Policy Office). Schools commonly share records with vendors under the "school official" exception, which in general requires the vendor to perform a service the school would otherwise use staff for and to be under the school's direct control over use and maintenance of the records (34 CFR 99.31). In product terms: use student data only for the contracted service, never for advertising, and be able to prove it.

COPPA covers online services directed to children under 13. The FTC's guidance includes a dedicated section on COPPA and schools, and notes that "the COPPA Rule was amended on April 22, 2025", so check the current text rather than older summaries (FTC COPPA FAQs). Historically the FTC has allowed a school to consent on parents' behalf only where data is used for the school's educational purpose and no other commercial purpose; confirm how that applies after the amendments.

United Kingdom: DfE guidance and UK GDPR

The DfE tells schools to ask suppliers to explain why each data category is necessary, describe their data flows, state whether they act as processor or controller, list sub-processors, and detail security testing (DfE: procuring EdTech). Schools must know whether data is "held or processed outside of the UK", and for AI tools whether pupil data trains the model. The same page notes that suppliers are often within scope of the ICO's Children's Code even where the school itself is not. The parent guidance, Data protection in schools, was last updated on 9 July 2026.

General information, not legal advice. Which laws apply to your product is a question for a privacy lawyer in each market you sell to.

How do students and teachers sign in: Google Workspace for Education or Microsoft Entra?

Support both, through OpenID Connect (OIDC), and decide which school an account belongs to on the server, never in the browser. Most schools already run one of these identity providers, and asking 30 children to create passwords is a common reason pilots fail in the first lesson.

• Google: the ID token carries an hd (hosted domain) claim for Workspace accounts. Google warns that the hd request parameter is only a UI hint, and that you should "validate that the returned ID token has an hd claim value that matches what you expect" (Google OpenID Connect docs). Google lists Education Fundamentals at no cost for qualifying institutions, which is why so many schools use it.
• Microsoft: Entra ID serves OIDC under https://login.microsoftonline.com/{tenant}/v2.0; the organizations value admits only work or school accounts, and a specific tenant ID admits one school's directory (Microsoft identity platform OIDC). The token's tid claim identifies that tenant.

Here is the core check, in TypeScript with the jose library: verify the token, then map it to a contracted school by Google domain or Entra tenant. Nonce and state checks happen in your OIDC client before this point.

import { createRemoteJWKSet, jwtVerify } from 'jose'

const GOOGLE_KEYS = createRemoteJWKSet(new URL('https://www.googleapis.com/oauth2/v3/certs'))
const ENTRA_KEYS = createRemoteJWKSet(
  new URL('https://login.microsoftonline.com/common/discovery/v2.0/keys'),
)

// Loaded from your database: only schools with a signed agreement
const contractedGoogleDomains = new Set(['district.example.org'])
const contractedEntraTenants = new Set(['11111111-2222-3333-4444-555555555555'])

export async function schoolForIdToken(
  provider: 'google' | 'microsoft',
  idToken: string,
  clientId: string,
) {
  if (provider === 'google') {
    const { payload } = await jwtVerify(idToken, GOOGLE_KEYS, {
      issuer: ['https://accounts.google.com', 'accounts.google.com'],
      audience: clientId,
    })
    const hd = typeof payload.hd === 'string' ? payload.hd : ''
    if (!contractedGoogleDomains.has(hd)) throw new Error('Not a contracted school account')
    return { schoolKey: 'google:' + hd, subject: String(payload.sub) }
  }

  const { payload } = await jwtVerify(idToken, ENTRA_KEYS, { audience: clientId })
  const tid = typeof payload.tid === 'string' ? payload.tid : ''
  const expectedIssuer = 'https://login.microsoftonline.com/' + tid + '/v2.0'
  if (!contractedEntraTenants.has(tid) || payload.iss !== expectedIssuer) {
    throw new Error('Not a contracted school tenant')
  }
  return { schoolKey: 'entra:' + tid, subject: String(payload.oid ?? payload.sub) }
}

The school key it returns should scope every query after sign-in, so one school can never see another's pupils.

How do you get class lists in: Clever, ClassLink or OneRoster?

Through the rostering service the school already uses, not a spreadsheet you ask teachers to upload. Rostering means syncing schools, classes, teachers and students from the school's student information system (SIS) into your product, and keeping it in sync as pupils join and leave.

Option	What it is	What to know before you build
Clever	A district-managed platform that shares rostering data and sign-in with apps	Clever's docs state that "access to live district data requires Clever certification", so budget time for review after you build in their sandbox
ClassLink Roster Server	Rostering certified by 1EdTech against the OneRoster standard, via API or SFTP file drops	ClassLink says districts can roster "with unlimited vendors with no additional fees" and supports SAML, OAuth and LTI "with no fees to vendors"
OneRoster directly	The 1EdTech standard for exchanging roster data, as CSV files or a REST API	A OneRoster CSV import covers schools without Clever or ClassLink and is a sensible first step

A practical MVP order: OneRoster CSV import first, because it works for nearly anyone; then whichever of Clever or ClassLink your first paying district uses. Two engineering rules matter more than the connector. Keep the external IDs from the roster as the join key, never names or emails. And treat a pupil leaving a class as a real event that removes access, not a row you forget to delete.

Doing it yourself: an experienced developer can typically get Google and Microsoft sign-in plus a OneRoster CSV import working in about 2–4 weeks. The main risk is not the login screen; it is tenant isolation. One missing school filter in one query exposes pupils across schools, and that ends the contract.

What is the smallest MVP that passes a school's checklist?

One classroom workflow, done well, plus the eight items below. Everything else, from gamification to analytics dashboards to a native mobile app, can wait until a paying school asks for it. (RAITHub builds web apps and PWAs, which install on Chromebooks and tablets from the browser; native mobile apps are outside its services.)

Checklist item	What the school asks	Smallest version that passes
Privacy agreement and policy	What do you collect, why, and will you sign our agreement?	A one-page data inventory, a plain-English privacy notice and willingness to sign the school's DPA or state agreement
School sign-in	Can pupils use their school accounts?	Google and Microsoft OIDC, with server-side domain or tenant checks
Rostering	How do our classes get in?	OneRoster CSV import, then Clever or ClassLink for the first district that needs it
Roles and isolation	Who can see a pupil's work?	Pupil, teacher and school admin roles; every query scoped to one school
Retention and deletion	What happens to data when we leave?	A documented retention period and a tested delete-and-export per school
Data location and sub-processors	Where is it stored, and who else touches it?	A named hosting region and a sub-processor list, including any AI provider and its data terms
Accessibility	Can every pupil use it?	Keyboard operation, contrast and screen-reader checks against WCAG 2.2 AA as a working practice
Security contact and incident plan	Who do we call, and how fast will you tell us about a breach?	A named contact, a written breach-notification process and audit logs of admin actions

None of these is a certification. Schools may still ask whether you hold one; answer honestly, and show the working controls instead.

How do you run a paid pilot with a school?

Charge for it, keep it short, and agree in writing what success means before it starts. A paid pilot, even a modest one, proves there is a budget line and a person who can approve spending, which a free trial never does.

1. Fix the scope: named classes, one term or semester, one workflow.
2. Agree success criteria up front: for example weekly active use by the pilot classes, teacher time saved on a named task, or completion of a unit. Pick what the school's approver cares about.
3. Write the conversion terms in: what the full-year price and scope will be if the criteria are met, so the decision is a yes or no rather than a fresh negotiation.
4. Treat pilot data as production data: the same privacy agreement, the same deletion at the end if the school does not continue.
5. Report in the school's language: a two-page summary for the head teacher or district lead, not a dashboard login.

Should you buy, build or hire for a school-ready MVP?

Route	Example	Choose this when	Watch out for
Off-the-shelf platform the school already has	Teaching through tools in Google Workspace for Education, which schools already approved	You are testing content or teaching method with a few teachers and have no product to sell yet	You own no product, data model or sign-in, so there is nothing to procure
No-code or template	Bubble, from $59 a month on the Starter plan billed annually	You need a clickable, working demo for teacher feedback before a privacy review	School SSO checks, rostering sync, per-school isolation and deletion are hard to prove to a reviewer
Custom build	A web app or PWA with OIDC, OneRoster and per-school scoping from day one	A school or district is ready to pilot and will ask the checklist questions in writing	Over-building: ship the eight checklist items and one workflow, not a full LMS

For scoping the custom route, our MVP guide for non-technical founders and how to write an MVP spec for an agency help, and the MVP cost estimator gives a quick range.

Why RAITHub for this

• Edtech built, not just discussed. RAITHub built PadhAI, an AI tutoring platform with 11 services, a 70/20/10 LLM router, a Socratic tutor with math verification and RAG, and 9 payment gateways. School SSO and rostering are not part of PadhAI's published description, so on your project they are new work, estimated and tested as such.
• Isolation and roles we have shipped. PropDesk has 4 roles and 1,024 automated tests; Sundor Skin runs on 146 PostgreSQL tables with row-level security and 88 permission codes. Per-school scoping is the same discipline.
• Multi-tenant MVPs on a fixed timeline. BlockEstate, a multi-tenant listing and inquiry platform, shipped its MVP in 6 weeks.
• Tests reviewers can rely on. TheSkinProof, the founder's own marketplace venture, carries 750+ automated tests across 217 API endpoints, gated in CI.

We sign NDAs and DPAs and work inside your controls; production and pupil data stay in your own cloud account, and development uses synthetic data. RAITHub is not SOC 2 or ISO 27001 certified and gives no legal advice.

When you don't need us

• You are still validating whether teachers want the idea. Use a no-code prototype or the school's existing tools first.
• You need a vendor with shipped Clever, ClassLink or LTI integrations to show a district today. RAITHub's published work does not include one.
• You need curriculum, instructional design or a native mobile app. RAITHub builds web software only.
• Your buyer requires a certified vendor. RAITHub holds no certifications.

More on what RAITHub builds for learning products is on the EdTech page.

How RAITHub would build this

• Scope: one classroom workflow end to end, with pupil, teacher and school admin roles.
• School sign-in: Google Workspace for Education and Microsoft Entra via OIDC, with server-side domain and tenant checks.
• Rostering: OneRoster CSV import, plus the Clever or ClassLink connector your first district uses.
• Privacy plumbing: per-school data scoping, retention settings, tested delete-and-export, admin audit logs and a sub-processor list.
• Pilot pack: the data inventory and answers your privacy reviewer will ask for, drafted for your lawyer to check.

Timeline: 4–6 weeks at fixed scope for the MVP, through the MVP development service. A connector that needs certification adds the vendor's review time on top.

What you receive: automated tests and CI, handover docs and runbooks, and full IP under NDA.

Next step: book the free 15-minute technical audit, then get a written fixed quote. Bring your target schools' country, their sign-in provider and any privacy questionnaire they have sent you.

Frequently asked questions

What do schools look for before buying edtech software?

A clear classroom benefit plus answers on privacy, sign-in, rostering, roles, deletion, data location, accessibility and security contact. Having those in writing before the first demo shortens the review considerably.

Do I need FERPA or COPPA compliance to sell to US schools?

FERPA governs how schools share education records, and vendors usually receive them under the school official exception with limits on use. COPPA applies to services directed to children under 13 and was amended in 2025. This is general information; confirm with a privacy lawyer.

Should my edtech MVP support Clever or ClassLink first?

Start with a OneRoster CSV import, which works almost anywhere, then build the connector your first paying district uses. Clever requires certification before live district data; ClassLink says it charges vendors no rostering fees.

How do I add Google and Microsoft school sign-in?

Use OpenID Connect with both providers, verify the ID token on the server, and map the Google hd claim or the Microsoft tid claim to a contracted school. Never trust a domain hint sent from the browser.

Should I charge for a school pilot?

Yes, where you can. A paid pilot proves a budget holder exists. Keep it to named classes and one term, agree success criteria and conversion terms in writing, and delete the data if the school does not continue.

What do UK schools ask edtech suppliers about data protection?

DfE guidance tells schools to run a DPIA, check contract clauses, and ask suppliers about data necessity, data flows, processor or controller role, sub-processors, security testing, storage outside the UK and, for AI tools, whether pupil data trains the model.

How long does it take to build a school-ready edtech MVP?

RAITHub scopes one workflow plus school sign-in, rostering and privacy plumbing at 4–6 weeks fixed scope. Rostering certification and a school's own review add calendar time outside the build.