TurtleDock builds a separate product for schools, for colleges and universities, for coaching institutes, and for students preparing on their own. Each has its own data model and its own records — and inside each, nothing is exported from one desk to be re-typed at the next.
A school, a college, a coaching centre and a student each get their own product, their own data model and their own records. None of them is a “module” of another.
Four separate products. One platform underneath. Never one shared database.
Between products, nothing is shared. A school’s records live in SchoolDeck, a college’s in CampusHub, a centre’s in TutorDesk, a student’s in ExamEdge. Different customers, different data models, no common student table.
Inside a product, everything is. Attendance, fees, marks and messaging write to one row per person — so nothing is exported from one desk to be re-typed at the next. Switching a module on is a permission change, never a migration.
Underneath, the engineering is common. Infrastructure, permissions, audit, payments and messaging are built once and hardened for all four.
How the 24 modules divide across the fourSchools, colleges, coaching centres and students run on different calendars, and each has a stretch where a slow system gets abandoned. Every product is engineered for its own peak.
Infrastructure, permissions, audit, payments and messaging are engineered once and hardened for all four products — shared code, not shared data. Student data is the most sensitive data an institution holds; these are the defaults, not a tier.
SchoolDeck, CampusHub and TutorDesk are configured with you: the year first, people second, money once the ledger reconciles. ExamEdge needs no rollout — a student signs up on a phone and starts with a diagnostic.
Most of what makes institutional software bad is a business decision, not a technical one. These are ours.