Иван

Понял, дальше не отвлекаю. Если на этапе монетизации или публикации всплывут нюансы - буду рад помочь.

Если хотите, могу в личке коротко накидать чек-лист, что я обычно проверяю в таких случаях

А вы embeddings для сопоставления ингредиентов и товаров не пробовали?

Кстати, если пойдете дальше, я бы рассматривал RuStore как промежуточный вариант перед Google Play.
Аудитория там, конечно, не такая большая, как в Google Play, но зато для российского разработчика понятнее контур монетизации.
Правда, я бы сначала проверил готовность к отдельным flavor-сборкам.
Если интересно, могу бесплатно посмотреть текущую реализацию именно с этой стороны и накидать короткий список: что стоит поправить перед выходом в RuStore / GP.

И Яндекс.Метрика, кстати, тоже должна быть нормально оформлена: cookie-баннер, политика и согласие на обработку данных метрическими программами.

Персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу, то есть субъекту персональных данных.

По смыслу 152-ФЗ Telegram ID + рост + вес + рацион + история питания - это уже ПДн, потому что этот набор относится к определяемому пользователю Telegram.

Меня бы здесь больше всего беспокоила не активация, а ПДн-контур.

Внешние AI-провайдеры - это не просто бот считает калории. Пользователь легко может отправить чувствительные данные.

Если часть этого уходит в Claude или Whisper - это минимум вопрос уведомления РКН, согласий и корректного описания обработки.

Здравтсвуйте, а у вас в конструкторе есть готовый блок согласия под 152-ФЗ?

Не просто добавить обязательный чекбокс, а именно нормальный шаблон: чекбокс согласия на обработку ПДн, ссылка на политику, ссылка на согласие, запрет отправки без галочки и отдельно согласие на рассылки, если форма потом используется для маркетинга.

Для российского form builder это может быть одним из главных продуктовых аргументов. Особенно если вы сами в статье пишете, что зарубежные формы упёрлись в ПДн и российские серверы.

Дмитрий, хорошо, что быстро поймали и закрыли.

Единственный момент: если 5432 какое-то время реально торчал в интернет, я бы не ограничивался только закрытием порта. Такие порты интернет-сканеры находят за считанные минуты, а дальше обычно начинается брутфорс.

Если доступ к БД успели получить, это может закончиться неприятными вещами: бэкдор-пользователь, майнер, cron/systemd-персистентность, изменённые секреты или следы в контейнерах/образах.

Я бы на всякий случай проверил логи postgresql, список ролей, подозрительные подключения, пользователей на сервере, cron, systemd, контейнеры/образы и после этого ротировал пароли/секреты.

Удалось уже посмотреть, были ли успешные подключения к postgresql снаружи?

За статью спасибо, но по технической части есть пара мелких технических уточнений.

По поводу уведомлений в точное время - загуглите Don't Kill My App. Дело не только во Flutter-библиотеке: там разрешения, версия Android, батарея, ограничения производителя и т.д.

И ещё у вас в примере CustomPainter не соберётся: не хватает shouldRepaint.

И бюджет разработки я бы всё-таки считал не так. На текущий момент: (250 часов * 300 руб) + 1000 руб = примерно 76 тыс., если брать совсем минимальную почасовую оплату по МРОТ при неполном рабочем дне - 300 рублей за час.