Как создать мобильное приложение для диеты и трекинга питания

Цели приложения и портреты пользователей

Приложение для питания ценят не за «много функций», а за понятную пользу в ежедневных ситуациях: быстро записать еду, увидеть результат и не потерять мотивацию. Поэтому начинать стоит с чётких целей и портретов пользователей — они задают требования к точности, интерфейсу и даже тону уведомлений.

Какие задачи должно решать

Обычно цели сводятся к четырём сценариям:

• Похудение: контроль дефицита калорий, привычки, «опасные» продукты, поддержка в срывах.
• Набор массы: профицит, белок, распределение приёмов пищи, удобство добавок и повторяющихся блюд.
• Поддержание веса: мягкий контроль, минимум рутины, фокус на стабильности.
• Медицинские/спортивные ограничения (по согласованию с врачом/тренером): аллергены, соль, сахар, интервальное питание.

Заранее решите, чем будет продукт: строгим трекером (точность и детализация) или лёгким дневником (минимум действий и быстрые подсказки). Компромисс возможен, но он должен быть прозрачен пользователю.

Портреты пользователей: что для них важнее

1. «Занятой новичок»: готов терпеть небольшую погрешность ради скорости. Ему критичны простой ввод, шаблоны, «как вчера».

2. «Точный энтузиаст»: требует граммов, КБЖУ, кастомных продуктов и контроля порций. Ему важны качество базы и понятные источники данных.

3. «Мотивируемый»: ведёт дневник, только если видит прогресс, получает челленджи, мягкие напоминания и объяснения «почему так».

Основные сценарии, которые должны быть без трения

• Записать приём пищи за 10–20 секунд (поиск, избранное, повторы).
• Увидеть прогресс: калории, КБЖУ, вес/замеры, тренды за неделю.
• Получить план: цель на день, ориентиры по порциям, подсказки по замене продуктов.

Как измерять успех продукта

Метрики лучше сформулировать до разработки:

• Удержание (D1/D7/D30) и доля пользователей, вернувшихся к ведению дневника.
• Дневная активность: сколько дней в неделю пользователь делает записи.
• Завершённые цели: процент дней, когда цель по калориям/белку/плану выполнена.
• «Время до первой ценности»: сколько минут до первой записи и первого понятного отчёта.

Эти ориентиры помогут не распыляться и принимать решения о функциях на основе поведения, а не предположений.

Анализ рынка и формирование УТП

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

Быстрый разбор 6 популярных решений

• MyFitnessPal: сильная сторона — огромная база и комьюнити; слабая — качество данных в пользовательских записях и часть важных функций за подпиской.
• FatSecret: плюс — простота и понятный дневник; минус — дизайн и персонализация целей часто ощущаются базовыми.
• YAZIO: плюс — хороший упор на планы/рецепты; минус — местами агрессивная монетизация и перегруз «советами».
• Lifesum: плюс — приятный интерфейс и привычки; минус — часть рекомендаций воспринимается слишком общей, без контекста.
• Cronometer: плюс — точность микронутриентов и источников; минус — для новичка может быть сложно и «сухо».
• Lose It!: плюс — мотивационные механики и цели; минус — качество локальных продуктов и рецептов зависит от региона.

За что платят — и почему уходят

Платят обычно за: удобство (сканер, быстрый ввод), персональные цели КБЖУ, планы питания/рецепты, аналитику (тренды, отчёты), синхронизацию между устройствами.

Уходят из‑за: долгого ввода еды, ошибок в базе продуктов, навязчивых уведомлений, ощущения «меня стыдят», непрозрачной подписки и слабой локализации под привычные продукты.

УТП без громких обещаний

Рабочая формула: для кого → какая ситуация → какой измеримый выигрыш → за счёт чего.

Пример: «Для людей, которые едят дома и в столовых: ввод рациона за 30 секунд благодаря локальной базе, шаблонам приёмов пищи и проверенным данным».

Must-have и nice-to-have

Must-have: дневник питания, расчёт калорий и КБЖУ, персональные цели, база продуктов с модерацией, быстрый поиск/избранное, прогресс и отчёты, экспорт/резервное копирование.

Nice-to-have: сканер штрихкодов, фото‑ввод, рецепты и меню, интеграции с часами/тренировками, рекомендации по микронутриентам, семейные профили.

Так вы получите честное позиционирование: не «самый умный трекер», а продукт, который решает конкретную боль лучше конкурентов.

MVP и дорожная карта развития

MVP — это версия, которая доказывает: людям удобно и полезно вести питание именно у вас. Цель — дать ощутимую ценность в первый день, а не «закрыть все хотелки» сразу.

Что включить в MVP (3–5 функций)

Соберите минимальный набор сценариев, который доводит пользователя до результата:

• Быстрая регистрация (почта/телефон/гостевой режим) и выбор цели (похудение/поддержание/набор).
• Добавление еды за 10–15 секунд: поиск по базе + «избранное» + копирование приёмов пищи.
• Подсчёт калорий и КБЖУ по дневным целям и простая сводка за день.
• История и базовый прогресс: календарь, вес/замеры (по желанию), отметка выполненных целей.
• Напоминания (1–2 типа): например, «добавьте завтрак» или «вода».

Если вы хотите быстро собрать кликабельный прототип и проверить путь «установка → первый заполненный день», можно использовать TakProsto.AI: это vibe‑coding платформа для российского рынка, где интерфейсы и серверную часть можно собрать через чат, а затем при необходимости экспортировать исходники.

Ограничения первой версии (это нормально)

Чтобы не расползтись по срокам, заранее зафиксируйте «не делаем в v1.0»:

• сложную аналитику, рекомендации на ML, социальные функции;
• десятки интеграций (умные весы, часы, внешние трекеры);
• распознавание еды по фото, если нет уверенности в качестве.

Лучше идеально отполировать ключевой путь: от установки до первого заполненного дня.

KPI MVP: как измерить, что продукт «взлетает»

Согласуйте метрики воронки и пороги успеха:

• регистрация → первое добавление еды (активация);
• первое добавление → заполненный день (ценность);
• 7‑дневное удержание (D7) и доля пользователей, вернувшихся 3+ раза за неделю.

Дорожная карта 1.1–2.0

Планируйте релизы через гипотезы:

• v1.1: ускорение ввода (шаблоны, избранное, улучшенный поиск), исправление онбординга.
• v1.2–1.3: штрихкоды, импорт рецептов, базовые персональные подсказки.
• v2.0: интеграции, продвинутые отчёты, умный ввод по фото — только после подтверждённого удержания.

UX/UI для дневника питания без перегруза

Хороший дневник питания ощущается как «пара быстрых касаний», а не как анкета на десять минут. Главная задача UX/UI — помочь человеку фиксировать еду регулярно, даже когда он устал, спешит или не очень мотивирован.

Онбординг: минимум шагов, максимум смысла

Онбординг лучше строить вокруг цели, а не вокруг «идеального профиля». Сначала спросите, чего человек хочет: снизить вес, набрать массу, поддерживать форму, улучшить привычки.

Дальше — только параметры, которые реально влияют на расчёты: рост, вес, возраст, уровень активности. Предпочтения (например, без мяса, аллергии, нежелательные продукты) можно собрать как «быстрые теги» и сразу объяснить, что именно они изменят.

Быстрый ввод еды: путь «в один экран»

Основной экран должен отдавать приоритет скорости:

• Недавние: то, что пользователь ел вчера и позавчера.
• Избранное: закреплённые продукты и блюда.
• Шаблоны приёмов пищи: «мой завтрак», «после тренировки», «перекус на работе» — чтобы добавлять набором.

Подтверждение порции должно быть простым: стандартные порции + возможность быстро поправить граммы/шт.

Доступность: удобно всем, не только «продвинутым»

Ставьте крупные интерактивные элементы, делайте заметный контраст, добавляйте короткие подсказки рядом с полями, а не прячьте их в справку. Ошибки ввода (например, слишком маленькая калорийность) лучше подсвечивать мягко: «Похоже на опечатку — проверить?».

Микрокопирайтинг без давления

Тон приложения влияет на удержание не меньше, чем функции. Избегайте стыда и оценок («плохая еда», «сорвался»). Лучше поддержка: «День бывает разный — давайте просто зафиксируем и пойдём дальше». Нейтральные формулировки и маленькие поощрения за регулярность работают лучше, чем моральные ярлыки.

База продуктов и качество данных

База продуктов — сердце приложения для питания: именно от неё зависит точность подсчётов и доверие пользователей. Если карточки «гуляют» по калориям и КБЖУ, любой трекер быстро превращается в генератор сомнений.

Источники базы: что выбрать и как комбинировать

Обычно используют микс из нескольких источников:

• Готовые каталоги (лицензионные базы): дают быстрый старт для MVP, но часто требуют доработки под локальные реалии.
• Партнёры (производители, ритейл, сервисы доставки): полезны для актуальных данных по брендам и штрихкодам.
• Собственное наполнение: нужно для региональных блюд, кафе, домашних рецептов и редких продуктов.

Лучше сразу определить, какие поля обязательны (энергия, Б/Ж/У, вес порции, бренд/категория), а что можно добавлять постепенно.

Нормализация: порции, граммовки, единицы

Даже хорошие источники дают данные в разном виде: «на порцию», «на 100 мл», «на упаковку». В приложении стоит привести всё к единому стандарту (обычно на 100 г/мл) и хранить исходное значение отдельно.

Критично продумать:

• конвертацию г ↔ мл там, где это возможно (а где нельзя — явно предупреждать);
• набор типовых порций («1 шт», «1 ломтик», «1 чашка») с понятными граммовками;
• округления так, чтобы они не искажали КБЖУ на малых порциях.

Качество: модерация и верификация

Система качества должна быть встроена в продукт:

• модерация новых карточек и правок (автоматические проверки + ручной контроль);
• жалобы пользователей с быстрым сценарием исправления;
• верификация популярных продуктов (топ‑1000 по употреблению) как приоритет.

Полезно хранить историю изменений и источники значений — это упрощает спорные случаи.

Локализация: региональные продукты и блюда

Дневник питания выигрывает, когда пользователь находит «свои» продукты: местные бренды, блюда столовых, традиционные рецепты. Локализация — это не только язык, но и категории, синонимы названий и разные форматы упаковок в регионах.

Расчёт калорий, КБЖУ и персональные цели

Пользователь открывает дневник питания ради простого ответа: «я сегодня в норме или нет?». Поэтому расчёты должны быть понятными и объяснимыми, без ощущения «магии».

Как считать калории и цель — простыми словами

Базовая логика может быть такой: приложение оценивает, сколько энергии человеку нужно в день (ориентируясь на рост, вес, возраст, пол и уровень активности), а затем задаёт цель в зависимости от выбранного режима. В интерфейсе важно показывать не формулы, а смысл: «это ваша поддерживающая норма», «это цель с дефицитом», «это коридор на день».

Полезная практика — отображать диапазон (например, ±5–10%), чтобы пользователь не воспринимал небольшие отклонения как провал.

КБЖУ и микроэлементы: что достаточно в базовой версии

В MVP обычно хватает:

• калорий на день и «остатка»;
• белков/жиров/углеводов (КБЖУ) в граммах и процентах;
• клетчатки и воды — как опциональные счётчики.

Микроэлементы (железо, кальций, витамины) лучше добавлять позже и аккуратно: данные по ним часто неполные, а пользователю важнее стабильная ежедневная привычка.

Гибкие цели: поддержание, дефицит/профицит и интервалы

Дайте три сценария: поддержание веса, снижение (дефицит) и набор (профицит). Дополнительно ценны интервальные цели: «в будни дефицит, в выходные поддержание» или «тренировочные дни — больше углеводов». Это снимает чувство постоянных ограничений и лучше соответствует реальной жизни.

Предупреждения и бережные подсказки

Без медицинских рекомендаций можно встроить «флажки безопасности»: если пользователь выбирает слишком большой дефицит/профицит, ставит крайне низкую калорийность, отмечает частые пропуски еды или резко меняет цель каждую неделю — показывайте нейтральное сообщение: «Если вы сомневаетесь в цели или самочувствии, обсудите план с квалифицированным специалистом». Это повышает доверие и снижает риск неправильного использования.

Планирование рациона и меню

Планирование — момент, когда дневник питания перестаёт быть «учётом прошлого» и становится инструментом, который реально экономит силы. Важно сделать план простым: пользователь должен собрать меню на день/неделю за пару минут и легко поправить его, когда планы меняются.

Конструктор меню: правила, ограничения и замены

Удобный конструктор работает как набор понятных правил, а не как сложный «мастер» с десятком экранов. Пользователь выбирает цель (например, дефицит калорий), режим питания (2–5 приёмов), а дальше приложение подсказывает варианты блюд и порций.

Полезные элементы:

• Ограничения: лимит калорий и КБЖУ на день, минимум клетчатки, максимум сахара/соли.
• Правила совместимости: например, «без молочных продуктов», «не добавлять рыбу».
• Замены ингредиентов: если в рецепте курица, то предложить индейку/тофу с пересчётом КБЖУ и веса порции.

Учёт аллергий, непереносимостей и предпочтений

Это должно задаваться один раз в профиле и автоматически применяться к поиску блюд и генерации меню. Минимальный набор: аллергены (орехи, молоко, яйца), непереносимости (лактоза, глютен), предпочтения (вегетарианство, халяль), а также «не люблю» (лук, грибы). Важно объяснять причины исключений: «скрытый аллерген в соусе» — чтобы пользователь доверял рекомендациям.

Список покупок из плана питания

После составления меню приложение собирает единый список покупок с суммированием граммов/штук, группировкой по отделам (овощи, молочное и т. д.) и возможностью отметить «есть дома». Практичная деталь — пересчёт списка при замене блюда или изменении порций.

Повторяемость: шаблоны недели и быстрые корректировки

Большинство людей питаются повторяемо — и это нормально. Дайте пользователю шаблоны («будни/выходные», «спорт‑дни», «постный день») и быстрые действия: сдвинуть ужин на завтра, заменить один приём пищи, пересчитать порции на семью или гостей — без пересборки всего плана.

Умный ввод: штрихкоды, фото и интеграции

Чем быстрее пользователь добавляет еду в дневник, тем выше шанс, что он будет вести трекинг регулярно. «Умный ввод» — это не про максимальное число функций, а про минимум шагов и понятную уверенность: что именно записалось и можно ли этому доверять.

Сканер штрихкодов: как организовать поток добавления продукта

Оптимальный сценарий — открыть сканер сразу из экрана добавления приёма пищи и после распознавания показать карточку товара: название, порция, КБЖУ на 100 г и на порцию.

Продумайте исключения: если код не найден, предложите быстрый вариант «создать продукт» с автоподстановкой названия (пользователь может ввести его голосом/текстом) и обязательными полями только для калорий и веса. Остальное — опционально. Добавьте кнопку «сообщить об ошибке в данных» прямо в карточке.

Распознавание по фото: как аккуратно описать ограничения точности

Фото‑ввод воспринимается как магия, но точность зависит от блюда, освещения и размера порции. Правильнее позиционировать функцию как «оценку» и всегда показывать уровень уверенности: например, 3–5 наиболее вероятных вариантов + предложение уточнить ингредиенты/объём.

Чтобы не разочаровать, используйте нейтральные формулировки: «мы предположили», «проверьте порцию». И обязательно оставьте ручной поиск/правку в один тап.

Интеграции с шагомерами/часами: что реально полезно и что можно отложить

На старте полезнее всего импорт шагов и активных калорий, чтобы корректировать дневную цель и показывать понятный баланс «съел/потратил». Сложные интеграции (тренировки по зонам пульса, подробная аналитика сна) часто можно отложить до этапа после MVP.

Оффлайн‑режим для дневника и синхронизация

Оффлайн нужен для базовых действий: добавить приём пищи, выбрать из избранного, внести вес порции. Храните изменения локально в очереди и синхронизируйте при появлении сети, аккуратно решая конфликты по принципу «последнее изменение + журнал правок». Пользователь должен видеть статус: «сохранено на устройстве» и «синхронизировано».

Прогресс, мотивация и уведомления

Люди возвращаются в дневник питания не из‑за «идеальных» расчётов, а потому что видят понятный прогресс и получают поддержку, а не давление. Важно продумать, как показывать изменения и как настраивать уведомления так, чтобы они помогали, а не раздражали.

Графики прогресса: что показывать и как не запутать

Сделайте прогресс визуально простым и модульным — чтобы пользователь включал только то, что ему актуально.

Хороший базовый набор:

• вес (с трендом и сглаживанием, чтобы не пугать дневными колебаниями);
• окружности (талия/бедра/грудь) и фото «до/после» по желанию;
• калории и КБЖУ по дням/неделям (с процентом попадания в цель);
• привычки: вода, овощи, шаги, сон — как чек‑лист с сериями.

Добавьте короткие пояснения прямо под графиком: «Вес может меняться из‑за воды и соли — смотрите на тренд за 2–4 недели». Это снижает тревожность и усиливает ощущение заботы.

Мотивация без токсичности

Избегайте риторики «сорвался/провал». Вместо этого используйте нейтральные формулировки: «сегодня вышло выше плана — давайте вернёмся к цели завтра».

Серии (streaks) и достижения лучше делать «мягкими»: например, серия сохраняется, если пользователь внёс хотя бы один приём пищи или отметил привычку. Полезен и режим «пауза/отпуск», чтобы серия не ломалась из‑за болезни или поездки.

Персональные уведомления и контроль пользователя

Уведомления должны быть настраиваемыми по времени, частоте и типу. Практичный подход — мастер‑настройка:

• когда напоминать (утро/обед/вечер или индивидуальное расписание);
• как часто (ежедневно, только по будням, 2–3 раза в неделю);
• что именно (внести приём пищи, выпить воду, взвешивание раз в неделю).

Дайте быстрые переключатели: «приглушить на неделю», «не напоминать вечером», «только важные». Контроль снижает отток.

Социальные функции — только по желанию

Социальность лучше делать опциональной: поделиться отдельным графиком или достижением, создать приватную группу поддержки, отправить отчёт тренеру. По умолчанию — приватность и понятные настройки видимости (кто видит, что именно и на какой срок).

Приватность, безопасность и доверие

Приложение для питания работает с очень личными привычками: что человек ест, когда, в каких количествах, как меняется вес и самочувствие. Доверие здесь — не «опция», а часть продукта. Многие решения не требуют сложного программирования: они начинаются с правильных продуктовых правил.

Минимизация данных: собирайте только необходимое

Начните с принципа «минимум для пользы». Для дневника питания чаще всего достаточно:

• цели (снижение/поддержание/набор), роста/веса и уровня активности;
• записей о продуктах и порциях;
• необязательных метрик прогресса (вес, замеры) — строго по желанию.

Не просите дату рождения, геолокацию и контакты «на всякий случай». Чем меньше вы храните, тем меньше рисков и вопросов у пользователя.

Хранение и шифрование: базовые принципы на уровне продукта

Даже на уровне MVP заложите базу: шифрование данных при передаче (HTTPS/TLS), шифрование на сервере и защищённое хранение токенов на устройстве. Ограничьте доступ внутри команды: данные пользователей должны быть доступны только тем, кому это нужно для поддержки, и только по процессу.

Экран согласий и управление данными

Сделайте отдельный экран «Данные и приватность» в настройках:

• понятные согласия на аналитику/маркетинг (по умолчанию — минимум);
• экспорт данных (например, CSV/JSON);
• удаление аккаунта и данных «в один‑два шага»;
• управление интеграциями (что подключено и какие данные передаются).

Риски: питание и здоровье как чувствительные данные

Говорите честно и простым языком: какие данные вы собираете, зачем, как долго храните и что не делаете (например, не продаёте данные третьим лицам). Если есть персональные рекомендации, добавьте дисклеймер: приложение помогает отслеживать рацион, но не заменяет врача — это снижает ожидания и повышает доверие.

Монетизация: подписка, разовые функции и этика

Монетизация в приложении для питания — это не только про доход, но и про доверие. Пользователь буквально «отдаёт» вам привычки, цели и иногда медицинские нюансы. Поэтому важно, чтобы платные механики усиливали пользу, а не создавали искусственные ограничения.

Freemium: что оставить бесплатным, а что — в подписке

Хорошая базовая версия должна закрывать ежедневную задачу: вести дневник питания, считать калории и КБЖУ, сохранять измерения и видеть простой прогресс.

Подписка логично выглядит там, где начинается «умная» ценность и экономия времени:

• Планы и планирование рациона: готовые меню, автосборка дня под цели, списки покупок.
• Расширенная аналитика: тренды по неделям/месяцам, корреляции (сон/вода/вес), цели по микроэлементам.
• Рецепты: подборки, фильтры по ограничениям, автоматический расчёт порций и КБЖУ на порцию.

Важно: не прячьте за подпиской базовые функции ввода еды и просмотра итога дня — это воспринимается как «плата за вход».

Разовые покупки: когда они уместны

Разовые покупки хорошо работают как дополнение к подписке или альтернатива для тех, кто не любит регулярные платежи:

• пакеты рецептов (например, «15 быстрых ужинов», «вегетарианская неделя»);
• персональные планы (на 7/14/30 дней) с учётом предпочтений;
• консультации специалистов — если вы реально обеспечиваете качество, квалификацию и понятные условия.

Этика здесь простая: не обещайте медицинских результатов и честно обозначайте, что это образовательная/практическая поддержка.

Реклама: где допустима и как не потерять доверие

Реклама допустима в бесплатном тарифе, если она:

• не мешает вводу еды и просмотру дневника;
• не выглядит как рекомендации «чудо‑средств»;
• легко отключается подпиской.

Нативные предложения (например, партнёрские продукты) маркируйте явно и не смешивайте с «персональными советами».

Что должно быть на странице /pricing

На /pricing лучше всего конвертируют:

• короткое сравнение тарифов «Бесплатно vs Подписка» с 5–7 пунктами;
• блок «Для кого подходит» (например, «хочу просто считать» vs «хочу план и аналитику»);
• прозрачные условия: цена в месяц/год, пробный период, отмена в один шаг;
• формулировки про ценность: «экономит 10–15 минут в день на планировании», «помогает удерживать цель» — без громких обещаний.

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

Технологии, разработка, тестирование и запуск

Технологический выбор влияет не только на скорость разработки, но и на качество данных, стабильность расчётов и стоимость поддержки. Для приложения про питание важно «не ломаться» на простых действиях: добавлении продукта, пересчёте КБЖУ и синхронизации прогресса.

Платформа: iOS, Android или кроссплатформа

Если вы уверены в одной аудитории (например, только iOS), нативная разработка упростит доступ к системным возможностям и даст максимально предсказуемый интерфейс.

Если важны скорость выхода и единая кодовая база, выбирайте кроссплатформенную разработку (часто это быстрее и дешевле на старте). Компромисс — часть «тяжёлых» модулей (камера, сканер) делать нативно, а остальное — общим слоем.

Бэкенд и аналитика: чтобы понимать, что работает

Даже MVP выигрывает от аккуратного бэкенда: учёт пользователей, сохранение дневника, синхронизация между устройствами, резервное копирование.

Параллельно настройте продуктовую аналитику: события (регистрация, добавление приёма пищи, завершение дня), воронки (от установки до первой недели), удержание, а также A/B‑тесты для онбординга, подсказок и платных офферов. Это помогает принимать решения на цифрах, а не на ощущениях.

Если нужна быстрая сборка веб‑кабинета, админки модерации базы или API для мобильного клиента, TakProsto.AI закрывает типовой стек «React + Go + PostgreSQL» и даёт практичные вещи вроде planning mode, снапшотов и отката, а также развёртывания и хостинга на серверах в России.

Тестирование: сценарии, нагрузка и проверка расчётов

Проверьте ключевые пользовательские сценарии (добавить продукт, изменить порцию, цель по калориям, офлайн‑режим). Отдельная зона риска — корректность данных и формул: округления, пересчёт порций, суммирование по дню/неделе, единицы измерения.

Нагрузочные проверки нужны хотя бы базовые: как сервис ведёт себя при росте пользователей, массовой синхронизации и импорте базы продуктов.

Запуск: бета, ASO и цикл улучшений

Запускайтесь через бета‑тест, собирайте обратную связь в приложении и планируйте улучшения короткими итерациями. Для магазинов приложений заранее подготовьте ASO: понятное название, ключевые слова, скриншоты «про пользу», а не «про функции».

Когда привлекать команду

Как только появляется риск «расползания» задач, полезны роли: продакт (приоритеты), дизайнер (простые сценарии), разработчики (клиент и сервер), QA (регресс и расчёты). Если нужно быстро оценить объём работ и собрать команду, удобно начать с консультации: /contact.