We build edtech products for LMS vendors, course platforms, K-12 and higher-ed tools, and corporate learning companies: learner and teacher apps, LMS and SIS integrations, and the content systems behind them. Most of the work is ordinary web and mobile engineering, but schools and employers add rules about standards, accessibility and student data that decide the architecture from the first sprint.
This page is for founders and product leads who need to know what an edtech build involves before they hire a team. It covers the parts that differ from other software, how we approach each, and where our edtech work so far fits.
Who we build edtech software for
Edtech buyers fall into four groups, and each one sets different requirements.
- LMS vendors and platform teams need extensibility: plugins, standards support and an API other tools can build on.
- Course and cohort platforms sell directly to learners or creators and care most about onboarding, payments and content production speed.
- K-12 and higher-ed tools are bought by districts and universities. Procurement asks about rostering, single sign-on, accessibility and privacy before it asks about features.
- Corporate learning products sell to HR and L&D teams. They need SCORM or xAPI support, reporting for managers and integration with the HR stack.
If you are not sure which group your product belongs to yet, that is a discovery question, and we cover it below.
Learner and teacher apps
An edtech product usually has at least two audiences who want opposite things. Learners want a short path to the next lesson. Teachers and admins want control: assigning work, grading, seeing who is behind. We design each role’s flows separately and share one component library underneath.
We plan for these from the start:
- Roles and permissions. Learner, teacher, teaching assistant, school admin, district admin, parent. Each role sees different data, and in K-12 the parent role has its own consent rules.
- Offline and low-bandwidth use. Learners on school devices or mobile data need lessons that load fast and save progress without a stable connection.
- Progress and state. Where the learner stopped, what they submitted and what is graded must survive device changes.
- Notifications that respect school hours and age rules, not just engagement targets.
For the design side, you can hire edtech designers who work on learner journeys and teacher dashboards inside your team.
LMS integrations: LTI, SCORM, xAPI and rostering
Integration work is easy to underestimate in edtech. Institutions expect your tool to fit into the systems they already run, and the standards are specific.
| Standard | What it does | When you need it |
|---|---|---|
| LTI 1.3 and LTI Advantage (1EdTech) | Launches your tool from an LMS course with single sign-on; Advantage adds roster access, grade passback and deep linking | Your tool runs inside Canvas, Moodle, Blackboard, Brightspace or another LMS |
| OneRoster (1EdTech) | Syncs schools, classes, teachers and students from a student information system | You sell to K-12 districts or need class rosters without manual uploads |
| SCORM | Packages a course so any LMS can launch it and record completion and score | You sell content to corporate L&D or to LMS-based schools |
| xAPI and cmi5 | Records learning activity as statements sent to a learning record store | You need analytics beyond completion, or learning that happens outside the LMS |
| Common Cartridge (1EdTech) | Imports and exports course content between systems | Customers want to move courses in and out of your platform |
How we approach this work:
- List the integrations your buyers ask for, not every standard that exists. A corporate learning product may need only SCORM export and SSO; a K-12 tool may need LTI 1.3 and OneRoster from day one.
- Build one integration layer that turns LTI launches, roster syncs and grade results into your own data model, so the rest of the product does not depend on any single LMS.
- Test against real LMS instances, because each platform implements the same standard with its own quirks.
- Plan for certification. 1EdTech runs conformance certification for its standards, and some buyers ask for it. Your team applies; we build so the tests pass.
Single sign-on goes alongside: Google and Microsoft accounts for schools, SAML or OpenID Connect for universities and companies.
Accessibility: WCAG 2.2 AA and Section 508
In education, accessibility is a buying requirement as well as a legal one. Universities and US public buyers often ask for an accessibility conformance report, usually based on the VPAT template, before signing. Section 508 applies to US federal agencies and is widely used as a reference by state and education buyers. In the EU, public procurement points to EN 301 549.
We design and test to WCAG 2.2 AA from the first prototype. That includes keyboard navigation through quizzes and drag-and-drop tasks, captions and transcripts for video lessons, readable math and charts, and timing options on timed assessments. Interactive learning content is where most products fail, so we test it with screen readers by hand, not only with automated tools. Our web accessibility services page covers audits and fixes for products that are already live.
Student data privacy by design
Student data has more rules than most consumer data, and those rules vary by age, country and buyer. We treat the following as scope topics to settle with your counsel before the build, not as boxes we tick for you:
- FERPA in the US governs education records held by schools; vendors that receive them work under the school’s contract and rules.
- COPPA in the US covers online services that collect personal information from children under 13.
- US state student privacy laws and district data privacy agreements often add their own terms on use and deletion.
- GDPR and UK GDPR apply to learners in Europe and the UK, and the UK Age Appropriate Design Code applies to services likely to be used by children there.
What we build in response: collect the least student data the product needs, keep identifiable data apart from analytics, give admins export and deletion tools, log who accessed which records, and choose hosting regions that match your contracts. We do not give legal advice or certify compliance. Our job is to make your compliance easier to prove.
Content at scale on a headless CMS
Most edtech companies run two kinds of content. Course content, such as lessons, quizzes and assessments, usually lives in the product or an authoring tool. Everything around it, such as the course catalog, landing pages, help center, blog and teacher resources, belongs in a CMS that marketing and curriculum teams can update without a deploy.
A headless CMS fits that second group well. One content model can feed the website, the in-app help panel and the mobile app. Structured fields for subject, grade level, standard and language make it possible to build catalog filters and landing pages from the same entries. Editorial workflows with review states let a curriculum lead approve a page before it goes out. When course content itself needs versioning and reuse across many courses, we model it in the product’s own database instead, so learner progress always points to a fixed version.
Analytics that teachers and buyers can use
Edtech analytics serve three audiences. Product teams want funnels and retention. Teachers want to see who is stuck and on what. Buyers want evidence of outcomes for renewals. We separate these from the start: product analytics on anonymous or pseudonymous events, teacher dashboards from the product’s own data with role checks, and xAPI statements to a learning record store when a customer needs portable learning data. Keeping personal data out of third-party analytics tools is usually the simplest way to stay inside your privacy commitments.
Start with product discovery
Plenty of edtech products lose learners in the first session, long before scale matters. Before committing to a full build, we often recommend a short discovery phase or design sprint: map the learner journey, prototype competing ideas and test them with real learners and teachers. Our product discovery services page explains the format.
For a UK-based seed edtech, a structured design sprint settled a debate the founding team had run for months. Their earlier pilot had shown 70% of learners abandoning within the first session. We prototyped both competing learning flows and ran six moderated sessions with target learners. The winning flow cut task completion time by about 35%, mainly because navigation on the critical path went from five clicks to two. The client shipped to beta eight weeks later with a 40% reduction in learner drop-off compared with the pilot. Read the edtech product design sprint case study.
That sprint is our published edtech proof. The integration and privacy work on this page is how we scope an edtech build; we have not published an LMS integration case study yet.
How we work with edtech teams
We work in three shapes: a fixed-scope discovery or design sprint, a fixed-scope build of a product or integration, or a dedicated team inside your sprints. Many edtech products are SaaS underneath, with schools or companies as tenants, so the platform work on our SaaS development page applies too: multi-tenancy, roles, billing and the move from MVP to scale.
Cost depends on the number of roles, the integrations your buyers require, the accessibility target, mobile apps and analytics depth. We price each build after a short audit and list these drivers as separate lines, so you can cut or defer the ones your first customers do not need.
See the other sectors we work in on our industries page, or tell us who buys your product and which systems it has to fit into. We will reply with the questions a first audit needs to answer.
