Kindergarten app: a modular platform with login for several kindergartens, bringing child records, staff and finances together, with access separated by role

The business problem

A kindergarten works every day with information that has to reach the right people: children's identity details, allergies and medical notes, parent contacts, contracts, group assignments, payments and expenses. Each of these has a different audience. An educator needs to know at once if a child has an allergy, management needs the overall picture, and some data has no business being seen by everyone.

Children's data is sensitive and falls under GDPR. When information has no shared home and no clear access rules, the risk grows that an important detail does not reach the person who needs it, or reaches someone who should not see it.

To work out, together with the client, a solution that brings all the kindergarten's data into one secure system, so each person on the team can work quickly with exactly the information they need.

• Sensitive child dataMedical and identity data of minors, protected under GDPR: strict access, a change history and real anonymisation on request
• Different rolesManagement sees everything, educators only their group; some modules, such as the swimming pool, are granted individually, per person
• Non-technical usersEducators using the app during the working day; no self sign-up, everything starts from an invitation
• Existing data to bring inThe kindergarten's existing records had to be brought into the system and cleaned
• Ready for multiple kindergartensEach kindergarten's data is isolated from day one, so the platform can take on more kindergartens

The solution

We started with analysis: who works in the kindergarten, what data each person touches and what they must not see. That produced a requirements document and a three-tier role model, super admin, admin and educator, with rules written once and enforced both in the interface and in the database. Together with the client we decided what was essential for the first version (children, groups, staff, settings) and what came next (attendance, finances, swimming pool), then brought the kindergarten's existing data into the system and cleaned it.

Then we built along the working day. The admin sees on the dashboard how many children are enrolled, the active groups and the latest changes. The educator marks the group's attendance: present, absent, excused, sick. On a child's profile they immediately see allergies and medical notes, plus parent contacts. The swimming coach sets their availability, and pool sessions are generated from recurring patterns. Management records payments, approves or rejects expenses, with a reason, and sees the totals.

Access is decided by the database, not just the interface. There is no public sign-up: staff join only by invitation, and an admin can only invite educators, only into their own kindergarten. The platform is modular: the swimming pool, for example, is a module granted individually, per person, not to a whole role. Several kindergartens can use the same platform, each with its own users, and each one's data is isolated from the others; the super admin creates, configures and can suspend kindergartens. Every change stays in a log, with an author and a time, and nothing is hard-deleted: children move through statuses (enrolled, withdrawn, graduated). For GDPR requests, exporting a child's data and real anonymisation are built into the system.

A few simple decisions guided the rest: birth date is the key field, and age is calculated so it never goes stale; a child's personal ID is optional, so it never blocks an enrolment.

What the client gained

The client has one place for the kindergarten's records: children, groups, staff, attendance, payments and expenses. Management sees on the dashboard how many children are enrolled, the active groups and what changed recently. Educators find a child's allergies right on the child's profile and see only their own group.

Every change has an author and a time, and children's data is protected at the database level, with export and anonymisation built in for GDPR requests. Expenses go through an approval flow, with a reason when one is rejected.

After launch, Codepedia provides 6 months of maintenance: we fix bugs and handle the unexpected situations.