Turn a broad software project into a useful checklist

A checklist is for deciding, not for ticking

These artefacts exist to force a decision that is otherwise deferred: who owns this data, which fee heads survive migration, what happens when a published result changes, who approves a concession. The value is in the disagreement a checklist surfaces during planning rather than during a live term.

Work through one with the people who own the work, and treat every item you cannot answer as a finding rather than an omission.

Take the output into vendor conversations

A completed checklist turns a demo from a presentation into an evaluation. Instead of watching a scripted flow, you can ask a vendor to demonstrate your fee structure, your role split, and your exception cases.

It also gives you a stable basis for comparing platforms, because every vendor is answering the same questions in the same order.

These tools never ask for student data

Everything in this directory collects planning choices only: structures, roles, dates, and preferences. No tool here asks for student names, guardian contact details, or any other personal data, and none is a route into a Schoolyi account.

If a planning tool anywhere asks a school to upload real student records to see a result, that is worth questioning. A planning artefact does not need a roster to be useful, and a school has no way to audit what happens to data it hands over during evaluation.

For the same reason, nothing here calculates a saving on your behalf from figures we invented. Where a tool produces a number, the inputs are yours and the method is shown, so you can disagree with the result and see exactly which assumption you are disagreeing with.