Edtech software development for schools, universities, and education companies

An education software development company for institutions and edtech products

Two kinds of buyer arrive at an education software development company, and they need different things from the first conversation. A K-12 school or a university usually has systems already: a student information system that holds the records, a learning platform the teaching staff use, a finance system that collects fees, and a spreadsheet or two doing the work none of them does. What it needs is a system that fits that estate and survives the start of term. An edtech company has no estate yet. It needs a product that many schools can adopt, which means sign-in, roles and data export designed for customers it has not met.

We build for both, with the same team and the same process. The scoping is the same, the weekly demo is the same, and the fixed price after scoping is the same. What changes is the design brief: fit for an institution, portability for a product. That difference is the first thing settled in scoping, because it shapes everything from the data model to the way a teacher signs in.

What breaks in education software, and why

Education software fails at the seams between systems, not on the screens. Four failures explain most of the pain, and each is a design decision that was skipped.

• Student data in three places — the student information system, the learning platform and a spreadsheet each hold a version of the truth. Skipped decision: which system owns each field.
• A pilot that stalls at rollout — one department loves it, the institution cannot adopt it, because sign-in is separate and nothing syncs. Skipped decision: single sign-on and integration designed before the pilot.
• The first week of term — enrollment, timetables and first log-ins land in the same week, and a system sized for the average fails at the peak. Skipped decision: capacity planned for that week.
• Permissions nobody can explain — a teacher still sees a class they no longer teach, and nobody can say who changed a grade. Skipped decision: role-based access and an audit log from the first release.

A school rarely names these problems; it names a feature. Scoping traces the feature back to the seam it depends on, so the build fixes the cause.

The four education systems we build

We build four kinds of education system, and an institution usually needs at least two of them talking to each other.

Other education software solutions, such as a library system, a tutoring marketplace or a staff-training tool, are scoped the same way. The team builds all kinds of software systems, and each one starts from the roles it serves, the data it has to share, and the week of term it has to survive.

Education data protection, built into the system

Student data protection is a set of decisions in the design, not a document attached at the end. The first decision is who can see what: role-based access control defines what a teacher, a student, a parent and an administrator each see, so a teacher sees this year's classes and a parent sees their own child. The second is what is recorded: audit logging keeps a record of who viewed and who changed a student record, so "who altered that grade" has an answer. The third is how long data is kept: retention is set as a schedule in scoping, per kind of record, and the system enforces it.

If your institution works under a data-protection regime, its requirements go into scoping, and the design is checked against them before build. After handover the school can verify all of this itself, because our contracts assign the school the code and the intellectual property, and the infrastructure runs in its own accounts:

• Access rules — readable in the code and the admin screens, not only in a policy.
• The audit log — queryable by the school's own staff.
• Retention — visible as a schedule, with the deletions it triggers.
• Data export — every record retrievable in a standard format, without asking us.

The longer version, with questions to ask a vendor, is our guide to protecting student data in school software.

Talk through your data model

Fitting the systems a school already runs

In an education build the integration is usually the project. Sign-in comes first. Schools on Microsoft 365 sign in through Entra ID and schools on Google Workspace through their Google accounts, so nobody gets a new password, and disabling a leaver's account in the directory stops their next sign-in. We have delivered both.

Then the data. Rosters, grades and attendance have to move between the student information system, the learning platform and the assessment system, by API where one exists and by scheduled import where it does not, and the systems without an API are the ones that decide the design. Where the school's content or tools have to work inside a learning platform, we build LTI tool integrations, so a tool launches from the LMS with the user already signed in and, where both sides support LTI Advantage, grades pass back; course content is packaged as SCORM or xAPI so it can move to another platform later. Fees and tuition are collected online through a payment gateway and reconciled against the student record.

Each integration is written down in scoping as a contract: which system owns the field, which direction it flows, how often, and what happens when the source is wrong.

Built for the first week of term

School software has one load shape: a spike in the first week of term, then months of quiet. A system sized for the quiet months fails on the day the whole institution needs it. So capacity is planned for the peak week, and before launch the build is load-tested against that week: the number of students, staff and parents the school expects, signing in at once, on the day the timetable is published.

Launches are timed for the gap between terms, when a problem affects nobody's lessons and can be fixed calmly. After launch, DevOps on our team runs the environments and the monitoring, so the first week of term is watched by the team that built it.

How an education build runs

Five steps run from the first scoping workshop to support after a launch between terms. The people who scope the system are the people who build it, so nothing is lost in a handover between a sales team and a delivery team we do not have.

We build education software for institutions and companies across the US and Canada, the UK and Europe, the Middle East, and Australia and New Zealand. We keep a daily working overlap with the UK and Europe, the Middle East, Australia and New Zealand, and the US East Coast. For client meetings, we overlap with all of Canada.

The stack behind our education software

Every technology here is one we build production systems in. For education work the stack maps to five layers.

• Web platforms and portals — React, Next.js, Angular, TypeScript
• Services and integrations — Node.js, NestJS, Java, .NET, PHP and Laravel
• Data — PostgreSQL
• Cloud and identity — AWS, with sign-in through Microsoft Entra ID or Google Workspace
• Student and parent mobile apps — Flutter or React Native, one codebase for iOS and Android, offline included

A learning platform that must serve content to another LMS, or an assessment engine that must scale for exam week, is built from the same list. The choice within that list is made in scoping, based on the school's existing systems and who will maintain it after us.

What education software development costs

There is no published price for education software, because five things move the number more than the feature list does. How many existing systems the build must connect to, and whether each has an API. How many roles it serves, and how different their screens are: a parent view is not a cut-down teacher view. Whether it must survive a term-start peak on its first day. How much existing data has to be migrated and cleaned on the way in. And whether it is a system for one institution or a product for many schools, which changes the data model.

Scoping settles all five, and the quote it ends in is itemized, so a school can see what the parent portal or the payment integration costs on its own and move it to a second phase deliberately. From there the build runs as a fixed-scope build, a dedicated team, or a support retainer once it is live. Tell us what the system has to do and we will reply within one business day.

Get your education build scoped

Custom edtech software, an off-the-shelf LMS, or an extension?

Not every school needs custom edtech software, and we say so in scoping. Buy when the workflow is the standard one and the platform lets you get your data out: Moodle, Canvas or Google Classroom will run a conventional course well, and a plugin or an LTI tool can cover one gap without a build. Extend when one platform is right and one requirement is not; an integration or a small custom tool beside the platform is cheaper than replacing it. Build when the workflow is the institution's own, when the data has to live in one place across several systems, or when the product is the business. If the platform in question is the LMS itself, the tests for each route are worked through in our article on custom LMS development.

That last case is where custom edtech software companies earn their keep. An edtech startup's first product is what an MVP development company is for: the smallest version real teachers can use, priced after scoping. A product sold to many schools is SaaS development, where tenant separation, billing and sign-in for customers you have not met are designed from the first release. A system the whole institution runs on is one of the enterprise systems we build. When a live system needs care rather than change, our software maintenance and support services take it on.

Get a free scope & quote Book a 30-min call

Education systems we have built

We have built each of the four systems above, and the design decision that mattered most was different every time. In a learning management system it was the content model: whether a course is a folder of files or a sequence with prerequisites decides what progress tracking can report. In a student information system it was ownership of the record: one place where enrollment, attendance and grades are true, and every other system reads from it. In an assessment and exam system it was the peak: marking a whole cohort in the same week is a different load from teaching it across a term. In a parent, student and teacher portal it was the role model: three views of one record, each showing what that person should see. You can meet the team behind an education build before you sign anything.