Platform model
Multi-tenant by design
Shared control plane, isolated tenant workspaces, domain-aware routing.
ShuleHQ
Public onboarding for institution rollout, implementation planning, and tenant activation.
Run school rollout with control
Public onboarding at the front, SaaS control in the admin plane, schools on their own subdomains.
ShuleHQ separates prospect intake, platform administration, and school operations so each part of the system lives on the right host with the right controls.
Operational span
Admissions to collections
Student lifecycle, finance, timetable, HR, exams, notifications, and audit.
Control posture
Role- and policy-driven
Tenant permissions, SaaS oversight, and traceable operational history.
Public site
shulehq.co.ke
Prospect access, rollout requests, demo planning, and implementation intake.
Admin host
admin.shulehq.co.ke
SaaS dashboard, rollout oversight, tenant management, and platform operations.
School host
novel-school.shulehq.co.ke
Director, principal, and secretary workspaces isolated to each tenant.
Host-separated routing for public, admin, and tenant entrypoints
TLS at the edge with loopback-only application exposure behind the proxy
Controlled prospect workspace before any rollout conversation starts
Tenant provisioning aligned to requested school subdomain ownership
Request desk
Start implementation from a dedicated onboarding section.
This intake surface is intentionally separate from tenant login and SaaS administration. Institution contacts create prospect access first, then raise the right request for demo, enquiry, or school visit.
01
Create controlled prospect access
One institution contact record anchors rollout requests, follow-up, and subdomain allocation without mixing public traffic into tenant auth.
02
Request the right engagement path
Demo, enquiry, and school-visit workflows stay on one operational record so the rollout team can move faster with less ambiguity.
03
Promote cleanly into the tenant host
Once approved, the school is activated on its own subdomain and operational users sign in there, not through the public site.
Guided rollout desk
Secure your demo, enquiry, or school visit.
Prospects use a dedicated access flow before they request a rollout conversation. School users and SaaS admins do not sign in here.
Loading request desk...
Platform coverage
Designed for real school operations, not disconnected modules.
The platform is structured so that finance, academics, staffing, and support can operate from one tenant-aware system without sacrificing operator oversight.
School onboarding
Provision tenant workspaces, issue director credentials, and standardize rollout by school or education group.
Academic operations
Coordinate classes, terms, timetable, exams, events, and student records from one operational system.
Revenue controls
Manage fee structures, invoices, discounts, scholarships, collections, and subscription visibility with discipline.
Access governance
Use tenant-aware RBAC, SaaS-level administration, and audit evidence to reduce operational drift.
Support and escalation
Route support into the platform so operators and schools share the same operational truth.
Network-wide visibility
Run multiple institutions under one product surface without collapsing them into one unsafe data plane.
Security posture
Infrastructure choices that respect school data.
The deployment model keeps databases, Redis, backend, and frontend bound privately while host-level TLS terminates traffic at the edge. That reduces accidental exposure and keeps the public entry point narrow.
Edge policy
HTTPS + HSTS
Runtime exposure
Loopback-only internal services
Access model
Tenant and SaaS scope separation
Evidence trail
Audit-first operations
Rollout path
A cleaner onboarding sequence for each school.
01
Qualify the institution
A prospect contact creates controlled access, declares the institution profile, and opens the right onboarding track.
02
Assign the school workspace
The SaaS team validates the requested subdomain, shapes the rollout plan, and provisions the tenant cleanly.
03
Activate daily operations
Directors, principals, and secretaries move into their own workspace while the control plane stays on the admin host.
Next actions
Keep the control plane, public onboarding, and school workspaces separated.
The public site handles prospect engagement. Platform operations stay on the admin host, and each school runs on its own tenant subdomain.