До разработки бэкенда и интеграций я собрал рабочую модель на условных данных: ученики, группы, занятия, балансы, льготы, финансы, заявки и боты. Так обсуждение системы стало предметным ещё до первой строки production-кода.
Фразы «учёт учеников», «льготы» и «бот для родителей» звучат понятно, пока не начинаются детали: ребёнок ходит на два направления, часть занятия оплачивает сертификат, скидку назначили задним числом, а остаток нужно вернуть.
Кликабельная модель обнаруживает такие развилки до того, как они станут дорогими переделками базы и финансовой логики.
Прототип превращает пожелания в проверяемую предметную модель: какие сущности нужны, кто что видит, как движутся деньги, что можно отменить и какие события должен отправлять бот. После согласования техническое задание описывает уже увиденную систему, а не набор предположений.
Это не выданный за production интерфейс и не результат на реальных пользователях. Все имена и операции сгенерированы. Ценность кейса — в качестве предпроектной работы: сложная логика проверяется до оценки основной разработки.
В публичном демо используются только сгенерированные данные.
Разбор задачи и оценка — бесплатно. Напишите пару фраз о том, что съедает время сейчас: отвечу, что реально автоматизировать, и назову цену по этапам.
Написать в Telegramили сначала посмотреть цены