Building in-house gives you exactly the system you want and no licence fee. The cost is ongoing rather than upfront: someone has to maintain it, patch it, and still be there in year five. Most in-house school systems are built competently and then stranded when the person who built them leaves.
Every large education group considers this, and the arithmetic looks compelling. A developer costs less per year than a subscription for eight thousand students. You get exactly what you want. Nobody can raise the price on you.
The arithmetic is right about year one and wrong about year five, and the reason is not technical competence. In-house school systems usually work. They get stranded.
Build in-house if software is a strategic capability for your group, you can fund two or more developers permanently, and you have a genuinely unusual model no product fits. Buy if the developer would be a single person, or a contractor, or somebody’s nephew — not because they lack skill, but because a one-person system has a one-person lifespan.
| What you are comparing | TurtleDock | An in-house build |
|---|---|---|
| Fit to your process | Configurable, within a model | Exact, by definition |
| Licence cost | Per student, per year | None |
| Change control | Our roadmap | Yours entirely |
| Real annual cost | Predictable subscription | Salaries, infrastructure, opportunity cost |
| Regulatory change | We track and ship it | You notice it, then build it |
| Security patching | Continuous, ours to own | Only when someone remembers |
| If the builder leaves | No effect | The central risk |
| Time to running | Two to six weeks | Nine to eighteen months, realistically |
In-house business cases usually compare a salary against a subscription. The comparison is missing several lines.
There are real cases, and we lose these fairly.
Most groups that want to build actually want one specific thing that is genuinely theirs — a particular analysis, an integration with something proprietary, a trust-level report shaped exactly their way.
Buying the record and building that one thing on top of the API and exports gets the distinctive part without owning attendance, fees and report cards forever. It also fails safely: if the internal project stalls, the school still runs.
Phrased the way they arrive, answered so each one stands on its own.
Not automatically. If it works and is maintained, keep it. Reassess when the person who maintains it becomes unavailable, or when a regulatory change sits unimplemented for a term — those are the signals that the arrangement has stopped working.
Yes, via API and structured exports. What you cannot do is modify SchoolDeck at source level; if that is a requirement, an open-source system is a better fit and we will say so.
Admissions, attendance, fees, examinations, report cards, a parent app and messaging, all correct enough to run a school on, is nine to eighteen months with a small team. The first three months look much faster than that, which is what makes the estimates optimistic.
Checked by the Implementations desk on 7 September 2026. Corrections go in the page, dated, rather than quietly.
Pricing is on the page, in the open, with the counting rule written next to it. Nobody has to book a call to find out what it costs.
See pricingForty minutes with an implementation engineer — your classes, your fee heads, your grading scheme, entered as we go. No slides, no sample school.