
What Meta Connect 2026 Actually Changes for Teams Building AI ProductsRead More

Any competent vendor salesperson can say yes to LTI 1.3, WCAG 2.2, and exam-day scale in a first call. A team that has shipped into schools can also hand over the artifact behind each answer, such as an Accessibility Conformance Report it authored or load test results from an enrollment peak.
A wrong pick costs more in education because institutions adopt on the academic calendar. A missed launch can cost a semester, since no institution switches platforms in week six. Repositories and cloud accounts left in the vendor's name mean a buyer owns code no other team can deploy.
This evidence-first guide to hiring an EdTech development company pairs each question with its proof, tests experience by layer, and fits the interview to your engagement model. It then covers product strategy, architecture, interoperability, accessibility, privacy and AI before closing on legal terms, exit readiness, proposal comparison, red flags, and the evaluation committee. The practical question is how to confirm an EdTech development partner can prove its claims before signing. It is written for founders, CTOs, academic leads, and procurement teams shortlisting EdTech software development companies.
A question is only as good as the evidence you can demand behind it. Any competent salesperson can answer "do you have EdTech experience?" correctly, so the question sorts nobody. Adding three things to each question fixes that: the shape of a strong answer, the artifact that would prove it, and the answer pattern that signals risk.
Run every question in this guide through that structure.
Ask | What a strong answer sounds like | Proof to request | Red flag |
|---|---|---|---|
Show us a product comparable to ours | The team describes user roles, the integration surface, and the constraint that shaped the architecture | Case study, named reference, the team's actual role on the project | "We've worked with education clients," followed by marketing sites |
Which interoperability standards does our platform need? | The vendor names the two or three that apply and explains why the others do not | An integration they built against that standard | A list of every acronym in the category |
How will accessibility be validated? | Accessibility enters at design, then automated and manual testing through delivery | A conformance report they authored, plus their test process | "We'll run a scanner before launch" |
What would you not build in phase one? | Specific cuts, with the reasoning tied to risk and outcomes | Their prioritization rationale from a past project | Agreement with everything in your scope |
Could another team take this over tomorrow? | Client-owned repositories and cloud accounts, with written runbooks | Repository access model, architecture docs, handoff plan | Infrastructure that lives in the vendor's accounts |
The pattern matters more than any single row. When a vendor answers well but cannot produce the artifact, you have found a gap between the sales team and the delivery team, which is the most common failure in this market.
Education software experience is not one qualification, and treating it as one is how buyers end up with a team that has built a course catalogue but never survived an exam-day traffic spike. Decompose it into layers, then test the layers your product actually depends on.
| Capability layer | Question that tests it | Evidence that settles it |
|---|---|---|
| Learner experience | How did you handle learners who drop off mid-course in a product you shipped? | Screens, analytics, or research from that project |
| Instructor and author workflows | Who on your team has watched an instructor build a course? | Named workflow decisions and the reason behind them |
| Administration | What does day-two administration look like for the client who runs this? | Admin documentation from a shipped product |
| Architecture under load | What is the peak concurrency profile of a system you built? | Load test results, incident history, scaling decisions |
| Accessibility | What conformance target did you design against, and who tested it? | A conformance report and the audit method |
| Privacy and data handling | Which learner data did you hold, where, and for how long? | Data flow diagram, retention policy, subprocessor list |
| Interoperability | Which standards have you implemented against a real institutional system? | Integration architecture and the partner system involved |
| Assessment integrity | How did you handle a contested exam attempt? | Attempt logging, scoring, and appeal handling design |
| Content operations | How does content get updated after launch without a release? | Authoring and publishing model |
| Analytics | What decision did your reporting change for an administrator? | A report or dashboard built for a real user |
A generic agency can fake one or two of these rows in a sales call. Faking eight is difficult, which is why the layered version of the question is more useful than asking whether the vendor knows education.
Three situations bring buyers to this search, and they need different interviews. Deciding which one describes your organization takes a minute and changes most of what follows.
Building something new puts the risk in scope and sequencing, and in how fast a first release reaches real learners. The questions that matter are about discovery, what gets cut, and how quickly the team can put something in front of users.
Modernizing or scaling an existing platform means the risk sits in the code and data you already own. The most revealing question here has nothing to do with features: ask the vendor to describe how they would learn an unfamiliar codebase before proposing a rewrite. A team that answers with a discovery period, a dependency map, and a staged plan has done this before. A team that proposes a rebuild in the first call is selling the engagement it prefers to run.
Replacing or supplementing a development partner carries a different risk again, because somebody has to inherit a system nobody documented. Ask what the vendor needs from the outgoing team, how long a takeover assessment takes, and what they do when the previous partner will not cooperate. The honest answer includes a period where velocity drops.
The vendors worth shortlisting will disagree with part of your plan during the sales process. That behavior is the signal, because a team that agrees with every requirement has no opinion to contribute and will bill you to build whatever you specify.
Useful questions here:
The last one produces the most information. Vendors who consult for a living have a story ready, usually with a number attached. Vendors who staff projects change the subject to their process.
There is a related test for consulting maturity. A partner who determines whether you need a custom build, an existing platform extended, a modernization, an integration layer, or extra engineering capacity is thinking about your outcome. A partner who recommends custom development before understanding the workflow is describing its own service menu.
Education platforms fail in ways that general SaaS does not, because usage arrives in spikes tied to a calendar. Semester start, assignment deadlines, and exam windows produce concurrency that a steady-traffic architecture handles badly.
That last question deserves weight. Missing a launch by three weeks in most industries costs three weeks. Missing it in education can cost a semester, because institutional buyers adopt on an academic calendar and will not switch platforms in week six. Ask how the vendor has handled a date tied to an enrollment cycle, and what they cut to make it.
Standards matter when an institution has to exchange data with your product, and they are noise when nobody is asking for them. The vendor that lists every acronym in the category has not done the analysis. The one that asks which systems your customers already run is doing the work.
| Standard | What it does | When it matters to you |
|---|---|---|
| LTI 1.3 and LTI Advantage | Lets a learning platform launch an external tool and pass assignments and grades back to the central gradebook, with services for grades, roster and role data, and content selection (Source: Learning Tools Interoperability - 1EdTech) | Your product runs inside someone else's LMS, or you host third-party tools |
| OneRoster | Exchanges people, courses, enrollments, organizations and grades between systems such as an SIS and an LMS, with rostering, gradebook and resource services (Source: OneRoster - 1EdTech) | Institutions need class rosters kept in sync without manual uploads |
| QTI 3.0 | Packages assessment items and tests in a portable format so they move between applications and institutions keep ownership of their content (Source: Question & Test Interoperability - 1EdTech) | You hold a question bank customers may want to take elsewhere |
| xAPI (IEEE 9274.1.1-2023) | Records learning activity as statements sent to a Learning Record Store, including activity outside a course player (Source: Experience API - xAPI) | You track learning that happens beyond the platform |
| SCORM | Packages course content for older LMS environments | A corporate buyer's existing LMS requires it |
Ask the vendor to walk through one integration they built against a live institutional system, including what failed the first time. Roster sync in particular breaks on the details, and the detail that exposes real experience is what happens when a student transfers mid-year. A team that has shipped into schools answers with grades, enrollments, and assignment history. A team that has not answers with API design.
Accessibility decides deals in education, because institutional and public-sector buyers ask for conformance documentation during procurement. Two questions separate teams who build accessible products from teams who audit at the end.
The first is which conformance target the vendor designs and tests against. The current answer is WCAG 2.2, published by W3C on 5 October 2023 and updated on 12 December 2024, which W3C recommends using because it has the widest future applicability. WCAG 2.2 is also an approved ISO standard, ISO/IEC 40500:2025 (Source: WCAG 2 - W3C). A vendor still describing WCAG 2.1 as current in 2026 is working from old material.
The second is how conformance gets verified. Automated scanners catch a fraction of issues and nothing about whether a screen reader user can complete an enrollment. Ask what proportion of testing is manual, who performs it, and whether people with disabilities take part.
Then ask for the document your procurement team will need. A Voluntary Product Accessibility Template is a template that translates accessibility requirements from frameworks such as Section 508 into testing criteria, and a completed VPAT with documented results is called an Accessibility Conformance Report (Source: VPAT - ITIC). Editions exist for Section 508, the EU, WCAG, and all three combined. A vendor who has authored one can show it. A vendor who has not will offer a policy statement instead.
Privacy requirements depend on who your learners are and which markets you sell into, so the useful question is not whether a vendor is compliant with a list of acronyms. Ask which requirements apply to your product, and why.
A partner working on a US K-12 product should be able to explain the school official exception under FERPA and what a written agreement with a district has to cover. If the product collects data from children under 13, the amended COPPA Rule applies. The Federal Trade Commission published its amendments in the Federal Register on 22 April 2025, with full compliance required one year after publication. The changes include separate verifiable parental consent before disclosing a child's personal information to third parties for targeted advertising, limits on retaining personal information beyond the purpose it was collected for, and an expanded definition of personal information that now covers biometric and government-issued identifiers (Source: FTC). Asking a vendor how their approach reflects the revised rule tells you more than asking whether they are COPPA compliant.
For European learners, ask about lawful basis, data residency, and subprocessors. For institutional buyers anywhere, ask what evidence the vendor can hand your customer during a security review.
Five questions that produce checkable answers:
One more piece of evidence is worth asking for. 1EdTech vets products against a data privacy rubric and lists certified products in its TrustEd Apps directory, where the public can see that an application has been vetted. If a vendor claims interoperability or privacy credentials, ask which of the products they built appear there.
AI features change the vendor evaluation because they add a dependency you do not control and a cost that scales with usage. General EdTech buyer guides still tend to skip this.
A team that has taken an AI feature from pilot to institution-wide rollout answers the monitoring question with specifics: what they log, how they sample outputs, and what they found in the first month. A team that has only built demos describes the model instead.
Commercial terms decide what you own when the relationship ends, which is the moment nobody plans for during a sales cycle.
Ownership of source code is the question most buyers ask and the weakest one available, because owning code you cannot deploy is not ownership. The test that matters is operational.
Ask the last question directly and watch how specific the answer gets. Teams that have handed over a system before describe their runbooks. Teams that have not talk about how unlikely a handover is.
A $150,000 proposal and a $250,000 proposal are not comparable until the scopes are normalized, and in most cases the gap is scope rather than rate. Rebuild both proposals against the same line items before anyone discusses price.
| Line item | What to check in each proposal |
|---|---|
| Discovery | Included, excluded, or billed separately |
| UX and learner experience design | Research and testing, or screens only |
| Architecture | A named architect, or design that happens during coding |
| QA | Manual coverage, automation, and who writes the tests |
| Accessibility | Design, testing, and documentation, or none |
| Security | Testing, review, and remediation time |
| Integrations | Which systems, how many, and who owns the contract with each |
| DevOps and infrastructure | Environments, pipelines, monitoring, and whose accounts |
| Documentation | Deliverables named, or best effort |
| Project management | Included in the rate or added on |
| Warranty and support | Duration, response times, and what counts as a defect |
| Third-party and cloud costs | Estimated and passed through, or absent |
The proposal that looks expensive often includes discovery, accessibility work, and a warranty period that the cheaper one leaves for a change request. A vendor who cannot produce this breakdown on request has not planned the work.
Scoring vendors on a worksheet helps, up to the point where it implies false precision. A few findings belong outside the scoring entirely, because they end the conversation.
A team can score well on capability and still fail on one of these, which is why the worksheet should record deal-breakers separately from ratings.
Vendor selection in education involves more people than the person running the search, and each of them protects a different risk. Sending this list to the right people before the first vendor call saves a round of interviews.
| Role | The question they should own |
|---|---|
| Founder or CEO | What will you challenge us on, and what outcomes will you own? |
| CTO or VP Engineering | Who designs the architecture, and what broke at scale in your last comparable build? |
| Product lead | How do you decide what should not be built? |
| Head of learning or academic lead | How do instructors and learners enter your product decisions? |
| CIO or enterprise architect | Which institutional systems have you integrated, and how did identity work? |
| Security and privacy | Where does learner data live, who touches it, and what evidence can you give our customers? |
| Accessibility lead | What conformance target, and how much of the testing is manual? |
| Procurement and legal | Who owns the code, the accounts, and the exit? |
| Finance | What is excluded from this price, and what drives cloud and AI costs? |
| Operations or LMS admin | What does running this look like on a Tuesday in week eight? |
Arbisoft's education work shows why the architecture and interoperability rows carry weight. Its engagement with edX began in 2013 and grew to a team of more than 150 people covering platform development, course authoring, testing, and support, including enterprise single sign-on and integrations with third-party systems such as SAP SuccessFactors and Degreed. Work of that shape is visible in public contribution records, which is the kind of evidence worth asking any vendor to produce.
Start with a comparable product, then ask which interoperability standards your platform needs and why the others do not apply, how accessibility gets tested, what the vendor would cut from phase one, and whether another team could take over the codebase tomorrow. Pair each question with the artifact that proves the answer: a case study, a conformance report, an integration architecture, or a handoff plan.
Break the claim into layers and test the ones your product depends on: learner experience, instructor workflows, administration, load behavior during exam and enrollment peaks, accessibility, privacy, interoperability, and assessment integrity. Ask for evidence per layer. General agencies can speak convincingly about one or two, and rarely about eight.
It depends on whether your differentiation lives in the part you would build. A branded catalogue with seat-based access, quizzes, and completion reporting is well served by an existing platform such as Open edX or Moodle, configured or extended. Custom development earns its cost when a distinctive workflow, data model, or learning mechanism is the reason customers choose you.
Price depends on scope, not on hourly rate, and proposals become comparable only after you normalize them against the same line items: discovery, design, architecture, QA, accessibility, security, integrations, DevOps, documentation, project management, warranty, and third-party costs. A gap between two proposals usually means one of them excluded work that will return as a change request.
That depends on your learners, your markets, and how data moves between systems. US K-12 products handling student records fall under FERPA, products collecting data from children under 13 fall under the amended COPPA Rule, and European learners bring GDPR obligations. Ask a prospective partner to identify which requirements apply to your product and to explain their reasoning, rather than confirming a list.
Pick the three capability layers your product actually depends on, write the four-part test for each, and send the relevant rows of the committee table to the people who own those risks before the first vendor call. Two interviews run this way will tell you more than six run on feature lists.
If you are weighing a build, a modernization, or a shortlist of proposals, bring your requirements, your existing architecture, or the proposals themselves to a conversation with an EdTech product team. The useful outcome of that call is a clear read on which route fits, including the cases where extending a platform you already run beats building something new.
Trusted by top platforms for our transformative solutions and exceptional results:






