Choosing an edtech software development partner starts with the work your team needs to get through. That might be an agent booking passed between centres, an application handed to another counsellor, or a partner update copied into several systems.
Before comparing proposals, define where that work stalls and what a useful first release would change. Then assess each company against the same workflow, dependencies and acceptance criteria. This guide gives language school groups, recruitment agencies and edtech owners a way to do that.
1. Bring one workflow to the first conversation
“We need a portal” leaves too much open. Describe who starts the process, what information they need, who acts next and how completion is recorded.
For example, a school with three centres might receive agent bookings by email. In this hypothetical workflow, staff check availability, confirm the price and enter the booking into a central system. A later date change reaches one centre but leaves the central record unchanged.
Use that example to prepare a short brief:
Trigger: an agent requests a booking or changes its dates.
People: agent, centre administrator and central bookings manager.
Records: course, dates, availability, agreed price and booking status.
Exception: the requested course is full or the quote has expired.
Acceptance: the authorised staff member confirms the change, and both views show the same current dates.
An agency can do the same for a counsellor handover. An edtech company can map a partner's first account setup. Ask each prospective partner to explain the gaps they would investigate before estimating.
2. Check whether custom development is necessary
Custom software for education businesses makes sense when a specific process needs rules, interfaces or connections that your current setup cannot reasonably provide. First check whether configuration, training or a narrower integration would address the problem.
Ask the team to compare three routes:
| Route | Useful when | Trade-off to examine |
| Configure existing software | The required workflow already fits its available settings | Your process must work within those settings |
| Add a module or integration | The core system works, but a handover or interface is missing | You depend on its API, permissions and future changes |
| Build a separate product | The workflow needs its own rules and user experience | You take responsibility for maintenance, hosting and ongoing product decisions |
A mobile app needs its own justification. Ask which task requires a phone feature or frequent mobile access. A browser-based interface may be enough for occasional partner administration. Compare the actual tasks before choosing platforms.
The education partner development page is a useful starting point for discussing portals, integrations and branded apps as separate scopes.
3. Ask for evidence of relevant problem-solving
When assessing an edtech software development company, look beyond sector labels and screenshots. Ask how its team clarified business rules, handled exceptions and tested a release.
Useful questions include:
What part of the work did your team deliver?
Which operational rule changed the proposed design?
How did you test a failed update or conflicting edit?
What did the client need to provide before work could proceed?
What was handed over, and what required a separate support agreement?
Use published case studies to examine scope and responsibility. Respect confidentiality: a team should be able to discuss its approach without exposing another organisation's private records. Treat a hypothetical demonstration as a demonstration, rather than evidence of past delivery.
Softvery builds custom software and AI features for international education companies. Assess that capability against your own process and ask what needs to be confirmed for your project.
4. Make the discovery sprint a purchase you can assess
A discovery sprint should resolve defined uncertainties. Before paying, agree which scenario it covers, who attends, what materials you provide and what you receive.
Request a written list of outputs:
A process map with roles, handovers and exceptions.
Key screen sketches that staff can review.
Assumptions, dependencies and unanswered questions.
A proposed first release with explicit boundaries.
An initial estimate and the conditions that could change it.
Ask what decision each output supports. A screen sketch can help staff assess the workflow. It does not establish whether an external system allows the required update. That may need a separate technical check.
Softvery's paid discovery sprint covers one scenario, key screens, assumptions and a next-step plan. Its stated duration is 5–10 working days from the agreed start after the source materials have been received. A working application, production code, live integrations and data migration are excluded from that sprint.
For background, read what a discovery sprint includes. In your proposal, confirm the specific outputs and review process for the scope you are buying.
5. Test integration and data assumptions early
“We can connect it” needs detail. Ask which system owns each record, which direction information travels and what happens when an update fails.
For a hypothetical agency commission tracker, separate an expected commission from an invoice issued and a payment received. Agree who confirms each status. A tracker can show an overdue item; payment still depends on the institution.
For every proposed connection, establish:
Access: who supplies documentation, test accounts and API permissions?
Mapping: which identifiers connect records, and how are duplicates handled?
Timing: when should changes appear in the receiving system?
Failure: who sees an error, retries it and checks the result?
History: what existing data must move, and who checks its quality?
Request a demonstration using invented data. Include a repeated update and a failed update, then check that neither creates a misleading status.
Review access through practical examples too. Can one agent see another agent's records? Can a former employee still sign in? Who can export or delete information? Agree the required controls and the people who approve them before development.
6. Choose a delivery model your team can manage
A defined module suits a business with a clear outcome and someone available to accept it. Agree the boundaries and change process before work starts.
A dedicated team suits ongoing product work when someone on your side can set priorities and answer questions. Monthly capacity still needs active management. Ask which roles are included and how unfinished work is reported.
Team reinforcement can fit an edtech company that already has technical direction but needs a particular skill. Define who reviews code, tests changes and authorises releases.
For every model, clarify:
Who makes product decisions and resolves conflicting requests?
Who checks business rules with your operations staff?
How often will you see working software?
How are scope changes priced and approved?
What happens if a dependency or decision is late?
Compare total responsibilities as well as price. A lower development estimate may exclude testing, migration or release work that another proposal includes. Ask each team to explain exclusions in plain language.
7. Agree acceptance, ownership and support
Write acceptance checks as tasks your staff can perform. For the hypothetical school booking change, test that an authorised administrator can approve new dates, the central record updates and an unauthorised agent cannot change another booking.
Include a failed connection and a way to recover. Agree who signs off, where testing happens and how defects are recorded. Plan the release around the people who must use and support it, including training and a fallback if the change cannot go ahead.
Before signing, ask about code access, documentation, hosting accounts, third-party licences and handover. Make ongoing support a specific discussion: coverage hours, issue priorities, response arrangements and responsibility for external services.
At Softvery, code and IP pass to you under the contract. Review the transfer terms and third-party licence conditions in the proposed agreement.
8. Compare written answers before choosing
Send the same brief to your shortlist. Record each answer as clear, partly answered or unresolved. Use this checklist in your review meeting:
Can they explain the workflow and its difficult exceptions?
Have they compared configuration, integration and a separate build?
Are discovery outputs and exclusions written down?
Have they identified dependencies requiring investigation?
Are decision-making, acceptance and change approval assigned?
Do the estimates cover comparable responsibilities?
Are ownership, handover and support terms clear?
Resolve the unanswered items before accepting a full build. If the remaining uncertainty is technical, scope a focused check. If it concerns your operating rules, involve the staff who make those decisions.
Where to start
Prepare one page: the workflow, current tools, an anonymised example, the main exception, a desired acceptance check and the person responsible for decisions. Add your budget boundary and any fixed operational deadline.
Use the partner software development overview to frame the initial discussion. Ask for a first step small enough to review before committing to a larger programme.
If you would like to discuss that brief, Book a 30-min call.
