The questions worth asking before you commit.
Including the ones where the answer is “not yet”. A school choosing an operations platform is making a multi-year decision, and the fastest way to make it badly is to be told only the good half.
Getting started
How long does it take to get a school running?
It depends almost entirely on the state of your existing records. A school with clean spreadsheets of students, staff and classes can be operational in days. A school pulling data out of an older system, or off paper, should plan for weeks — most of which is checking the data rather than configuring the platform. We do that work with you rather than handing you an import template and wishing you luck.
Can we bring our existing data across?
Yes. Students, guardians, staff, classes, subjects and historical results can be imported. The honest constraint is quality, not format: if two spreadsheets disagree about which class a child is in, no import fixes that. We surface those conflicts before anything is written rather than after.
Do we have to move everything at once?
No, and most schools should not. A common path is to start with students, staff and attendance for one term, add assessments and results at the end of it, and bring finance across at the start of the next financial period. Each module works without the others being finished.
What happens if we decide to leave?
Your data is yours and you can export it. We would rather lose a school cleanly than hold anyone in place through the cost of leaving — a product that has to trap customers is not one we want to have built.
Security and data
Can another school ever see our data?
No. Each school is a separate tenant, identified from the hostname rather than from anything a browser can send. Isolation is enforced at the data layer: a query that arrives without a tenant scope fails rather than returning everything. This is a property of the architecture, not a filter someone remembered to apply.
Can a parent see another family’s child?
No. Holding the “read students” permission is not enough on its own — access is additionally constrained to the students a guardian is actually linked to. Permission decides what someone can do; the relationship decides which records it applies to.
Who can see a change to a student’s marks?
Important changes record who made them, when, and the values before and after. That history is surfaced to authorised school staff in the product, not left in a server log for an engineer to retrieve.
Are you SOC 2 or ISO 27001 certified?
No, and we will not imply otherwise. Both are on the roadmap and the platform is being engineered towards them — audit logging, environment isolation, access control and backup procedures are already in place. But certification is a formal audit we have not completed, and any vendor at our stage claiming it deserves a hard question.
Where is our data stored?
In managed cloud infrastructure with automated backups and a documented restore procedure. If your institution has a specific residency requirement, raise it early — it is a legitimate constraint and better discussed before you commit than after.
Using it day to day
Can we configure it to how our school actually works?
That is the point of the product. Grading scales, term structures, attendance rules, fee categories, approval steps, custom roles, branding and report card layouts are all configuration. A school that grades differently from its neighbour should not need a code change, and with Schoolspine it does not.
Can we create our own roles?
Yes — an Examination Officer, a Registrar, a Librarian, a Discipline Officer. A school defines the role and the permissions it carries. There is one guard rail: an administrator cannot grant a permission they do not themselves hold, which prevents someone quietly promoting themselves.
Does it work on a phone?
The web application is responsive and works on a phone or tablet, which covers a teacher taking a register or a parent checking results. Native mobile applications are on the roadmap and are not available yet.
What about poor or intermittent connectivity?
Today Schoolspine needs a connection. We treat offline tolerance for high-frequency tasks — attendance and marks entry especially — as a regional necessity rather than a nice-to-have, and it is a roadmap priority. We are not going to pretend it is finished.
How do parents get access?
A guardian exists in the school’s records whether or not they ever sign in — the school always has the contact. Portal access is granted separately, so a school can record every guardian without being forced to create accounts for all of them.
Commercials and support
What does it cost?
Pricing is agreed per school and scales with enrolment, charged per term or per year to match how schools budget. Staff accounts are not charged per seat — per-seat pricing makes schools ration accounts, which quietly undermines the audit trail. Pass-through costs such as SMS credits are billed at cost.
Who do we talk to when something goes wrong?
Someone who can actually fix it. There is no support tier to escalate through and no account manager relaying your problem to a queue — you reach the people who build and operate the platform, which is why an issue raised during exam week gets handled during that week.
What if we need a feature you do not have?
Tell us. A good proportion of what is on the roadmap came from schools describing a real workflow. What we will not do is build a private branch of the product for one customer — that path ends in a codebase nobody can maintain and a product that gets worse for everyone.
Still have a question?
Ask it directly. If the answer is that we have not built it yet, that is what you will hear.