Kita

Kita is the platform we built for organisations that do not run one nursery but many. Enrolment, attendance, daily reports, meal plans, and photo sharing with guardians live in one system — and each centre sees only its own children, families, and staff.

The Problem: One Organisation, Many Centres

Nursery software is usually written for a single centre. An organisation with several of them ends up with one installation per centre, duplicated staff records, and no way to answer a question across the whole network. The alternative — one shared database with everything mixed together — is worse: a guardian from one centre must never be able to reach a photo of a child from another.

Kita takes the multi-tenant path. One installation, one upgrade path, one place to add a centre; and the isolation is enforced in the data layer rather than by hoping every screen remembers to filter. A centre is a tenant, and a subscription is per centre.

What We Did: Isolation Where It Belongs

Every table that holds a child, a guardian, or a daily report carries its centre, and the repositories filter by it automatically instead of trusting the caller. The method that deliberately reads across centres is named so that reading the code tells you which one you are calling — because with photographs of minors, a leak is not a bug report, it is an incident.

On top of that isolation, the day-to-day: guardians receive the daily report and the photos of their own child, staff record attendance and incidents from a phone, and the organisation gets the reporting it needs without exporting five spreadsheets.

The Result: Built for the Second Centre

Kita runs in production for an organisation operating multiple nurseries, and the architecture was chosen for the day the number grows rather than retrofitted afterwards. Adding a centre is an administrative action, not a deployment.