You have a product idea, a market you understand, and a budget that took months to put together. The next decision, choosing who builds it, will determine whether that budget delivers a working product or an expensive lesson.
EdTech founders in Ireland and the UK face a particular version of this problem. The pool of development companies willing to take an education brief is large. The pool that has actually shipped a product into a school, a university, or a corporate training environment is much smaller. The difference matters because education software carries constraints that generic web development does not: multi-role permissions, academic calendar dependencies, MIS (Management Information System, the school's core administrative database) integration, GDPR (General Data Protection Regulation, the EU's data privacy law) obligations around children's data, and institutional procurement cycles that penalise products which are not ready when the buying window opens.
This guide covers what to look for, what to test, and which questions reveal the most about a development partner before you sign anything.
Key takeaways
Domain experience is not optional. Education software carries regulatory, accessibility, and integration requirements that generic development teams routinely underestimate. A partner who has shipped into schools or universities will scope more accurately than one learning the sector on your budget.
The portfolio tells you more than the pitch. Look for live products with real users, not prototypes or concept work. A platform serving 25,000 students and holding 4.5 stars on the App Store is evidence. A case study with no named client and no verifiable outcome is not.
Proposals differ in scope, not just price. Two quotes for the same brief can vary by 40% because one includes accessibility testing, data migration, and security hardening while the other excludes them. Compare what is included before you compare what it costs.
IP ownership must be settled before work begins. Not every development contract transfers intellectual property to the client on completion. If your business model depends on owning the platform, confirm that the contract says so.
A discovery phase is the cheapest insurance against a misfire. Two to four weeks of structured scoping before development begins consistently produces more accurate budgets and fewer mid-project surprises than jumping straight into a build.
Why does EdTech need a specialist development partner?
Education software operates under constraints that most commercial SaaS (Software as a Service, cloud-hosted software sold by subscription) does not face, and these constraints shape every technical decision from architecture to deployment.
Multi-role permissions are structural, not cosmetic. A typical EdTech platform serves students, teachers, parents, school administrators, and sometimes district or ETB (Education and Training Board, one of 16 regional bodies managing further education in Ireland) supervisors. Each role carries distinct data visibility rules. A parent sees one child. A teacher sees their class. A principal sees the school. An ETB administrator sees multiple schools. Building this cleanly at the database and API (Application Programming Interface, the technical layer connecting different systems) level requires experience with hierarchical permission models, not just role-based checkboxes.
Compliance is not a feature you add later. Platforms handling student data must comply with GDPR, Irish Data Protection Commission (DPC) guidelines, and the European Accessibility Act (EAA), which has been enforceable in Ireland since June 2025. Building to WCAG (Web Content Accessibility Guidelines, the international standard for web accessibility) 2.1 AA from day one costs materially less than retrofitting. A development partner unfamiliar with these requirements will either miss them or discover them late, when the cost of correction is highest.
Integration with school systems is a specialism. Irish primary schools run on Aladdin. Post-primary schools use VSware. UK schools often connect through Wonde or work with SIMS. Each system has its own authentication model, data format, and sync behaviour. Standards like LTI (Learning Tools Interoperability), OneRoster, SCORM (Sharable Content Object Reference Model), and xAPI (Experience API) exist to bridge these systems, but conformance certification through 1EdTech is formal, not automatic. A generalist team that treats integration as a late-stage task will hit surprises that a specialist team prices in from the start.
Pro tip. Ask any prospective development partner to name the MIS systems they have integrated with. If the answer is vague, their integration estimate will be too.
What should you look for in a development company's portfolio?
Live products with verifiable outcomes. Not wireframes, not concept videos, not unnamed 'a leading education provider' references.
A credible EdTech portfolio shows platforms that real institutions or learners use. Leaving Cert Plus, built by Square Root Solutions, serves over 25,000 students across Ireland with a 4.5-star rating on the App Store and 4.9 on Google Play. That is a verifiable claim. A case study that says 'we helped a client improve engagement by 30%' without naming the client or the measurement is not.
Look for multi-product delivery. Education platforms are rarely a single interface. They typically include a learner-facing app, an educator or admin portal, and sometimes a parent or family view. A company that has delivered connected products on shared data, where a record entered once appears correctly across every interface, has solved the hardest architectural problem in EdTech. When Square Root Solutions built the MOSAIC early years platform, the team delivered three connected products: the Educator tablet app, the Family App, and an admin panel, all reading and writing to the same child record. That platform reached 85+ schools within five months of launch.
Check whether the company has built for your market. Irish and UK education markets have specific regulatory, curricular, and procurement requirements. A development company with strong references in the US or Indian market may not understand DPC guidance, Cuntais Mhiosúla planning formats, or the OGP (Office of Government Procurement) tender processes that govern institutional purchasing in Ireland.
How do you test whether a company understands education?
Ask questions that only someone who has built for schools or universities would answer well.
Ask what happens to their deployment schedule in September. A development partner who has shipped into schools knows that major releases during the academic year disrupt active classrooms. Irish schools operate on a September-to-June cycle. Testing windows compress. A bug discovered in May often cannot be safely deployed until July. If the answer to this question is blank, the team has not navigated an academic deployment cycle before.
Ask how they handle concurrent usage spikes. Assessment platforms face load patterns unlike most commercial software. Hundreds or thousands of students logging in simultaneously during an exam window demands infrastructure designed for peak load. A team that has built for this can describe their approach. A team that has not will treat it as a scaling problem to solve later.
Ask about their approach to accessibility from day one. The European Accessibility Act is enforceable. WCAG 2.1 AA is the minimum standard. A partner who treats accessibility as a post-launch audit has not built accessible products before. Screen-reader compatibility, keyboard navigation, and contrast ratios need to be in the component library from the start, not bolted on after the design is signed off.
Ask them to walk through a permission model. Describe a simple feature ('view student progress') and ask them to explain how it differs across roles. The answer reveals whether they understand the structural complexity of education software or whether they will underestimate it.
What technical capabilities actually matter?
Not every technology listed on a company's website matters equally. These capabilities separate teams that can deliver education software from teams that will struggle with it.
Cross-platform mobile and web delivery. Most EdTech products need to work on phones, tablets, and desktops. Frameworks like Flutter and React Native allow a single codebase to serve iOS, Android, and sometimes web, reducing development cost and keeping feature parity across platforms. When Square Root Solutions built the OnWard Education clinical training platform, the student app was delivered in Flutter across Android and iOS, with a shared backend serving the app and two web portals.
Real-time data synchronisation. Products that serve educators and learners simultaneously need real-time updates. When an educator posts a learning story in the MOSAIC app, parents see it in the Family App immediately through WebSocket connections and push notifications. A development partner that cannot demonstrate real-time sync capability will produce a platform where updates require manual refreshes, and users lose trust.
Scalable backend architecture. A platform that works for 50 beta users and collapses at 5,000 is a prototype, not a product. Node.js with NestJS, PostgreSQL, and Redis is a common stack in the Square Root Solutions portfolio, supporting products from Aquinas Education (10,000 teachers placed weekly) to Acuru (adaptive learning for PwC, Grant Thornton, and BDO).
AI integration capability. If your product involves adaptive learning, automated assessment, or content recommendation, the development partner needs demonstrable experience with LLM (Large Language Model) APIs, RAG (Retrieval-Augmented Generation) pipelines, or custom adaptive algorithms. The OnWard Education platform uses AI to compare student clinical notes against a defined question set. The Acuru platform uses custom adaptive algorithms to personalise professional exam preparation. Each approach is different. A partner who has done both understands when AI solves a real problem and when a rules-based system is the better answer.
Pro tip. Ask for the tech stack of two or three completed projects. Consistency across projects suggests a mature team with proven patterns. A different stack for every project suggests a team that follows trends rather than building expertise.
How should proposals be compared?
On scope, not price. Two proposals quoting €120,000 and €170,000 for what appears to be the same platform may not be comparable at all.
Comparison point | What to check |
UI/UX design | Is complete design included, or are wireframes expected from you? |
Accessibility testing | Is WCAG 2.1 AA compliance tested and guaranteed? |
Security hardening | Is penetration testing and encryption at rest included? |
Data migration | Is legacy data cleansing, mapping, and import included? |
Integrations | How many system integrations are included, and who manages API changes? |
Testing and QA | Does the quote cover automated testing, manual QA, and accessibility audit? |
Post-launch support | What maintenance period and SLA (Service Level Agreement) terms are included? |
IP ownership | Does the contract transfer all intellectual property on completion? |
An unusually low quote is not automatically poor value. But missing scope and unclear assumptions need investigation before you sign. A €120,000 proposal that excludes accessibility testing, security hardening, and data migration is not cheaper than a €170,000 proposal that includes them. It is incomplete.
What are the warning signs in a development partner?
Some patterns are consistently associated with projects that stall, overrun, or deliver a product that schools refuse to adopt.
No named education clients. A portfolio full of unnamed references ('a leading university,' 'a major publisher') may mean the work was subcontracted, the client relationship ended badly, or the case studies are fabricated. Named clients with verifiable outcomes are the minimum standard. Druid Learning, a Square Root Solutions client, is a content intelligence platform backed by Techstars and Enterprise Ireland, processing 500,000+ assets across 140+ languages for clients including NPR, CJ Fallon, and the Dutch Cancer Institute. Named, specific, verifiable.
Fixed-price quotes with no discovery phase. A company that quotes a fixed price from a feature list alone is either padding the quote to absorb risk or underestimating the work. The Standish Group's CHAOS research has consistently found that only around 31% of software projects are delivered on time and on budget. A structured discovery phase, typically two to four weeks, produces the scoping work that makes a fixed-price estimate credible.
No questions about your users. A development partner who jumps straight to technology choices without asking who the platform serves, how they currently work, and what problem needs solving is building to a specification, not to a need. When Square Root Solutions built MOSAIC, the team spent time understanding how an early years room actually works before designing anything. As the founder Avril McMonagle put it: 'They took the time to understand how an early years room actually works before designing anything, and it shows in how naturally educators took to the app.'
Resistance to transparent communication. Weekly progress updates, access to a project board, and regular demos of working software are baseline expectations for a professional development engagement. A partner who prefers to disappear for six weeks and return with a 'big reveal' is hiding problems, not solving them.
What does a good engagement model look like?
The best development partnerships follow a pattern: structured scoping first, iterative delivery second, and transparent communication throughout.
Discovery first. A two-to-four-week Discovery Sprint maps the problem, the user roles, the integration landscape, the compliance requirements, and the realistic budget. It produces a scoped brief that both parties can plan against. Square Root Solutions runs this as a standard engagement before any development begins, because the quality of the scoping determines the quality of the estimate.
Iterative delivery. Working software demonstrated every two to three weeks, not a single delivery after six months. Each iteration should be testable by real users or stakeholders, with feedback incorporated into the next cycle. This is how the Leaving Cert Plus platform evolved from a focused study tool into a multi-subject platform serving 25,000+ students, with content from practising Leaving Cert teachers and a partnership with CJ Fallon.
A retained relationship. Education products are not 'build and forget.' Academic calendars shift, curriculum specifications change, regulatory requirements evolve, and user expectations grow with adoption. The development partner should offer ongoing maintenance, support, and feature evolution as a retained engagement, not as an afterthought. The NameDown school admissions platform has been supported through multiple admissions seasons since 2021, growing the product as more schools came on board.
Pro tip. Ask for references from clients the company has worked with for two or more years, not just from recent projects. Long relationships are harder to fake than launch-day testimonials.
How do you protect your IP and your budget?
Two contractual issues cause more problems than any technical decision: intellectual property ownership and scope management.
IP ownership. Not every development contract automatically transfers intellectual property to the client. Some contracts retain IP with the development company until final payment. Others grant a licence rather than ownership. If your business model depends on owning the platform, the code, and the data architecture, confirm that the contract says so explicitly. This is especially important if you plan to raise investment, because investors will ask who owns the technology.
Scope and change management. Scope changes are inevitable in software development. What matters is how they are handled. A professional engagement includes a defined change request process: the client describes what changed, the development partner estimates the impact on timeline and budget, and both parties agree before work proceeds. Without this process, scope creep erodes the budget invisibly until the project stalls.
Milestone-based payments. Paying for completed milestones (discovery signed off, design approved, MVP deployed, production release) ties spending to deliverables. It gives the client natural checkpoints to assess progress and provides the development partner with a predictable cash flow. Avoid contracts that require large upfront payments with no deliverable attached.
Escrow and continuity. For critical platforms, consider code escrow arrangements. If the development partner ceases trading, you retain access to the codebase and can engage another team. This is insurance, not distrust, and a confident partner will not object to it.
Frequently asked questions
How much does it cost to hire an EdTech software development company?
Costs vary by scope and complexity. In the Irish market, a narrow MVP typically costs €25,000 to €60,000. A pilot-ready product with multi-role support and standard compliance runs €60,000 to €140,000. A commercial-grade platform with integrations, payment infrastructure, and production scalability sits between €140,000 and €300,000. These are indicative estimates. A structured discovery phase produces a more reliable figure than a quote based on a feature list alone.
What questions should I ask an EdTech development company?
Ask about their experience with school MIS integration (Aladdin, VSware, Wonde, SIMS). Ask how they handle accessibility compliance under the European Accessibility Act. Ask them to walk through a multi-role permission model for a simple feature. Ask for named clients with verifiable outcomes. Ask who retains intellectual property on completion. These questions separate teams with genuine EdTech experience from generalists learning the sector on your project.
Should I choose a specialist EdTech developer or a generalist?
A specialist who has shipped into schools or universities will scope more accurately, anticipate regulatory requirements, and navigate institutional procurement cycles. A generalist can build competent software but will typically underestimate the complexity of multi-role permissions, academic calendar constraints, and MIS integration. If your product serves the education market, choose a partner who has built for it.
How long does it take to build an EdTech platform?
Timelines depend on complexity. A narrow MVP takes 8 to 12 weeks. A pilot-ready product takes 12 to 22 weeks. A commercial platform with full integrations takes 6 to 12 months. These timelines assume a completed discovery phase and clear requirements. Projects that skip discovery typically take 30% to 50% longer due to mid-build scope changes. For a full breakdown, read How Long Does It Take to Build an EdTech Platform? What is a Discovery Sprint and why does it matter? A Discovery Sprint is a two-to-four-week scoping engagement that maps the problem, the user roles, the integration landscape, and the compliance requirements before any development begins. It typically costs €5,000 to €12,000 and produces a detailed brief, a realistic budget estimate, and an architectural recommendation. The alternative, jumping straight into development from a feature list, is the most common source of budget overruns and mid-project scope changes in EdTech projects.
Square Root Solutions builds custom EdTech platforms for founders, publishers, and training organisations across Ireland and the UK. If you are choosing a development partner and want to compare approaches, start with a Discovery Sprint two weeks, a mapped route, and an honest view of what the build requires.
