Most EdTech vendor pages describe features. Course builders, quizzes, progress dashboards, an AI tutor. Those are real, and they are also the part of the product that nobody blocks a purchase over.

What blocks purchases is student data, consent and whether the tool fits into systems the institution already runs. A development partner who has not met those constraints will build you something that demos well and stalls in procurement. This article covers what to check.

What schools and training providers are actually buying

The buyer in education is rarely a single person. A teacher wants something that works in a 45 minute lesson. An IT administrator wants single sign-on, a data processing agreement and no new password for 900 students. A finance lead wants a renewal that is easy to justify. A privacy officer wants to know exactly what leaves the building.

A product that satisfies only the teacher gets enthusiastic pilots and no contract. That is why the sections below spend more time on records, consent and integration than on features: those are the parts that decide whether the product can be bought at all.

Corporate training buyers differ in the details and not in the shape. They have an existing LMS, a security review and an identity provider, and they ask the same integration questions.

Student data: FERPA and education records

In the United States, the Family Educational Rights and Privacy Act governs student education records. The Department of Education describes FERPA as a federal law that gives parents the right to access their children's education records, the right to seek to have those records amended, and some control over the disclosure of information from them. Those rights transfer to the student at 18 or on entering a postsecondary institution.

For a development partner the consequences are concrete rather than abstract. If your product stores grades, attendance, assessment results or disciplinary information on behalf of a school, you are handling records the school remains responsible for. The build has to support access, correction and deletion as real features rather than as database work someone performs by hand. Audit logging matters, because "who looked at this record" is a question that gets asked. Data residency and subprocessors matter, because the school has to be able to describe where the records go.

The practical test when evaluating a partner: ask how they would implement a parent's request to amend a record. An answer that involves someone running SQL against production is the wrong answer.

Products used by under-13s: consent before collection

If your product is used by children under 13, the Children's Online Privacy Protection Rule applies and it is stricter than most teams expect. Under 16 CFR 312.5, an operator is required to obtain verifiable parental consent before any collection, use or disclosure of personal information from children, including consent to any material change in practices the parent already agreed to. The rule also requires that the parent be given the option to consent to collection and use of the child's personal information without consenting to disclosure of that information to third parties, unless the disclosure is integral to the service.

Read that as an architecture requirement. "Before any collection" means the consent gate sits in front of account creation and in front of analytics, not after onboarding. The separate opt-in for third-party disclosure means your consent record needs more than one flag, and your analytics and advertising SDKs have to be switchable per user rather than compiled in. Retrofitting that into a product built on a single "accepted terms" boolean is expensive, which is why it belongs in the first design conversation.

Ask a prospective partner how they model consent. If the answer is a timestamp on the user row, they have not built for this before.

Interoperability decides adoption: LTI

A tool that lives outside the institution's systems creates a second login, and a second login is where usage dies.

Learning Tools Interoperability is the standard that solves it. 1EdTech describes LTI as a technical standard, not a product, used to connect learning tools with an institution's learning environment without logging into each tool separately, and it supports passing data about users securely. The specification lets an LMS or platform integrate remote tools and content in a standard way, and the current version, LTI 1.3, improves the authentication security of earlier versions and provides a structure for additional services through the LTI Advantage suite.

In procurement terms, LTI support changes the question from "will staff adopt this?" to "shall we enable it?" Launching from inside the LMS the institution already runs means no new credentials, roster information arriving with the launch, and grades able to travel back.

So ask a partner directly whether they have implemented LTI 1.3, and specifically whether they have done the parts beyond launch: names and roles provisioning, and sending grades back. Launch alone is the easy half.

Accessibility is a procurement requirement, not a polish task

Public institutions in many countries are required to buy accessible software, and the review usually happens before the contract rather than after. Keyboard navigation, screen reader labelling, colour contrast, captions on video and accessible assessment interactions are the common failure points.

The reason to settle this early is cost. Accessibility that is designed in costs a little; accessibility retrofitted into a component library costs a rebuild. Ask what the partner's component library looks like and whether accessibility is tested or assumed.

Build patterns that hold up

Four problems come up in most education products, and they are worth asking about by name.

Assessment integrity. If the product tests people, someone will try to game it. Question banks with randomisation, server-side scoring, and timing enforced on the server rather than in the browser are the baseline.

Low bandwidth and offline. School networks are congested at the start of every lesson, and many learners are on phones. Content that degrades gracefully, resumable uploads and offline reading matter more than animation.

Load that arrives all at once. Education traffic is not evenly distributed. Everyone starts the exam at the same minute and submits in the same five. The architecture has to be designed for that shape rather than for average load.

Content lifecycle. Courses get versioned, retired and re-run next term. If the data model treats a course as a single mutable object, the second year of operation is painful.

MOHA has built in this space. Our published work includes an online learning platform with examinations and an e-library for schools in Laos, where bandwidth and offline access were constraints rather than nice-to-haves, along with a Korean language study platform and other e-learning and language-learning projects. Education is one of our industry practices, and the rest of the work is in our portfolio.

Adding AI features without creating a new privacy problem

Nearly every education roadmap now has an AI item on it: a tutor that explains a wrong answer, a marker for written work, a planning assistant for teachers. The engineering is the easy part. The part that stalls deals is that an AI feature usually sends student work to a third party.

That collides directly with the two rules above. Under COPPA the parent has to be able to consent to collection and use without consenting to disclosure to third parties, so an AI feature that forwards a child's writing to an external model is exactly the disclosure the separate opt-in exists for. Under FERPA, the school remains responsible for the records involved, so it needs to be able to say where the text went and how long it is kept.

Three design decisions follow, and they are worth settling before anything is built.

Decide what leaves your systems. Sending an anonymised excerpt is a different proposition from sending a named student's full submission, and the difference is usually invisible in a demo.

Make the AI feature separately switchable per institution and per user, because some customers will buy the product and decline the feature.

Keep the model's output reviewable. Teachers are accountable for grades, so AI-assisted marking needs to show its reasoning and keep a human decision point rather than writing to the gradebook directly.

A partner who treats an AI feature as an API call has not thought about any of this. We wrote more about the product side of this in AI-powered tutoring.

How to evaluate a partner in one conversation

You can learn most of what you need by asking how they would handle four specific situations rather than by reading a capability deck.

A parent asks to see and correct everything you hold about their child. What happens, and how long does it take?

The product needs to be usable by nine-year-olds in one market and adults in another. How does the consent model differ between them?

A customer runs Moodle and wants your tool inside it with grades flowing back. What do you implement?

Two hundred students start the same exam at 09:00. What breaks first, and what did you do about it?

Partners who have shipped education software answer these with specifics. Partners who have not will talk about scalability in general.

Questions to ask MOHA

Which parts of our published EdTech work are closest to what you are building, and what we learned from them.

How we would model consent and record access for your markets and age groups.

What our approach to LTI and identity integration is for your target customers.

How we structure the team, and who on our side is accountable for the engagement.

Where to go next

The features in an education product are the part everyone can discuss. Records, consent and integration are the part that decides whether a school can sign. A development partner worth hiring treats them as architecture from the first week.

To talk about a platform, contact us with what you are building and who it is for. You can also read our overview of education technology work, the longer piece on EdTech development outsourcing, and how we think about AI-powered tutoring.