We develop mobile apps for kindergartens that become the primary communication channel between teachers and parents. Photos of the day, announcements, menus, attendance tracking, meal payments—technically simple, but there is a strict requirement that defines the entire architecture: children's personal data. The key challenge is not just to create a convenient app, but to guarantee full data protection in accordance with Federal Law 152-FZ and GDPR.
For over 5 years, we have been creating solutions for educational institutions and have accumulated 20+ projects. Every development stage includes a security audit. Based on our experience, 95% of parents start using the app daily, and teachers reduce time on paper reports by 70%. According to Federal Law No. 152-FZ, processing biometric data requires separate consent, so we incorporate this into the architecture from the very beginning.
What is included in developing a mobile app for kindergarten?
A standard app includes an event feed, menu, attendance tracking, payments, and push notifications. But we adapt each solution to the specific kindergarten: number of groups, reporting requirements, integration with accounting.
How to protect children's personal data? — mobile app development
A child's photo is biometric data in terms of the face, and personal data in terms of identification. It cannot be stored without explicit parental consent. In practice, this means:
- Consent for processing — a separate form with a list of data and purpose. Not a checkbox during registration.
- Group photos are published only in a "closed" channel for parents of that specific group, not the entire kindergarten.
- The S3 bucket with photos must be private; access only via presigned URLs with a TTL of 1 hour, not via public links.
- Deletion of data upon parent request (right to erasure) is implemented at the backend level.
If these rules are ignored, the first complaint to Roskomnadzor will cause problems for the kindergarten, not the developer.
How we implement security?
We use Flutter for cross-platform development—this reduces time and cost. Firebase Security Rules ensure access only for authenticated users within their role. Firebase Authentication with phone number login (OTP) is convenient for parents: no need to remember a password. Firestore provides real-time synchronization of messages and announcements without WebSocket. Firebase Storage for photos with server-side rules—access only if request.auth.uid belongs to the child's group. Push notifications via FCM with topic subscription to a group: the teacher sends one message, all parents in the group receive the push. No need to manually iterate through tokens.
Example of Firestore Security Rules configuration
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } These rules ensure that a parent only sees posts from their group. The administrator gets a separate claim.
| Component | Technology | Purpose |
|---|---|---|
| Frontend | Flutter (Dart) | Mobile app |
| Auth | Firebase Auth (OTP) | Phone number login |
| Realtime | Firestore | Feed, messenger |
| Storage | Firebase Storage (presigned URLs) | Photos |
| Push | FCM (topic) | Notifications |
| Payments | SBP / YooKassa | Meal payments |
Functional core
Roles: kindergarten administrator, group teacher, parent. Each role sees only their own data—RBAC is mandatory.
The teacher marks attendance—simple UI, but logic is important: marking for a past date must require confirmation or be limited (cannot mark attendance "back in time" further than 3 days). Meal payment: integration with a bank via SBP or YooKassa, receipts in PDF via the pdf Flutter package or server-side generation.
The event feed is not a social network. No likes, no comments from other parents (children are not Instagram content). Only photo + text from the teacher, parent reactions (read/unread).
Timeline and budget
The development cost is calculated individually, but indicative timelines:
| Stage | Duration |
|---|---|
| MVP (attendance, feed, push, roles) | 8–12 weeks |
| MVP + payments, menu, reports | 14–18 weeks |
| Full version with analytics | from 16 weeks |
Flutter app is cheaper than native due to a single codebase, and Firebase reduces backend development time by 2 times compared to a custom server.
How to design RBAC without unnecessary complexity?
We use a nested data structure: each user (parent) is assigned a list of groupIds. The teacher has access to the groups where they are assigned. The administrator has access to all. In Firestore security rules, the check looks like this:
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } This scales to hundreds of groups without lag. For more complex scenarios (e.g., access to reports only for an accountant), we use custom claims in Firebase.
Step-by-step plan for implementing RBAC in the app
- Role analysis — determine who has access to data (administrator, teacher, parent, accountant).
- Groups design — create a
groupscollection in Firestore with an array ofmemberIds. - Authentication — set up Firebase Auth with phone number.
- Security Rules — write rules for each collection, checking
request.auth.uid in resource.data.memberIds. - Testing — verify that a teacher cannot see data from another group.
Schedule a consultation for your project—we will show you how it works in 30 minutes. Contact us for a free consultation on your project architecture. We guarantee compliance with 152-FZ and GDPR, proven by 20+ successful projects. Get a consultation—we will evaluate your project for free and suggest the optimal solution.