Розробка EdTech застосунку: де ламається навчання
Учень проходить урок у метро, закриває застосунок — і наступного дня починає тему заново. Це не рідкість, а системна проблема навчальних застосунків: прогрес зберігається локально, а на сервер іде лише при виході, і будь-який обрив зв'язку стирає півгодини роботи. Ціна такої помилки — не баг у звіті, а втрачений учень, який більше не повернеться до курсу.
Розробка EdTech застосунку впирається в три вузькі місця, які майже не видно на демо, але проявляються на живій аудиторії. Перше — синхронізація прогресу: без журналу подій і повторного надсилання при конфлікті версій пристрій і сервер розходяться в тому, який урок пройдено.
Друге — офлайн-доступ до уроків: якщо контент не кешований заздалегідь, учень у поїзді бачить порожній екран замість матеріалу. Третє — стабільність відеоплеєра: на мобільних мережах потік рветься, буфер не встигає, і лекція зависає на середині.
Кожен збій б'є по утриманню напряму. Розсинхрон прогресу знецінює працю учня, відвали на слабкому інтернеті відсікають цілі регіони з нестабільним покриттям, а зависле відео ламає довіру до платформи швидше, ніж будь-яка помилка в інтерфейсі.
Розбираємо, як це закривається на рівні архітектури: журнал прогресу з ідемпотентним надсиланням, передзавантаження уроків під офлайн і адаптивний плеєр, який підлаштовує якість під канал замість очікування ідеальної мережі.
Що дає правильна архітектура EdTech застосунку
Офлайн-режим і синхронізація даних
Учень відкриває урок у метро або в літаку — без мережі. Якщо застосунок уміє працювати офлайн, контент і прогрес зберігаються локально, а при появі зв'язку йдуть на сервер. Ключове питання — розв'язання конфліктів: що робити, якщо прогрес змінювався на двох пристроях.
Ми використовуємо версіонування записів і правило «остання зміна перемагає» з журналом операцій — синхронізація не втрачає відповіді й не перетирає прогрес. Частка перерваних сесій падає в рази: учень не втрачає пройдене при обриві зв'язку.
Відеоуроки на мобільних
Відео — найважчий контент. Ми віддаємо його через адаптивний стримінг з кількома якостями й кешем на пристрої: перший кадр з'являється за секунди навіть на слабкому каналі, повторний перегляд іде з локального кешу без звернення до сервера.
Це знижує навантаження на сервер і вартість трафіку — при пікових навантаженнях інфраструктура не деградує.
Навантаження на сервер
Пікове навантаження в EdTech передбачуване: вечірні години й старт потоку. Ми виносимо важкі операції — генерацію звітів, розсилку, перерахунок прогресу — у фонові задачі, а статику й відео віддаємо через CDN. Сервер тримає пік без ручного масштабування, клас відмов «сервіс недоступний у годину пік» зникає.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативний застосунок | Складний офлайн, відео, push | Дорожче в підтримці двох платформ |
| Кросплатформна розробка | Єдина кодова база, швидкий старт | Тонка робота із залізом обмежена |
| Веб-застосунок (PWA) | Швидкий запуск, мінімум встановлень | Слабкий офлайн, обмежений доступ до пристрою |
Вибір фіксується на етапі проєктування — переробка архітектури після запуску коштує дорожче, ніж закласти офлайн і синхронізацію одразу. Ми спираємося на перевірені рішення, наприклад Firebase, для синхронізації та push-повідомлень.
Опишіть задачу — повернемося з оцінкою та планом щодо архітектури.
Як ми вибудовуємо процес розробки EdTech продукту
Розробка edtech застосунку рідко стартує з нуля: частіше є сайт з курсами, лендінг, розрізнені таблиці або legacy-застосунок, який учні закинули після другого уроку.
Завдання інженера — не «зробити застосунок», а зібрати систему, де прогрес учня не губиться між пристроями, а контент оновлюється без релізу в сторах.
Тому процес будуємо навколо аудиту поточного рішення та вимірюваних метрик: частка завершених уроків, повернення на другий день, час до першого уроку.
- Аудит навчальної платформи. Розбираємо поточний продукт: як зберігається прогрес, де обривається воронка «реєстрація → перший урок → оплата», які сценарії ламаються за слабкої мережі. На виході — карта вузьких місць і список гіпотез, які перевіряємо до написання коду.
- Прототипування. Збираємо клікабельний прототип ключових сценаріїв: урок, тест, повернення до незавершеного заняття, офлайн-режим. Це дешевше за правки в готовому застосунку: спірні місця в навігації видно до розробки.
- Проєктування даних та інтеграцій. Визначаємо, як застосунок спілкується з LMS, платіжним контуром і відеосховищем, як синхронізується прогрес під час перемикання між телефоном і планшетом.
- Розробка ітераціями. Кожні два тижні — робоча збірка з новою функцією, а не звіт. Пріоритет віддаємо сценаріям, що впливають на утримання, а не другорядному оформленню.
- Тестування на пристроях. Прогоняємо сценарії на реальному парку телефонів і планшетів, включно зі слабкою мережею, перериванням дзвінком, зміною часового поясу. Окремо перевіряємо коректність прогресу після збою.
- Передача проєкту. Віддаємо вихідні коди, схеми даних, інструкції зі збірки та релізу, доступи до магазинів застосунків. Команда замовника може розвивати продукт самостійно.
- Підтримка та розвиток. Стежимо за падіннями, метриками утримання та оновленнями платформ, плануємо наступний цикл функцій за фактичними даними.
Опишіть вашу платформу та поточні вузькі місця — повернемося з оцінкою та планом етапів.
Чим відрізняється нативний застосунок від кросплатформного?
Нативна розробка — це окремий код під кожну платформу: Kotlin і Swift, прямий доступ до системних інтерфейсів, повний контроль над відтворенням кадрів і роботою з пам'яттю.
Кросплатформна розробка — спільна кодова база, з якої збираються обидві версії застосунку; системні виклики йдуть через проміжний шар.
Різниця проявляється не в «красі», а в тому, де саме застосунок упирається в межу: в анімаціях, фоновому завантаженні, роботі з камерою, пуш-повідомленнях, офлайн-сховищі.
Для розробки edtech застосунку вибір технології визначається сценаріями навчання.
Якщо всередині відеоуроки із синхронними субтитрами, інтерактивні тренажери, запис відповідей на камеру, офлайн-доступ до матеріалів і фонова синхронізація прогресу — нативна розробка дає передбачувану продуктивність застосунку й менше «дивних» відмов на слабких пристроях.
Якщо продукт — це каталог курсів, особистий кабінет, тести, чат із викладачем і оплата, кросплатформна розробка закриває завдання однією командою і помітно швидше виходить на ринок.
Ключова асиметрія — у підтримці. Нативний проєкт потребує двох компетенцій і двох релізних циклів: правка в одному місці не переноситься в друге.
Кросплатформний проєкт тримає логіку в одному місці, але при оновленні платформ або сторонніх бібліотек з'являється залежність від того, наскільки швидко проміжний шар підтримує нововведення.
На практиці це виглядає так: кросплатформа економить на старті й на рутинних доопрацюваннях, нативний код економить на розборі складних дефектів і на важких функціях.
Тому вибір технології — не релігія, а розрахунок під конкретний продукт. Ми дивимося на три речі: які функції критичні для утримання учнів, як часто плануються релізи, і чи є в команді замовника ресурс на дві платформи.
Часто виграє гібрид: оболонка й типові екрани — на кросплатформі, важкі модулі (відео, розпізнавання, офлайн-движок) — нативно.
Такий варіант дає швидкість розробки й не заганяє продуктивність застосунку в стелю, а бюджет розробки розподіляється туди, де він реально впливає на навчання.
Кейс: як ми знизили відвали на 40% у застосунку для навчання
Клієнт прийшов із класичною для edtech картиною: застосунок встановило багато користувачів, але до кінця курсу доходив приблизно кожен п'ятий.
Аналітика показувала, що люди йдуть не на складному матеріалі, а на вході в урок — плеєр підвантажував відео повністю, і на мобільній мережі старт займав до 12 секунд. За цей час користувач встигав закрити застосунок і не повертався.
Ми розібрали шлях до першої лекції по кроках і переписали завантаження: перейшли на потокову передачу з адаптивною якістю, винесли стартовий фрагмент попереду решти відео й додали передзавантаження наступного уроку, поки користувач дивиться поточний.
Паралельно переробили прогрес: замість абстрактного «урок переглянуто» почали фіксувати частку переглянутого й повертати користувача рівно на ту секунду, де він зупинився, — на будь-якому пристрої.
Що змінилося в метриках
| Метрика | До | Після |
|---|---|---|
| Час до старту уроку | до 12 секунд | 1-2 секунди |
| Утримання на 7-й день | 24% | 38% |
| Завершуваність курсу | 21% | 34% |
| Відвали на першому уроці | 46% | 27% |
Окремо зайнялися поверненням: налаштували нагадування за розкладом самого користувача, а не за фіксованим часом розсилки, і пов'язали їх із незакритим уроком. Це дало ще частину утримання без жодної зміни в контенті курсу.
Чому це спрацювало
Ми не чіпали методику й не переписували уроки — уся робота йшла на стороні доставки контенту та збереження прогресу. Ключовим виявилося те, що прогрес синхронізується між пристроями: користувач починає на телефоні в транспорті й продовжує вдома з планшета, не втрачаючи місце. Для онлайн-навчання це прямо конвертується в завершуваність курсів.
Стек тут вторинний — важливою була дисципліна вимірювань: до правок ми зняли базові метрики навчання по кожному кроці воронки, після — порівнювали на тій самій вибірці.
Інструменти аналітики та збірки під iOS і Android підбирали під задачу, орієнтуючись на Firebase як єдину точку по подіях і падіннях.
Сумніви перед стартом: сумісність, міграція, доступи
Перед стартом розробки edtech застосунку замовник зазвичай тримає в голові три технічні ризики: як нова система уживеться з поточною LMS, що буде з уже накопиченими курсами та прогресом учнів, і як забезпечити доступи без дір у безпеці.
Ці побоювання обґрунтовані — навчальна платформа живе роками, і невдала міграція означає втрачені записи про прогрес і зламані інтеграції.
Що якщо після релізу доведеться відкочувати зміни?
Відкат проєктуємо заздалегідь: збірки версіонуються, конфігурація зберігається окремо від коду, схема даних змінюється лише зворотно сумісними кроками. Повернення до попередньої версії займає хвилини, а не години ручного редагування — без втрати користувацьких даних.
Що якщо у нас своя LMS? Сумісність закриваємо через стандартні формати обміну навчальним контентом і прогресом, а не через прив'язку до одного постачальника. Якщо у платформи є програмний інтерфейс — інтегруємося напряму, якщо ні — будуємо проміжний шар синхронізації.
Що з доступами та безпекою? Ролі розмежовуємо за принципом мінімально необхідних прав: учень, викладач, адміністратор і методист бачать рівно свої дані. Токени доступу короткоживучі, дії з оцінками та платежами пишуться в незмінний журнал.
Що якщо міграція затягнеться? Переносимо поетапно: спочатку довідники та каталог курсів, потім користувачі та прогрес, наприкінці — історія платежів. Кожен етап перевіряється звіркою контрольних сум, тому розбіжності видно одразу, а не через місяць експлуатації.
Після завершення робіт ви отримуєте на руки:
- Схему інтеграції з поточною LMS та опис форматів обміну даними
- Політики ролей і розмежування доступів у вигляді конфігурації
- Регламент міграції навчальної платформи з планом відкату
- Опис процедури повернення до попередньої версії та точок відновлення
- Документацію проєкту: архітектуру, схему даних, інструкції для адміністраторів
- Набір автоматичних перевірок ключових сценаріїв навчання
Опишіть вашу поточну платформу та обмеження — повернемося з оцінкою сумісності та планом міграції під ваш випадок.
Терміни впровадження EdTech-додатку за етапами
Терміни в EdTech-проєкті визначає не обсяг екранів, а кількість інтеграцій і глибина освітньої логіки. Додаток, який просто показує відеоуроки, і платформа з перевіркою завдань, прогресом за модулями та синхронізацією між пристроями — це різна тривалість розробки. Нижче — етапи впровадження з орієнтовними термінами, які ми уточнюємо після розбору вимог.
Етапи йдуть із частковим перекриттям: дизайн ключових екранів стартує, поки аналітика ще уточнює другорядні сценарії, а інтеграції підключаються паралельно розробці ядра. Такий план проєкту скорочує загальний термін запуску додатку на кілька тижнів без втрати якості.
Тривалість розробки найбільше зростає від нестандартної логіки — наприклад, якщо потрібні живі заняття з розкладом, перевірка відкритих завдань викладачем або складна система доступу до платного контенту. Такі блоки ми оцінюємо окремо і закладаємо в план до початку робіт.
Flutter дозволяє зібрати додаток під обидві платформи з однієї кодової бази — це помітно скорочує терміни та спрощує підтримку, коли потрібно випускати оновлення для учнів на різних пристроях.
