An education or EdTech website is rarely just a marketing surface. It may support learning, admissions, content authoring, payments, safeguarding workflows, staff administration and integrations with systems that cannot simply be replaced.
Choosing the right agency therefore requires more than reviewing visual portfolios. You need evidence that the team can understand the educational outcome, design for diverse users and deliver a system your organisation can operate safely.
Define the outcome before the platform
Start by writing the change the project should create. Examples include:
- more prospective families completing an enquiry or application;
- learners finding and finishing the right activity;
- teachers publishing accessible content without developer support;
- administrators reducing duplicate data entry;
- an EdTech product proving a new workflow before scaling;
- improved visibility of learner or programme outcomes.
Then name the users: learners by age or stage, parents, teachers, administrators, support teams, assessors, employers or partners. “All users” is not an actionable audience.
A good agency will challenge a platform-first brief. It should help distinguish the essential outcome from features inherited from an old system or a competitor screenshot.
Look for discovery that reaches the classroom and operation
Stakeholder workshops with leadership are useful but insufficient. The team should plan to observe or interview the people who perform the actual tasks, with appropriate consent and safeguarding controls.
Discovery should investigate:
- current journeys and workarounds;
- learning or service objectives;
- content governance and approval;
- device, connectivity and assistive-technology constraints;
- data sources and ownership;
- seasonal deadlines such as admissions or exam periods;
- procurement, security and policy requirements;
- what must remain operational during migration.
Ask for the concrete outputs: a prioritised journey map, risk register, architecture options, prototype, content model or delivery roadmap. “Discovery workshop” alone does not describe value.
Accessibility must shape the system
Accessibility is not a final audit or a contrast plugin. It affects navigation, forms, media, assessment, feedback, authoring tools and content governance.
Ask how the agency applies WCAG 2.2 and tests with keyboard and assistive technology. If staff or teachers create content, the authoring interface and the content it produces also matter. The W3C's education guidance on authoring-tool accessibility provides useful context for that wider responsibility.
Request evidence from a real project:
- an accessibility acceptance criterion;
- an example issue and how it was fixed;
- the assistive technology and browser combinations tested;
- how captions, transcripts and alternative text are governed;
- how editor mistakes are prevented or surfaced;
- what independent review is included.
An automated score is supporting evidence, not proof of accessibility.
Safeguarding and privacy require explicit boundaries
The website or platform may process learner details, communications, progress, support needs or behavioural data. The agency should be able to map data flows and minimise collection before choosing implementation details.
Discuss:
- age and identity assumptions;
- parental or institutional roles;
- moderation and reporting routes;
- communication between adults and learners;
- audit trails and access reviews;
- retention and deletion;
- analytics and third-party scripts;
- export and subject-rights support;
- incident response and supplier access.
Do not accept “GDPR compliant” as a feature. Ask what data exists, why, where it travels, who can access it and how the operating organisation controls it.
The precise legal and safeguarding requirements depend on your jurisdiction, institution and audience. Obtain specialist advice where required.
Assess security as an operating capability
A credible team should explain its secure development and deployment process in plain language.
Look for:
- authentication and role design;
- least-privilege administration;
- dependency and vulnerability management;
- secret handling;
- separate test and production environments;
- peer review and automated checks;
- backups and tested restoration;
- monitoring and incident ownership;
- patching and support after launch;
- a responsible route for reporting vulnerabilities.
Ask who will hold production access and how access is removed. If the agency uses subcontractors, establish the same controls and responsibilities for them.
Integrations deserve early technical evidence
Education projects often depend on a management information system, learning platform, single sign-on provider, payment service, CRM, assessment tool or content repository.
An integration label in a proposal can hide a large uncertainty. Ask the agency to verify:
- which API or standard is available;
- whether your licence permits access;
- authentication and rate limits;
- the authoritative system for each record;
- identity matching and duplicate handling;
- failure, retry and reconciliation behaviour;
- sandbox or test-environment availability;
- supplier support and change notices;
- data import, export and exit requirements.
A small technical spike before the full build can retire more risk than weeks of interface design.
Examine the learning and content model
For learning products, ask how the team models courses, activities, attempts, feedback, completion and evidence. The right structure depends on the pedagogy and reporting need, not just the CMS.
Questions include:
- Can content be reused without creating conflicting copies?
- Can different roles see appropriate versions?
- How are prerequisites and progress represented?
- What happens when published content is revised?
- Can staff preview the learner experience?
- Is data export understandable outside the application?
- Which analytics reflect learning rather than clicks alone?
For institutional websites, content ownership is equally important. Define who can publish urgent notices, update policies, retire old courses and review accessibility.
Ask for evidence, not sector decoration
A row of education logos is not enough. Request a case study that explains:
- The original problem.
- The users and constraints.
- The team's specific responsibility.
- The difficult decision or risk.
- The delivery and verification method.
- The measured result, with appropriate caveats.
- What the agency would do differently now.
Relevant experience can come from adjacent regulated or multi-role systems, not only an identical institution. Judge whether the team can transfer the underlying capability.
Talk to a reference about communication, change control, difficult releases and post-launch behaviour, not just whether the finished site looked good.
Compare delivery approaches
Fixed scope
Useful when requirements and integrations are sufficiently understood. Demand explicit assumptions, acceptance criteria and change control.
Phased product delivery
Useful when the organisation needs to validate workflows. Each phase should produce a usable outcome and evidence for the next decision, not an endless prototype.
Embedded or retained team
Useful for a live product with continuous priorities, provided ownership, budget controls and knowledge transfer are clear.
Whichever model you choose, ask how the agency handles school terms, enrolment peaks, change freezes and stakeholder availability.
Run a small evidence-based selection
A practical procurement process might be:
- Share the outcome, users, constraints, known systems and budget range.
- Ask a shortlist to identify risks and questions before proposing a solution.
- Score the written response against published criteria.
- Hold a working session on one real journey or integration.
- Check technical, accessibility and delivery evidence.
- Speak with relevant references.
- Resolve ownership, support and exit terms in the contract.
Pay finalists for substantial speculative work if you require it. Do not ask several agencies to design the full product for free; that rewards presentation speed rather than durable collaboration.
Our general guide to choosing a web development agency offers additional questions on scope and commercial fit.
A weighted scorecard
Adjust weights for the project, but consider:
- understanding of educational and user outcomes;
- accessibility approach and evidence;
- safeguarding, privacy and security maturity;
- integration and data architecture;
- product, content and learning design;
- delivery and quality process;
- support, knowledge transfer and exit;
- total cost and commercial clarity;
- chemistry and communication.
Score evidence, not confidence. Record concerns and dependencies beside the number so the decision remains auditable.
Red flags
Pause if an agency:
- chooses the platform before understanding users or integrations;
- treats accessibility as an optional final test;
- cannot explain production access or incident ownership;
- promises an integration without seeing documentation;
- offers a learner dashboard without defining useful outcomes;
- proposes collecting extra data “for future AI” without a present purpose;
- avoids ownership and export questions;
- prices the build but omits migration, training and support;
- guarantees adoption without addressing organisational change.
The bottom line
The right education or EdTech agency makes the hard boundaries visible early. It connects the educational outcome to user research, accessible interaction, responsible data, supported integrations and an operable delivery plan.
Choose the team whose evidence improves your decision, not only the team whose pitch looks most finished.
If you are planning an education website or learning product, talk to LogicLeap. We can help define the first valuable release, test the technical risks and build a procurement-ready scope.
