How The Schools Platform went from an idea to a secure, multi-tenant SaaS in 12 months
Triotech took The Schools Platform from a blank page to a production-ready, multi-tenant school SaaS in 12 months: web, iOS and Android, per-school encryption, and UK GDPR and POPIA controls.
12 monthsfrom a blank page to production-ready SaaS
3platforms: web, iOS and Android
5security tools in every build
/situation
The situation
The Schools Platform started as an idea, not a product. Its founders saw a gap between schools and parents: admissions, attendance, marks, messages, events and fees were spread across separate tools, paper and email, and families had no single place to stay connected with their child's school. They needed a technology partner to turn that idea into a complete product, starting from a blank page. The product had to work for a small primary school and a multi-campus group alike. It would hold student records, learning-support notes and parents' payments, and it had to meet the UK GDPR from day one, then South Africa's POPIA as the platform expanded. A privacy failure would end the business before it started.
/constraint
The constraint
No product, no specificationSensitive data about childrenPaymentsMany schools, one platformThree audiencesWeb and mobileTwo privacy regimes
- No product, no specification. Everything, from requirements to design to code, had to be created.
- Sensitive data about children. Student records and learning-support information demand the strictest protection.
- Payments. Parents pay school fees through the platform, so payment security couldn't be an afterthought.
- Many schools, one platform. Every school needed its own branding and fully separate, encrypted data, on shared infrastructure.
- Three audiences. Families, teachers and school leaders each needed a different experience.
- Web and mobile. Everything had to work in the browser and in iOS and Android apps.
- Two privacy regimes. UK GDPR at launch, then POPIA for South Africa.
/what-we-did
What we did
- Discovered the real problemWe worked with the client on the problems schools and parents actually face, and on the rules schools operate under. Our business analyst turned that into a Business Requirements Document and a Software Requirements Specification, so everyone agreed on what was being built before a line of code was written.
- Designed one product for three audiencesFamilies: admissions, messages, fees and school news in one place. Teachers: registers, marks, timetables and pupil support. School leaders: dashboards, reports and a view across every campus.
- Built one platform that keeps every school apartMulti-tenant by design: every school runs on the same platform and gets new features and fixes at the same time, while its data stays completely separate. White-labelled: each school carries its own logo, colours and identity across the web portals and the iOS and Android apps. Modular: admissions, academics, attendance, pupil support, communication, finance, reporting and administration are isolated modules, so a problem in one can't spill into another. Fully on AWS: application, database, storage, networking and delivery.
- Gave each school its own encrypted schemaSchema segregation: every school has its own schema in a multi-tenant MySQL database, so data can't mix, even by mistake. Encryption per tenant: each school's schema is encrypted on its own. Built for onboarding: bulk data import loads a new school's students, parents, staff and classes in one step. Built for reporting: dashboards and a custom report builder pull data across modules without slowing day-to-day use.
- Built every module, web and mobileFor families: automated admissions, real-time messaging with the school, online invoicing and fee payments through Stripe, and email and SMS notifications. For teachers: attendance registers from any device with missing-register alerts, markbooks and progress reports, a timetable engine, and learning-support profiles with early flagging. For school leaders: a live dashboard, a consolidated multi-campus view, a custom report builder and bulk import. For every school's brand: white-labelled web portals and React Native apps for iOS and Android.
- Designed in security and privacy from day oneRole-based access per module: a teacher sees their classes, a parent sees only their own children, and learning-support records are restricted to the staff who need them. Every request checked against both the user's role and their school, so nobody can reach another school's data, even by changing a link. Encryption at rest and in transit, per school schema and across every app and browser. Payments through Stripe, a PCI DSS-certified provider, linked to invoices for clear reconciliation. Five security tools in every build: SonarQube, Semgrep, OWASP ZAP, Trivy and Gitleaks. Separate environments, so real school data never sat in test environments. Privacy compliance: controls designed for the UK GDPR at launch and extended for POPIA in South Africa.
- Delivered in two-week sprintsAgile delivery: two-week sprints, each ending with a demo to the client, planned in Jira and documented in Confluence. Four environments: feature, development, staging and production, with QA and the client reviewing every release on staging. Quality assurance: manual testing against the specification, automated and regression tests on every change, and cross-platform testing on web, iOS and Android.
- Advised on compliance throughoutWe kept the client ahead of regulatory requirements at every stage, from UK GDPR at launch to POPIA as the platform expanded, so compliance was met in the design rather than patched in later.
- Launched and handed overDemoed to 5 schools to prove the product and gather feedback. Handed over a production-ready platform to the client's sales and marketing team, with documentation and guides in Confluence. Support: 3 months of post-launch support.
How a change ships
- 1A feature is planned in Jira as part of a two-week sprint.
- 2A developer builds it on a feature branch in GitHub.
- 3CI/CD runs automated and regression tests.
- 4SonarQube, Semgrep, Trivy and Gitleaks scan the code, dependencies and secrets.
- 5It moves to staging, where OWASP ZAP tests the running application and QA tests the feature.
- 6The client reviews it at the sprint demo.
- 7It's released to production on AWS.
/result
The result
Idea to SaaS in 12 monthsA production-ready product, built from a blank page.
Every module built by TriotechFrom admissions to multi-campus reporting.
Three platformsWeb, iOS and Android (React Native).
Multi-tenant, schema per schoolEach school's data in its own encrypted schema.
Every school white-labelledIts own branding across web and mobile.
Privacy by designPer-tenant encryption, role-based access, and controls for UK GDPR and POPIA.
Five security tools in every buildSonarQube, Semgrep, OWASP ZAP, Trivy and Gitleaks.
Secure fee paymentsThrough Stripe, with email and SMS notifications keeping parents informed.
Fully on AWSApplication, database, storage and delivery.
Demoed and handed overShown to 5 schools, handed to the client's sales team with full documentation, plus 3 months of support.
/technology
Technology
PHPMySQLReact NativeAWSStripeSonarQubeSemgrepOWASP ZAPTrivyGitleaksGitHubJiraConfluence
Technology
Application: PHP · MySQL (multi-tenant, schema per school, encrypted) Mobile: React Native (iOS and Android) Cloud and payments: AWS · Stripe Messaging: Email · SMS DevSecOps: SonarQube · Semgrep · OWASP ZAP · Trivy · Gitleaks Delivery: GitHub · CI/CD · feature, dev, staging and production environments Collaboration: Jira · Slack · Confluence
/free-audit
Find out what your stack is hiding.
If you're building a product that holds sensitive data, security and privacy have to be in the design, not bolted on before launch. Book a free audit and we'll show you where to start.