Edtech MVP Development: Buyers, Children's Data and Scope

An edtech MVP has to settle who the buyer is before it settles features, because a product for learners, a product for parents and a product for institutions are three different builds. Then come children's data under GDPR Article 8, integration with the learning platform the school already uses, and accessibility, which public institutions in particular will check. With Easify, an edtech MVP typically costs €6,000 to €14,000 for a consumer course or tutoring product and €14,000 to €25,000 for an institutional pilot, over 4 to 12 weeks.

Below: the three kinds of buyer, how to validate with a pilot before you build, children's data, LMS integration, accessibility, the AI Act, selling to the UK and the US, a minimum feature set, what to leave out, a week-by-week build plan, a worked example, what to measure in the pilot, typical scope and price, the running costs after launch, common mistakes, the education businesses we have built for, and when not to hire us. The regulatory points are orientation from the official texts, not legal advice.

At a glance

Learners, parents and institutions are different buyers

• Learners who pay for themselves. Adults learning a language, a professional skill or for an exam. They decide in minutes, pay by card, and leave if the first lesson does not deliver. The MVP is content, progress and payment.
• Parents who pay for children. The parent buys, the child uses, and both need something different from the product. The parent wants progress, safety and a reason to keep paying; the child wants it to be engaging. Two roles, linked accounts, and children's data rules from day one.
• Institutions. A school, college, training provider or employer buys, teachers administer, and learners use. Sales cycles are long, decisions are made by committees, and you will be asked about data protection, accessibility and integration before price. A pilot with one institution is the realistic MVP.
• Tutoring and live classes. If a person teaches, the product is a booking and scheduling problem as much as a learning one; see the booking platform guide.

Pick one. You can add the others, but version one is built around one buyer's decision.

A useful way to choose is to ask who would notice first if the product disappeared, and who would sign the payment. If those are different people, as they are in schools, the MVP has to give each of them something: the teacher saves time or gets a clearer view of the class, and the person who approves the budget gets a reason to renew.

Validate with a pilot before you build

Most edtech ideas can be tested before there is much software. The cheapest evidence, in order:

1. Teacher and learner interviews. Ask what they did last week, not whether they would use your product. Five to ten conversations with the people who would use it usually show whether the problem is real.
2. A manual version. Run the lesson, the feedback or the progress report by hand, with a spreadsheet, a form and email. If nobody comes back to the manual version, software will not fix that.
3. A commitment. For consumers, that is a payment or a pre-order. For an institution, that is a written pilot agreement. Interest in a meeting is not a commitment.
4. Only then, the build. The pilot agreement tells you which features the MVP needs, because the institution's requirements are the scope.

A pilot agreement template

Copy this and fill it in with the pilot institution before you scope the build. It is a working document, not a contract; your lawyer turns it into one.

Children's data under GDPR Article 8

GDPR Article 8 applies where you rely on consent to offer an online service directly to a child.

• Age. Processing is lawful on the child's own consent from 16. Below that, a parent must give or authorise consent. Member States may lower the age, but not below 13, so the threshold depends on the country you launch in.
• Verification. You must make reasonable efforts to verify that a parent has given or authorised consent, taking available technology into account (Article 8(2)). A checkbox saying "I am a parent" is weak; a parent account that invites the child is stronger.
• Not only consent. When a school uses your product, the school is usually the controller and you are its processor under a contract (Article 28). Article 8 is about consent for services offered directly to children; institutional products rest on the school's own basis.
• Data protection impact assessment. Systematic monitoring or profiling of children is the kind of processing that usually calls for one (Article 35). Learning analytics can come close.
• Design. Collect the minimum, avoid public profiles and open chat for children, and keep analytics and advertising tools out of children's areas.

LMS integration

If you sell to schools, colleges or universities, sooner or later you will be asked whether you integrate with their learning management system.

• LTI 1.3 is the current version of 1EdTech's Learning Tools Interoperability standard. It lets an LMS launch your tool with single sign-on, using a security framework built on OAuth2 and JSON Web Tokens (1EdTech).
• LTI Advantage adds services on top: Assignment and Grade Services to post grades back, Names and Role Provisioning Services for class rosters, and Deep Linking so a teacher can pick specific content from your tool.
• For an MVP, an LTI launch alone is often enough. Grade passback and roster sync each add work and testing against every LMS the pilot uses.
• Before LTI, many pilots run on a plain link and a CSV roster. If that is acceptable to the pilot institution, it is the cheapest first version.

Accessibility

Learners include disabled people, and institutions are often required to buy accessible tools.

• Public sector bodies, which can include public schools and universities, are covered by the Web Accessibility Directive. Member States may exclude schools, kindergartens and nurseries, except for content relating to essential online administrative functions (Article 1(5)). In practice, public buyers increasingly write accessibility into procurement.
• Consumer services may fall under the European Accessibility Act, which since 28 June 2025 covers services including e-books and e-commerce services provided to consumers (Article 2). Microenterprises providing services, with fewer than 10 staff and turnover or balance sheet of no more than €2 million, are exempt from its service requirements (Article 4(5)).
• The benchmark is the W3C's WCAG 2.2. Build to it from the start: keyboard navigation, contrast, captions for video, and forms that work with screen readers. Retrofitting accessibility into a finished interface costs more than building it in.

AI in edtech

AI tutoring, feedback and grading are where many edtech founders want to start. The EU AI Act lists as high-risk, in Annex III point 3, AI systems used in educational and vocational training institutions to determine access or admission, to evaluate learning outcomes, to assess the level of education someone will receive, or to monitor and detect prohibited behaviour during tests. Under the 2026 Digital Omnibus on AI, the high-risk obligations for Annex III systems apply from 2 December 2027.

Inferring the emotions of a person in education institutions is prohibited by Article 5(1)(f), except for medical or safety reasons, and has been since 2 February 2025. An AI practice tutor that gives feedback a teacher reviews is a different proposition from one that grades exams. Our AI MVP guide covers model costs and evaluation.

Selling to the UK or the US as well

Many edtech guides are written for the US market and lead with American law. If you launch in the EU, the GDPR comes first, but plan for these if the UK or the US is on the roadmap.

• UK: the Children's code. The ICO's Age appropriate design code is a statutory code of practice with 15 standards for online services likely to be accessed by children. It explains how data protection law applies to them and asks services to put the best interests of the child first. High privacy settings by default and no nudging children to share more are the parts that most often change an MVP's design.
• US: COPPA. The FTC's Children's Online Privacy Protection Rule applies to operators of websites or online services directed to children under 13, and to other operators with actual knowledge that they collect personal information from a child under 13.
• US: FERPA. The Family Educational Rights and Privacy Act gives parents rights over their children's education records, which pass to the student at 18 or on entering postsecondary education. US schools will expect a vendor to handle those records within FERPA, usually through their contract with you.

None of these need building into an EU-only MVP, but the same design choices help with all of them: collect little, default to private, keep children's areas free of advertising and tracking, and keep the school in control of school data.

Minimum feature set checklist

• One buyer, one learner journey, end to end
• Sign-up for the buyer; linked learner accounts if a parent or school pays
• Age check and parental consent flow where children sign up directly
• The core learning unit: lesson, exercise, course or session
• Progress the buyer can see: completion, scores or attendance
• Payment, or an institutional pilot agreement instead of payment
• Teacher or admin role to add learners and see their progress, for institutional products
• CSV roster import, or an LTI 1.3 launch if the pilot requires it
• Accessible interface to WCAG 2.2, including captions for video
• Privacy notice written for the age of the user, and terms

What to leave out of version one

• More than one buyer type. Consumer and institutional versions later share code, not version one.
• Grade passback and roster sync, unless the pilot cannot run without them.
• Content authoring tools. Load the first courses yourself.
• Gamification beyond progress. Badges and leaderboards can wait until you know learners come back.
• AI grading. Use AI for practice and feedback a person can check, if at all.
• Native apps. A responsive web app covers most first pilots.

Week by week: an institutional pilot build

An illustrative plan for the largest scope on this page, an institutional pilot of about 10 weeks after the Scoping Sprint. A consumer course compresses the same steps into 4 to 6 weeks.

A worked example

A fictional product, to show how the scope and price fit together. It is not a client.

The idea. A vocational college wants second-year students to practise workplace English between classes, and teachers want to see who is falling behind without marking more work.

The question the MVP answers. Will students complete short practice units at least twice a week for a term without the teacher chasing them, and does the teacher use the progress view?

In version one:

• Teacher and student roles, classes created by the college admin
• CSV roster import (the college agreed a link and a roster instead of LTI for the pilot)
• 40 short practice units the founder writes, with automatic marking for closed questions
• A weekly progress view for teachers: who has done what, and which units are failing most students
• Email reminders for students who have not practised that week
• Accessible to WCAG 2.2 AA, with captions on every video
• An admin view for the founder to load units and see pilot data

Left out: LTI and grade passback, AI feedback on free writing, badges and leaderboards, a parent view, native apps, content authoring for teachers.

Where it falls. Between the consumer course and the institutional pilot rows in the price table below: roughly €12,000 to €16,000 and 7 to 9 weeks with Easify. Illustrative, not a quote. Adding LTI and AI feedback on writing would push it towards the top of our band.

What to measure in the pilot

Decide these before the pilot starts and write them into the pilot agreement. Vanity numbers, such as sign-ups and page views, say little about whether learning happened.

• Activation: the share of invited learners who complete the first unit.
• Habit: learners active each week, across the whole pilot, not only the first week.
• Teacher use: how often teachers open the progress view, and whether they act on it.
• Teacher time: setup and weekly minutes. If it adds work, it will not survive the pilot.
• Outcome proxy: a before and after quiz, or the institution's own assessment, agreed in advance.
• Renewal signal: whether the person who approves the budget wants to continue, and at what price.

Typical scope and price

Illustrative ranges inside our €5,000 to €25,000 MVP band, not a quote. Use the MVP cost calculator for your own scope.

What moves a scope up or down the range:

Running costs after launch

The build is a one-off; these are not. Budget for them before the pilot, because they continue whether or not the institution renews.

• Hosting and database in an EU region, which grows with learners and stored media.
• Video hosting and streaming, if lessons are video. Usually the largest running cost in a content product.
• Captions and transcripts for new video, to keep the product accessible.
• AI model usage, charged per request, if the product generates feedback or practice.
• Email for invitations and reminders, and payments fees if learners pay by card.
• Content. Someone has to write, check and update the courses. In many edtech products that costs more over a year than the software.
• Support and fixes once teachers rely on it, which is what our retainer after launch on the pricing page covers.

For how founders pay for the build itself, including grants that can cover an MVP, see our guide to MVP grants and funding in Europe and the overview of EU funding for startups.

Common mistakes

• Building for everyone. Learners, parents, teachers and administrators in version one, each served badly.
• Treating interest as a pilot. A friendly meeting with a head teacher is not a commitment. A written pilot agreement is.
• Ignoring the teacher's time. Teachers adopt tools that save them time and drop tools that add work, however good the learning design.
• Starting the school pilot at the wrong time. Institutions plan around terms and exams. A product ready in the middle of exam season may wait months for its first class.
• Leaving accessibility for later. An institution's review can stop the pilot, and retrofitting costs more than building it in.
• Copying US compliance checklists. COPPA and FERPA matter if you sell in the US; in the EU, the GDPR and the school's role as controller come first.
• Measuring sign-ups. The pilot is judged on use and outcomes, so measure those from the first week.

The education businesses we have built for

These are websites for education businesses, not edtech products, and they are here for what they show about education buyers rather than as proof of an edtech build.

• EU College Group is an international education consultancy, described in its case study as a vocational training institute based in Budapest. We redesigned its WordPress site around the student, with a user-friendly application form for international applicants, multilingual support, and a mobile-first build.
• Videsh Academy helps Indian students apply to universities abroad. Its case study describes a decision made by two people, the student who wants it and the parent who pays and worries, which is exactly the parent-and-learner split above. The site lays out services by stage and adds an enquiry form and a route to book a consultation.
• TPO Traders publishes educational content and market analysis for traders. We redesigned the WordPress site and worked on its content and SEO.

Start with the Scoping Sprint

The €900 MVP Scoping Sprint is the step we recommend before any edtech build. In about two weeks you get, in writing: the one question the MVP must answer, the smallest feature set that answers it, what is deliberately left out, the main user flows, the technical and hosting plan, and a fixed price and timeline for the build. For edtech, the flows name the buyer, the learner and whether children are involved, which decides the consent design and what the pilot institution will ask. The €900 is credited in full against the build if you build with us, and the scope is yours to keep whatever you decide.

When not to hire us

• You only need to sell a course. An existing course platform will do it for a monthly fee.
• Your first customer is a ministry or a large school district. Public procurement needs references and certifications we would have to build up first.
• You want an agency with an edtech product in its portfolio. Our education work so far is websites for education businesses.
• The pilot institution has not agreed to a pilot. Get the agreement and its requirements first; they are the scope.