Skip to main content
Schoolyi

Product guides

Make-or-buy analysis for school management, ERP, and SIS

A make-or-buy analysis for school management software that compares internal development, procurement, configuration, integration, risk, ownership, and total cost.

By Schoolyi Editorial Team10 min read

Define the decision precisely

Make-or-buy is not a contest between building everything and buying everything. Define the workflow, users, data, controls, outcome, delivery date, support period, and boundaries first. A school may buy a platform, configure a workflow, integrate a specialist service, and build a small internal report.

State what must be dependable, what may remain manual, what must be local, and what evidence is required. Without that boundary, cost and capability comparisons are misleading.

Compare the operating models

For each option, record who owns product decisions, data quality, security, access, updates, integrations, training, support, incidents, backups, exports, retention, and contract-end work. Include the capacity required after launch, not only the delivery team.

GOV.UK procurement guidance highlights data protection by design, minimum necessary data, access control, security, subprocessors, incident notification, and data return or deletion. These are obligations to price and govern in both an internal and a supplier model.

  • Fit to the bounded workflow and exceptions
  • Time to a safe, testable release
  • Internal skills and continuity risk
  • Data, privacy, security, and supplier responsibility
  • Five-year operating and change cost

Model total cost honestly

Include discovery, design, migration, validation, infrastructure, licenses, integrations, support, training, security review, monitoring, upgrades, incident response, documentation, and staff time. Include the cost of leaving the option later, including data export and migration.

Do not invent savings from a faster screen or assume that internal work is free. Use ranges and assumptions, and identify the evidence that would change the estimate.

Compare risk and reversibility

Ask what happens if the option fails, the owner leaves, the school grows, a campus joins, a supplier changes, or requirements change. Test permissions, data quality, recovery, support, and contract-end data handling before accepting a low-risk label.

The U.S. Department of Education data governance resources offer a useful lifecycle structure for quality, access, security, sharing, disposal, and monitoring. Apply it to the chosen option and the rejected alternatives.

Make a bounded recommendation

Recommend an option for a defined phase, with assumptions, exclusions, evidence, owner, acceptance tests, hold rule, and review date. A buy decision may still require internal configuration and governance; a make decision may still require external services and specialist advice.

Review the recommendation at 30, 60, and 90 days after the first phase. Expand, change, consolidate, or stop based on evidence rather than sunk cost or enthusiasm.

Document the option that was not selected and the condition that could reopen it. This protects the school from treating the first decision as permanent when its staffing, requirements, risk, or economics change. It also makes later review more disciplined than starting the argument from memory.

Ask the decision maker to confirm the trade-off in plain language. The chosen option should state what the school accepts, what it will not accept, and which evidence would change the recommendation.

Apply the guidance to one school decision

Before approving this guidance for make-or-buy analysis for school management software, translate it into one school-specific decision record. State the workflow, roles, data fields, permissions, evidence, support route, academic-calendar constraint, and condition that would hold the next phase. Keep product capability, school responsibility, legal advice, and measured outcome as separate questions.

Run the decision with controlled data and the people who will operate the workflow. Record what was observed, what remains unknown, who owns the unresolved item, and when it will be reviewed. Revisit the record after launch at 30, 60, and 90 days. This keeps a useful guide from becoming an untested promise or another document that sits outside daily work.

Keep reading

Related guides

Back to all guides