Nadia Mohamed
Technical SEO
Custom EdTech Software: What to Specify Before You Commission It
Search for custom edtech software and every result is an agency page: industries served, technologies used, a form. None of them tells you what to write down before you talk to any of them. That gap is where edtech builds go wrong, because the expensive mistakes in a learning platform are rarely in the code. They are in what was never specified: the platform cannot be dropped into a university’s learning management system, the checkout fails an accessibility audit the client did not know applied to them, the eleven-language rollout has no plan for how search engines will tell the locales apart, and the course pages that should be the growth engine are invisible to Google because nobody said they had to render.
This article is the specification the agency pages leave out. It is written from the engineering side of two edtech engagements on this site, a multi-year build behind CareerFoundry’s organic growth and a structural audit of a multilingual learning platform across eleven locales, and it covers the four things that belong in the brief before a line of code is written: interoperability, accessibility, multilingual architecture and discoverability. The last section turns them into a checklist with acceptance tests.
Key takeaways
- Custom edtech software is justified by a learning experience or integration an off-the-shelf LMS cannot deliver, not by a preference for owning the code; write down which one before commissioning anything.
- If institutions will ever buy it, specify LTI 1.3 and the LTI Advantage services up front; retrofitting single sign-on and grade passback into a platform that was not designed for them is a rebuild.
- Accessibility is a legal requirement for consumer-facing learning products sold in the EU: the European Accessibility Act has applied since 28 June 2025, and WCAG 2.2 level AA is the standard to name in the contract.
- Multilingual is an architecture decision, not a translation task; the eleven-locale audit found clean rendering and hreflang but no structured data on any page in any language.
- Course pages are the growth surface. Specify server-rendered course pages with Course schema and measurable Core Web Vitals, and make rich-result eligibility an acceptance test rather than a hope.
What custom edtech software is, and when it is the right call
Most learning products do not need custom software. A learning management system, a course marketplace or a headless CMS with a video provider covers the majority of “we need a platform” conversations, and the honest first question for anyone commissioning custom edtech software is which of those was tried and why it failed.
Custom is justified in three situations. The learning experience itself is the product: adaptive sequencing, a proprietary assessment model, a live-cohort format that off-the-shelf tools flatten. The integrations are the product: the platform has to sit inside institutional systems, sync with a student information system, or pass grades back to a gradebook it does not own. Or the scale and languages are the product: a platform serving learners across many markets where the content model, the URL architecture and the editorial workflow have to be designed together rather than bolted onto a template.
If none of those apply, the money is better spent on content and on the technical SEO of the site around the platform. If one of them does apply, everything below belongs in the specification.
Interoperability: specify LTI 1.3 before anyone writes a login page
The single most common regret in edtech builds is discovering, after launch, that a university or corporate buyer wants the product inside their existing learning management system. The standard that makes that possible is Learning Tools Interoperability. 1EdTech’s LTI standard page describes LTI 1.3 as the specification that lets a learning platform integrate remote tools and content in a standard way, with a security model built on OAuth2 and JSON Web Tokens, and LTI Advantage adds the services buyers actually ask for: Assignment and Grade Services to create a gradebook column and post grades, Names and Role Provisioning Services for roster and role data, and Deep Linking so an instructor can place your content inside their course.
The reason to specify this before the login page is written is that LTI changes who the identity provider is. In a standalone product, your platform owns the user. Inside an LMS, the platform launches your tool with a signed token that says who the user is and what role they hold, and your software has to accept that identity, map it to its own records and hand grades back the same way. A platform designed around its own accounts first and LTI second ends up with two identity systems and a reconciliation problem that never quite closes.
Write it into the brief as a requirement with a test: “a tool launch from an LTI 1.3 platform creates or matches the learner, and a completed assessment posts a score to the platform gradebook via Assignment and Grade Services”. If you do not yet have an institutional buyer, specify it anyway; it is far cheaper as a day-one architecture decision than as a year-two rebuild.
Accessibility: the European Accessibility Act made this a contract clause
Accessibility used to arrive in edtech briefs as a value. Since June 2025 it arrives as a legal obligation for a large share of learning products. The EUR-Lex summary of the European Accessibility Act states that Directive 2019/882 applies from 28 June 2025 to, among other services, e-commerce and e-books, requires service providers to make their websites and mobile services accessible and to publish information on how the service meets the requirements, and exempts microenterprises providing services. A learning platform that sells courses to consumers in the EU is an e-commerce service; a platform that delivers reading material is close to the e-book provisions. Unless the company is small enough for the microenterprise exemption, the obligation applies.
The standard to name is WCAG. The W3C’s WCAG 2 overview sets out WCAG 2.2 as 13 guidelines under four principles, perceivable, operable, understandable and robust, with testable success criteria at levels A, AA and AAA; it was published on 5 October 2023 with an update in December 2024 and is now also ISO/IEC 40500:2025. The same page notes that for the European Accessibility Act most organisations use WCAG together with the European standard EN 301 549, which currently references WCAG 2.1 and is expected to move to 2.2. The practical specification is therefore WCAG 2.2 level AA: it satisfies the current EN 301 549 reference by construction, since content conforming to 2.2 also conforms to 2.1, and it does not need re-doing when the European standard catches up.
Edtech has accessibility problems that generic web guidance underweights. Video with captions and transcripts. Assessments with time limits, which WCAG treats specifically. Interactive exercises that must work by keyboard. Mathematical and code content that screen readers need marked up rather than rendered as images. Put each of those in the brief as its own line, with an audit against the success criteria as the acceptance test, and ask the vendor how they will produce the accessibility statement the directive requires providers to publish.
Multilingual: an architecture, not a translation budget
The eleven-locale audit on this site is the clearest example of what happens when multilingual is treated as a content task. The platform’s rendering was clean on every template, hreflang reciprocity was correct within declared pairs and internal linking was sound, and yet there was no structured data on any page, in any locale, leaving the entire estate ineligible for rich results. The engineering was good. The specification had simply never said that a course page in Spanish needed to be as machine-readable as the English one.
Three decisions have to be made before the first locale ships, and they are covered in depth in hreflang implementation for multilingual SaaS: the URL structure for locales, how translated pages declare their alternates so search engines do not treat them as duplicates, and what happens to a page that exists in one language and not another. A fourth is specific to learning platforms: the content model has to carry locale on the course, the lesson and the assessment separately, because they are translated on different schedules by different people and a lesson that falls back to English inside a Spanish course is both a learner problem and an indexing problem.
Headless stacks make this both easier and riskier. The content model is explicit, which helps. The rendering is a separate decision, which is where the technical SEO of headless architecture comes in: a course catalogue that only exists after client-side JavaScript runs is a catalogue search engines index late, partially or not at all.
Discoverability: the course pages are the growth engine, so specify them as one
The CareerFoundry engagement is the counter-example. Over several years the marketing team owned content and editorial while the engineering side shipped the structured data across course, article, organisation and breadcrumb templates, ran the migrations and owned the Core Web Vitals, and organic traffic grew by 340% over that period. The point is not the number; it is that the growth ran on course pages that were built to be found.
That translates into four specification lines that agency proposals rarely include unprompted. Course and programme pages are server-rendered and reachable by crawlers without authentication, with the enrolment gate applied to the lesson content rather than the catalogue. Every course page carries Course structured data, built the way rich snippets with JSON-LD describes, with the organisation and breadcrumb graph around it. The pages meet the Core Web Vitals thresholds on real devices, measured in the field rather than in a lab run on the developer’s laptop. And the URL structure survives the next migration, because there will be one, and the redirect map is an engineering deliverable rather than an afterthought.
A fifth line is newer. AI assistants and Google’s AI features cite pages they can read and trust, and a course catalogue that is clean, structured and fast is the precondition for being cited when someone asks an assistant which course to take. The structured data for AI search piece covers what the answer engines can use; the specification just has to make sure the pages give them something to use.
The specification checklist
Each row is a line for the brief, with the acceptance test that tells you whether it was delivered. Vendors who push back on the tests are telling you something about how they will build.
| Area | Specify | Acceptance test |
|---|---|---|
| Interoperability | LTI 1.3 launch with LTI Advantage grade passback, roster and deep linking | Launch from a test LMS creates the learner; a completed assessment posts a grade to the gradebook |
| Accessibility | WCAG 2.2 level AA across web and mobile; captions, transcripts, keyboard-operable exercises, accessible maths and code | Independent audit against the success criteria; accessibility statement published |
| Multilingual | Locale on course, lesson and assessment separately; hreflang and canonical rules; fallback behaviour defined | Every locale page declares its alternates; no untranslated lesson renders inside a translated course without a declared fallback |
| Rendering | Server-rendered catalogue and course pages, crawlable without login | Fetch as a crawler returns full course content and structured data |
| Structured data | Course, Organization and BreadcrumbList JSON-LD on the relevant templates, in every locale | Rich Results Test passes on a sample from each template and locale |
| Performance | Core Web Vitals within thresholds on field data | Search Console CWV report green for the course templates after launch |
| Migrations | Redirect map as a deliverable for any URL change | Zero 404s on former URLs after cutover; internal links updated |
| Observability | Logs and dashboards for crawl activity, error rates and learner-facing failures | Named owner can answer “what broke and when” within a day of launch |
Who should build it
The specification above is unusual in one way: half of it is engineering and half of it is what an SEO or accessibility consultant would normally review after the fact. Edtech builds go better when the same people hold both, because the decisions are the same decisions. Where the locale lives in the content model is a data-modelling question and an indexing question at once. Whether course pages render on the server is an architecture question and a discoverability question at once.
That is the shape of the full-stack development work on this site: implementation that does not need a separate developer to translate the audit into shipped code, in stacks including React frontends, headless CMS platforms and the WordPress infrastructure that a lot of edtech still runs on. If you already have a build team, use the checklist as the brief and the acceptance tests as the review. If you do not, the checklist is the first thing to send.
Frequently asked questions
When does custom edtech software make sense instead of an LMS?
When the learning experience, the integrations or the multilingual scale is the product and an off-the-shelf learning management system flattens it. If a standard LMS or a course marketplace would deliver the same learner outcome, custom software adds cost and maintenance without adding value, and the budget is better spent on content and on the site around the platform.
What standards should custom edtech software support?
For institutional buyers, LTI 1.3 with the LTI Advantage services (grade passback, roster provisioning and deep linking). For accessibility, WCAG 2.2 level AA, which also satisfies the current EN 301 549 reference used under the European Accessibility Act. For discoverability, schema.org Course, Organization and BreadcrumbList structured data on server-rendered pages, and hreflang for every locale.
Does the European Accessibility Act apply to a learning platform?
If the platform sells to consumers in the EU, in most cases yes. The directive has applied since 28 June 2025 to e-commerce services and e-books among others, requires providers to make their websites and mobile services accessible and to publish how they meet the requirements, and exempts microenterprises providing services. Check the microenterprise definition against your company; if you are above it, plan the audit and the accessibility statement into the build.
How much does custom edtech software cost?
The cost is driven by the four areas in this article more than by screen count: LTI integration, an accessibility audit and remediation, the number of locales and how they are modelled, and the rendering and structured-data work on the course pages. A brief that specifies those up front gets comparable quotes; a brief that leaves them out gets a low quote followed by change requests. Ask every vendor to price the acceptance tests in the checklist, not just the features.
How do I make sure the course pages rank?
Specify it as an engineering deliverable: server-rendered course and catalogue pages reachable without login, Course structured data in every locale, Core Web Vitals within thresholds on field data, and a redirect map for any URL change. Then measure it with Search Console after launch. The CareerFoundry engagement grew organic traffic by 340% over several years on exactly that foundation, with the marketing team producing the content on top of it.