Branch-scoped roles
Directors, principals, coordinators and accounts staff each see one slice of the same data. Permissions follow the campus, not the person, so transfers take a minute.
Division 01 — Product engineering
Software that survivesthe second campus.
One control room for institutions that run more than one campus — enrolment, attendance, fees and results reconciled across every branch instead of once per branch.
The situation
Multi-campus institutions usually end up with one spreadsheet per campus and a phone call to reconcile them. Fee defaulters hide in the gap between branches, timetables clash across shared faculty, and head office sees last month rather than this morning.
The approach
MultiCampusConnect keeps every campus in one schema with branch-scoped permissions on top. A branch administrator sees only their campus. The director sees all of them side by side, using the same numbers, updated as they are entered.
Fig. 01 — data model
One ledger, many campuses
The design decision that matters is boring and structural: campuses are rows, not copies. Reports roll up because there is nothing to reconcile, and a student who transfers keeps one record instead of gaining a second one.
- Stack
- React, TypeScript, Postgres
- Hosting
- Netlify, edge-cached
- Auth model
- Role and campus scoped
- Data export
- CSV and JSON, on demand
- Handover
- Source included on milestone close
- Support
- Same team that wrote it
Inside MultiCampusConnect
Six modules in production
Enrolment that survives transfer
A student moving between campuses keeps one record — history, fee ledger and results travel with them instead of being retyped.
Fee ledger with ageing
Invoices, partial payments, concessions and arrears per student, rolled up per campus. Ageing buckets show who is 30, 60 and 90 days late without anyone building a report.
Attendance from any device
Teachers mark on a phone in the classroom. Late arrivals reconcile against the same register rather than a second sheet.
Timetable clash detection
Shared faculty and shared labs are checked across campuses before a timetable is published, so the clash is found on screen instead of on Monday.
Results and transcripts
Assessment weightings per programme, grade computation, and printable transcripts that match your existing template.
What we take on
01
MultiCampusConnect deployment
Discovery, data import from your existing sheets, staff training on site, then a supported first term.
Fixed price per campus, milestones agreed up front
02
Custom web applications
Line-of-business software built the same way we build our own product — schema first, no throwaway prototypes handed over as production.
Per milestone, source included
03
Integration & migration
Moving records off spreadsheets, connecting biometric attendance devices, wiring payment gateways and SMS or WhatsApp notification.
Scoped per system, quoted after a short audit
How an engagement actually runs
Step One
Audit
Two days with your registrar and accounts staff, looking at what already works. Nothing is proposed before that.
Step Two
Schema
The data model is agreed and written down before any interface is designed, because that is the part which is expensive to change later.
Step Three
Build in the open
A deploy preview goes up every working day. You watch the software arrive rather than waiting for a reveal.
Step Four
Handover
Training, documentation and the source repository. You are free to leave, which is the point.
Bring us the spreadsheetsyou are tired of.
Two days of audit, then a written scope with a fixed price per campus. If MultiCampusConnect is the wrong fit, we will say so in that document.