Ми розробляємо мобільні додатки для дитячих садків, які стають основним каналом зв'язку між вихователями та батьками. Фотографії дня, оголошення, меню, позначки відвідуваності, платежі за харчування — технічно це нескладно, але є жорстка вимога, яка визначає всю архітектуру: персональні дані дітей. Ключове завдання — не просто створити зручний додаток, а гарантувати повний захист даних відповідно до 152-ФЗ та GDPR.
За нашою практикою понад 5 років ми створюємо рішення для освітніх закладів і накопичили 20+ проєктів. Кожен етап розробки включає аудит безпеки. За досвідом, 95% батьків починають використовувати додаток щодня, а вихователі скорочують час на паперові звіти на 70%. Згідно з Федеральним законом № 152-ФЗ, обробка біометричних даних вимагає окремої згоди, тому ми закладаємо це в архітектуру з самого початку.
Що входить у розробку мобільного додатку для дитячого садка?
Стандартний додаток включає стрічку подій, меню, позначки відвідуваності, платежі та push-сповіщення. Але кожне рішення ми адаптуємо під конкретний садок: кількість груп, вимоги до звітів, інтеграцію з бухгалтерією.
Як захистити персональні дані дітей? — розробка мобільного додатку
Фото дитини — біометричні дані в частині обличчя, персональні дані в частині ідентифікації. Зберігати їх не можна без явної згоди батька. На практиці це означає:
- Згода на обробку — окрема форма з переліком даних і метою. Не галочка при реєстрації.
- Фотографії групи публікуються лише в «закритий» канал для батьків конкретної групи, а не всього садка.
- S3 bucket з фотографіями має бути закритим, доступ — лише через presigned URLs з TTL 1 година, не через публічні посилання.
- Видалення даних за запитом батька (право на забуття) — реалізовано на рівні backend.
Якщо проігнорувати ці правила, перша скарга до Роскомнагляду створить проблеми садку, а не розробнику.
Як ми реалізуємо безпеку?
Ми використовуємо Flutter для крос-платформної розробки — це скорочує час і вартість. Firebase Security Rules забезпечують доступ лише автентифікованим користувачам у межах їхньої ролі. Firebase Authentication з входом за номером телефону (OTP) зручний для батьків: не потрібно пам'ятати пароль. Firestore забезпечує реалтайм-синхронізацію повідомлень та оголошень без WebSocket. Firebase Storage для фото з серверними правилами — доступ лише якщо request.auth.uid належить до групи дитини. Push-сповіщення — FCM з topic-підпискою на групу: вихователь надсилає одне повідомлення, всі батьки групи отримують пуш. Без необхідності перебирати токени вручну.
Приклад налаштування Security Rules для Firestore
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } Ці правила гарантують, що батько бачить лише пости своєї групи. Адміністратор отримує окремий claim.
| Компонент | Технологія | Призначення |
|---|---|---|
| Frontend | Flutter (Dart) | Мобільний додаток |
| Auth | Firebase Auth (OTP) | Вхід за номером телефону |
| Realtime | Firestore | Стрічка, месенджер |
| Storage | Firebase Storage (presigned URLs) | Фотографії |
| Push | FCM (topic) | Сповіщення |
| Payments | СБП / ЮKassa | Оплата харчування |
Функціональне ядро
Ролі: адміністратор садка, вихователь групи, батько. Кожна роль бачить лише свої дані — RBAC обов'язковий.
Вихователь позначає відвідуваність — простий UI, але логіка важлива: позначка за минулу дату має вимагати підтвердження або бути обмеженою (не можна ставити відвідування «заднім числом» далі ніж 3 дні). Оплата харчування: інтеграція з банком через СБП або ЮKassa, квитанції в PDF через pdf пакет Flutter або серверна генерація.
Стрічка подій — це не соціальна мережа. Немає лайків, немає коментарів від інших батьків (діти — не Instagram-контент). Тільки фото + текст від вихователя, реакції батька (прочитано/не прочитано).
Строки та бюджет
Вартість розробки розраховується індивідуально, але орієнтовні строки:
| Етап | Строк |
|---|---|
| MVP (відвідуваність, стрічка, пуши, ролі) | 8–12 тижнів |
| MVP + платежі, меню, звіти | 14–18 тижнів |
| Повна версія з аналітикою | від 16 тижнів |
Flutter-додаток обходиться дешевше за нативні через одну кодову базу, а Firebase скорочує час backend-розробки в 2 рази порівняно з власним сервером.
Як спроектувати RBAC без зайвої складності?
Використовуємо вкладену структуру даних: кожному користувачу (батькові) присвоюється список groupIds. Вихователь має доступ до груп, де він призначений. Адміністратор — до всіх. У Firestore security rules перевірка виглядає так:
match /groups/{groupId}/posts/{postId} { allow read: if request.auth.uid in resource.data.memberIds; } Це масштабується до сотень груп без лагу. Для складніших сценаріїв (наприклад, доступ до звітів лише бухгалтеру) використовуємо кастомні claims у Firebase.
Покроковий план впровадження RBAC у додатку
- Аналіз ролей — визначте, хто має доступ до даних (адміністратор, вихователь, батько, бухгалтер).
- Проектування groups — у Firestore створюємо колекцію groups з масивом memberIds.
- Аутентифікація — налаштуйте Firebase Auth з номером телефону.
- Security Rules — пишіть правила для кожної колекції, перевіряючи
request.auth.uid in resource.data.memberIds. - Тестування — перевірте, що вихователь не бачить дані чужої групи.
Замовте консультацію по вашому проєкту — ми покажемо, як це працює за 30 хвилин. Зв'яжіться з нами для безкоштовної консультації з архітектури вашого проєкту. Ми гарантуємо дотримання 152-ФЗ та GDPR, досвід підтверджено 20+ успішними проєктами. Отримайте консультацію — оцінимо проєкт безкоштовно та запропонуємо оптимальне рішення.