От идеи простыми словами до приложения: перевод LLM

Идея простыми словами: что считать достаточным вводом

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

На практике это особенно заметно в формате vibe-coding, где вы двигаетесь от диалога к результату итерациями. Например, в TakProsto.AI можно начать с короткого описания сценария, а затем шаг за шагом уточнять экраны, данные и ограничения — платформа будет собирать прототип web/mobile и backend вокруг вашей формулировки.

Что значит «простыми словами» в продукте

Хорошая формулировка описывает действие и результат, а не только тему. Вместо «нужно приложение для спорта» — «пользователь выбирает тренировку на 20 минут, приложение ведёт по таймеру, сохраняет прогресс и напоминает 3 раза в неделю».

Полезный ориентир: если из текста можно построить 3–5 экранов и понять, какие данные нужно хранить, — ввод уже достаточный для первого прототипа.

Пример: одна идея — два качества описания

Плохо: «Сделайте сервис доставки еды для студентов. Должно быть удобно и быстро».

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

Хорошо: «Нужен web и mobile сервис для студентов кампуса. Пользователь выбирает столовую (3 точки), видит меню на сегодня, собирает заказ, оплачивает картой, выбирает окно выдачи (15‑минутные слоты). Цель — сократить очереди. Ограничение: без доставки, только самовывоз. Админ столовой обновляет блюда и стоп-лист».

Такое описание даёт LLM опору для ролей, экранов, сущностей данных и базовых сценариев.

Что лучше указать сразу

1. Аудитория и контекст: кто пользуется и где (город, офис, кампус, домашнее использование).

2. Цель и метрика успеха: «сократить время оформления до 30 секунд», «уменьшить ошибки в заказах».

3. Ограничения: платформы (web/mobile), язык, регион, бюджет на инфраструктуру, сроки, офлайн/онлайн режим.

4. Нужно/не нужно: регистрация обязательна? уведомления? чат? интеграции?

Как убрать двусмысленности и скрытые допущения

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

И главное — прямо перечислите то, чего точно не будет в первой версии. Тогда модель не «достроит» лишнее по умолчанию, а сфокусируется на MVP.

Как LLM читают и уточняют требования

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

Как модель выделяет сущности

Из фразы «сделайте приложение для записи к мастерам» LLM обычно достаёт базовые блоки:

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

Этот «скелет» важен, потому что на нём держатся экраны, API, модель данных и тестовые сценарии.

Неявные требования: что обычно забывают

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

LLM может выявлять их через уточняющие вопросы. Хорошие вопросы выглядят так:

• «Что важнее на первом релизе: запись или оплата?»
• «Кто может менять расписание: только мастер или администратор тоже?»
• «Нужно ли подтверждение записи и за сколько времени напоминать?»
• «Какие причины отмены важны для аналитики?»

Уточнение целей и приоритетов

Чтобы требования не расплывались, полезно просить LLM фиксировать цель, метрики и границы версии 1. Например: «цель — снизить количество звонков», метрика — «доля записей онлайн», границы — «без программы лояльности и без сложных ролей». Так модель сможет предлагать решения и одновременно отбрасывать лишнее.

Риски: уверенный тон и пропуски

LLM может:

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

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

От описания к сценариям и структуре продукта

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

1) Роли и ключевые задачи пользователей

Начните с того, чтобы попросить LLM выделить роли (кто пользуется) и цели (зачем). Хороший результат — не «пользователь», а 2–5 конкретных ролей.

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

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

2) Пользовательские истории и критерии приёмки

Дальше каждую ключевую задачу превращаем в user story простым языком:

• «Как роль, я хочу действие, чтобы ценность».

И рядом — 3–6 критериев приёмки, которые можно проверить без споров. Например: «Заявка отправляется, если заполнены поля A и B», «Пользователь видит понятную ошибку, если поле B пустое», «После отправки открывается экран статуса».

3) Карта экранов и переходов

Попросите LLM составить карту экранов/страниц: список экранов + основной сценарий переходов. Полезно сразу фиксировать состояния: пустой список, загрузка, ошибка, нет доступа.

Так вы получаете скелет продукта: «Вход → Список → Карточка → Создание → Подтверждение». Это уже основа для прототипа.

4) Определение MVP: что делаем первым, что откладываем

В конце сделайте «разрез» по версиям:

• MVP: только сценарии, без которых продукт не работает.
• V1+: улучшения удобства и автоматизация.
• Позже: редкие кейсы, кастомизация, сложная аналитика.

Главный критерий: MVP должен решать одну-две задачи целиком (end-to-end), а не «чуть-чуть всё».

Прототип интерфейса для web и mobile

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

Черновой UI: навигация, компоненты, состояния

Попросите LLM разложить вашу идею на 5–9 основных экранов и нарисовать структуру переходов: «список → карточка → действие → подтверждение». Затем уточните набор компонентов на каждом экране: кнопки, поля ввода, фильтры, табы, таблицы, карточки.

Важно отдельно описать состояния, которые обычно забывают:

• пусто (нет данных), загрузка, ошибка
• нет прав/доступа
• успех и подтверждение действий
• состояние «черновик» или «не сохранено» (если актуально)

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

Особенности web: адаптивность, доступность, формы и таблицы

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

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

Особенности mobile: жесты, офлайн, пуши

Для mobile-прототипа уточните навигацию (нижняя панель, стек экранов), жесты (свайп, pull-to-refresh) и то, что должно работать без сети: просмотр последних данных, очередь действий, понятные сообщения о синхронизации.

Если нужны пуши, зафиксируйте типы уведомлений и куда ведёт тап: на экран, на конкретный объект или в центр уведомлений.

Как LLM ускоряет прототип и сбор обратной связи

Практика: сделайте 1–2 итерации «прототип → комментарии → правки». LLM может быстро:

• предложить альтернативные варианты экранов и навигации
• превратить сценарии в кликабельную карту экранов (описанием)
• подготовить вопросы для интервью и формулировки гипотез

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

Проектирование backend и модели данных

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

Если вы собираете продукт через vibe-coding, полезно заранее зафиксировать стек и договорённости по данным: это снижает количество «дрейфа» в решениях между итерациями. В TakProsto.AI типовой стек под это уже заточен (React для web, Go для backend, PostgreSQL для данных, Flutter для mobile), а дальше важнее всего качество требований и приоритетов.

Границы систем: что где происходит

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

• Клиент (web/mobile): формы, экраны, локальная валидация, офлайн‑поведение.
• API: единая точка входа, проверка прав, бизнес‑правила, работа с данными.
• Фоновые задачи: рассылки, генерация отчётов, обработка очередей, синхронизации.
• Админка: управление справочниками, модерация, ручные операции поддержки.

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

Монолит или сервисы — на уровне здравого смысла

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

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

Модель данных: сущности, связи, жизненный цикл

Начните с сущностей из сценариев: Пользователь, Проект, Задача, Комментарий, Оплата — и определите:

• Связи: «один‑ко‑многим», «многие‑ко‑многим», владельцы и участники.
• Жизненный цикл: статусы (черновик → активен → завершён), архивирование, удаление.
• История изменений: нужно ли хранить аудит, кто и когда менял данные.

Как фиксировать решения и допущения

Чтобы не потерять контекст, ведите короткую документацию: 1–2 страницы на модуль.

• Таблица «решение → причина → последствия».
• Список допущений (например: «оплаты только в одной валюте на старте»).
• Схема API на уровне ресурсов (без излишних деталей): что создаём, читаем, меняем.

Так LLM и команда работают в одном поле: меньше неявных ожиданий, меньше переделок.

Генерация кода и тестов: где ИИ реально экономит время

ИИ лучше всего ускоряет работу там, где много повторяющихся решений: типовые экраны, CRUD-операции, валидации, проклейка маршрутов, заготовки для API и тестов. Важно воспринимать результат как «черновик, который уже компилируется», а не как готовую систему.

Что реально можно поручить LLM

Обычно хорошо получается сгенерировать:

• каркас проекта: структура папок, базовая конфигурация, скрипты запуска;
• модули и типовые сущности: модели, DTO/схемы, контроллеры, репозитории;
• CRUD: список/создание/редактирование/удаление с фильтрами и пагинацией;
• UI-экраны: формы, таблицы, пустые состояния, простые навигационные сценарии;
• «склейку» между слоями: маршруты, обработчики ошибок, логирование.

Экономия времени максимальна, когда вы заранее ограничили рамки: какие сущности есть, какие поля обязательны, какие ошибки показываем пользователю.

Как задавать стиль и правила проекта

Чтобы код не превратился в «зоопарк», задайте правила до первой генерации и закрепите их в репозитории:

• линтер/форматтер и единый стиль именования;
• архитектурные ограничения (например: "UI не обращается к API напрямую, только через сервисы");
• соглашения по ошибкам и ответам API;
• шаблоны файлов (как выглядят сервис, контроллер, тест).

Практика: начните с короткого «гайда проекта» в README и просите ИИ следовать ему при каждом изменении.

Генерация тестов: где полезнее всего

Наибольшую пользу обычно дают:

• unit-тесты для бизнес-правил (валидации, расчёты, ограничения);
• интеграционные тесты для API (контракты, авторизация, ошибки);
• e2e — точечно, на критические сценарии (логин, оплата, создание заказа).

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

Как принимать изменения и не терять контроль

Сильная схема — маленькие итерации:

1. просите сделать ровно одну задачу (один эндпоинт или один экран);
2. фиксируйте критерии приёмки (что должно работать и какие ошибки допустимы);
3. запускайте линтер, сборку и тесты до мержа;
4. проверяйте дифф: ИИ должен менять только связанные файлы.

Так ИИ экономит часы на рутине, а вы сохраняете управляемость и качество кода.

Интеграции и внешние сервисы без сюрпризов

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

Типовые интеграции, которые стоит предусмотреть

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

Что обязательно описать в промпте

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

• События: какие действия пользователя или системы должны запускать интеграцию (например, «оплата успешна», «подписка продлена», «доставка отменена»).
• Вебхуки: какие входящие события ожидаем от сервиса, как проверяем подпись, что считаем идемпотентным повтором.
• Ошибки: какие коды/ситуации возможны (недостаточно средств, истёк токен, 429 rate limit) и что показываем пользователю.
• Лимиты: частота запросов, окна ретраев, дневные квоты, ограничения по размеру payload.

Контракты: договорённости API и схемы данных

Попросите LLM сформировать контракты до реализации: таблицу эндпоинтов (метод, URL, поля, статусы), схемы JSON (вход/выход), а также модель данных: какие сущности храним у себя (например, payment_intent_id, provider, status, amount, currency, last_error). Контракт — это «правило игры» для frontend, backend и внешнего провайдера.

План деградации при сбоях

Заранее опишите сценарии: сервис недоступен, вебхук не пришёл, пришёл дважды, очередь переполнена. Хороший минимум: таймауты, повторы с экспоненциальной задержкой, очередь задач, ручная сверка, режим “мы приняли запрос и обработаем позже” и понятные статусы в интерфейсе.

Безопасность и приватность при использовании LLM

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

Если вы работаете с требованиями к приватности, учитывайте и инфраструктуру инструмента. Например, TakProsto.AI рассчитан на российский контур: запуск на серверах в России, использование локализованных/opensource LLM и принцип «данные не уезжают за пределы страны» — это может быть важным ограничением уже на этапе выбора процесса разработки.

Базовые меры: аутентификация, роли, хранение секретов

Начните с фундамента приложения, а не с промптов. Если LLM помогает генерировать backend, проверьте, что в проекте предусмотрены:

• Аутентификация (лучше через проверенные библиотеки/провайдеров) и понятный жизненный цикл сессий/токенов.
• Роли и права (RBAC/ABAC): кто может видеть данные, редактировать, экспортировать.
• Секреты: ключи API, токены, пароли — только в секрет-хранилище или переменных окружения; никогда не в репозитории и не в примерах кода.

Защита данных: минимизация, шифрование, резервные копии

Сформулируйте принцип: «отправляем минимум, храним минимум». Для персональных и коммерчески чувствительных данных:

• Минимизация: в запросы к LLM передавайте обезличенные поля или агрегаты (например, “пользователь_123”, без e-mail и телефона).
• Шифрование: включите TLS в транзите; для базы — шифрование на диске и, при необходимости, на уровне полей.
• Резервные копии: автоматические бэкапы, периодические проверки восстановления, хранение копий с ограниченным доступом.

Безопасность промптов: что нельзя отправлять в модель

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

Логи и мониторинг: какие события важны для расследований

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

Итерации: правки, контроль качества и устойчивые результаты

LLM ускоряет путь от текста к продукту, но качество появляется не «с первого промпта», а через короткие циклы: сформулировали правку → получили результат → проверили → зафиксировали. Именно итерации превращают разрозненные ответы модели в предсказуемую систему.

Как превращать фидбек в конкретные правки для модели

Фидбек вроде «сделай удобнее» не исполняется. Нужны наблюдаемое поведение и критерии:

• Что было: «На экране оформления нельзя вернуться к корзине без потери введённых данных».
• Что должно стать: «Кнопка “Назад в корзину” сохраняет введённые поля и возвращает на корзину».
• Как проверить: «Заполнить поля → нажать “Назад” → увидеть заполненные значения после возврата».

Такой формат одинаково полезен и модели, и команде: он сводит «мнение» к проверяемому сценарию.

Регрессии: почему «мелкая правка» ломает другое и как это ловить

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

• критичные пользовательские сценарии оформлены как чек-лист или автотесты;
• изменения вносятся маленькими порциями;
• модель получает контекст: «не трогай X», «нельзя менять контракт API», «сохрани миграции БД».

Минимальный «сигнал тревоги» — список 5–10 ключевых проверок, которые прогоняются после каждой правки.

Подход «маленькими шагами»: короткие итерации и проверки

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

Шаблон ревью: требования → реализация → тесты → документация

Используйте единый шаблон на каждую итерацию:

1. Требование: что меняем и критерии готовности.
2. Реализация: какие файлы/модули затронуты и почему.
3. Тесты: что добавили/обновили и как запускать.
4. Документация: что поменялось в поведении, настройках, API.

Этот шаблон снижает хаос: даже если часть работы делает LLM, результат остаётся проверяемым и воспроизводимым.

Роль человека в цепочке: кто за что отвечает

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

Где ИИ ускоряет, а где нужен человек

ИИ хорош там, где требуется скорость и варианты: набросать пользовательские истории, предложить edge cases, собрать список экранов, разложить логику по модулям, сгенерировать черновики тестов или документации.

Человек обязателен там, где есть цена ошибки:

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

Роли в команде: кто за что отвечает

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

Дизайнер отвечает за пользовательский опыт: сценарии, информационную архитектуру, тексты, визуальную систему. LLM может предложить варианты, но дизайнер принимает решения и проверяет их на людях.

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

Как организовать совместную работу

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

Как давать LLM контекст продукта

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

Практический чек-лист: как начать и не утонуть в деталях

Самый быстрый способ получить пользу от LLM — не пытаться «описать всё», а собрать минимальный, но связный пакет вводных. Ниже — практический стартовый набор, который помогает превратить идею в понятный план MVP без бесконечных уточнений.

1) Шаблон промпта для старта проекта (идея → MVP → ограничения)

Скопируйте и заполните:

Ты — продуктовый аналитик и архитектор. Помоги превратить идею в спецификацию MVP.

1) Идея в 2–3 предложениях:
...

2) Для кого продукт и какая главная польза:
...

3) MVP: 3–7 ключевых функций (в порядке важности):
- ...

4) Что точно НЕ делаем в первой версии:
- ...

5) Платформы:
- web (обязательно/желательно)
- mobile (iOS/Android/оба)

6) Данные и роли:
- какие сущности храним
- роли пользователей и права

7) Интеграции:
- платежи/почта/карты/аналитика/CRM и т.д.

8) Нефункциональные требования:
- скорость, офлайн, доступность, локализация

9) Риски и ограничения:
- сроки, бюджет, юридические ограничения, приватность

Выход: список вопросов, пользовательские сценарии, список экранов, модель данных, план релиза.

2) Чек-лист материалов, которые стоит подготовить

Чтобы LLM не «додумывала» важное, заранее соберите:

• Сценарии: 5–10 шагов «пользователь → цель → результат».
• Экраны: список страниц/разделов и что на них должно быть.
• Данные: какие поля нужны, примеры записей, что является уникальным.
• Интеграции: что именно отдаём/получаем, частота, ошибки.
• Риски: приватность, модерация, финансовые операции, доступы.

3) Как оценить объём работ и собрать план релиза

Попросите LLM разложить MVP на «единицы поставки»: экран/эндпоинт/интеграция/тест. Затем:

• Отметьте зависимости (например, «оплата» зависит от «пользовательского профиля»).
• Оцените каждую единицу по шкале S/M/L и добавьте буфер 20–30%.
• Сформируйте 2–3 релиза: R1 (ядро), R2 (удобство), R3 (рост).

Если вы делаете проект в TakProsto.AI, эту декомпозицию удобно использовать как «план режима планирования» (planning mode): сначала согласовать структуру и границы версии, а уже потом переходить к генерации модулей, снимкам (snapshots) и откатам (rollback) при изменениях.

4) Где узнать больше

Про стоимость и форматы — /pricing. Больше разборов и шаблонов — /blog. Примеры решений и результатов — /examples.

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