Что на самом деле дает экспорт из Lovable?

Владеть сгенерированным кодом полезно, но это не значит, что в пятницу можно уйти с платформы, а в понедельник запустить тот же продукт в другом месте. Экспорт из Lovable может дать вам обычный репозиторий с исходным кодом. Сам по себе он не перенесет рабочую базу данных, состояние аутентификации, сохраненные файлы, секреты, домены, управление развертыванием, мониторинг и рабочие привычки, которые команда выстроила вокруг платформы.

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

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

Владение кодом и операционная независимость различаются

В документации Lovable сказано, что создателям принадлежат их проекты и сгенерированный код, а условия сервиса относят приложения, сайты и результаты работы ИИ к собственности клиента с учетом прав третьих лиц. Такая позиция по владению имеет практический смысл. Вы можете копировать, изменять и развертывать результат, не запрашивая у платформы отдельную передачу прав на каждый сгенерированный файл.

При этом те же условия оставляют за Lovable права на платформу, облако, модели, интерфейсы, инструменты и другие материалы Lovable. Для программного сервиса это нормально, однако именно здесь проходит граница, которую часто не замечают основатели. Вам принадлежит созданный системой план дома. Вам не принадлежат редактор, процесс генерации, управляемая среда выполнения, внутренние механизмы развертывания и все зависимости, которые превращают этот план в готовое здание.

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

Команды постоянно смешивают три разных утверждения:

• Юридическое владение означает, что договор не объявляет ваше приложение собственностью поставщика.
• Техническое владение копией означает, что у вас есть актуальная версия в репозитории под вашим управлением.
• Операционная переносимость означает, что эту копию можно собрать, развернуть, восстановить, защитить и обслуживать в другом месте.

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

Условия работы с подрядчиком должны дополнять условия платформы. Ваш договор с Lovable не передаст вам права, которые агентство сохранило за собой в собственном договоре. Потребуйте от подрядчика передать права на работу, созданную для проекта, раскрыть повторно использованные компоненты, перечислить сторонние лицензии, передать историю репозитория и документацию, а после приемки удалить сохраненные учетные данные и клиентскую информацию. Отдельно фиксируйте ранее созданные библиотеки, которые подрядчик предоставляет по лицензии, а не передает в собственность.

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

Административный контроль влияет и на сам экспорт. Lovable разрешает управлять подключением GitHub только пользователям с соответствующими ролями рабочего пространства, поэтому инженер с правом редактирования может не суметь создать репозиторий в аварийной ситуации. Проверьте полномочия, пока владелец учетной записи доступен. Запишите, кто может передать владение проектом, авторизовать приложение GitHub, разрешить доступ организации и отключить проект.

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

Экспорт содержит дерево исходников, а не работающую компанию

Lovable предлагает два практических способа получить код. В редакторе кода на платных тарифах можно скачать полную кодовую базу проекта в ZIP-архиве. Интеграция с GitHub создает репозиторий и поддерживает двустороннюю синхронизацию основной ветки. Согласно документации, после отключения репозиторий остается в GitHub, но изменения перестают синхронизироваться.

В типичном проекте вы увидите исходный код приложения, манифесты пакетов и файлы блокировки версий, публичные ресурсы проекта, стили и конфигурацию, файлы миграций базы данных, если проект их использует, а также исходники серверных или пограничных функций, которые хранятся в репозитории. Точное дерево зависит от времени создания приложения и выбранного бэкенда. Сейчас справка Lovable различает новые приложения на TanStack Start и старые приложения на React и Vite, поэтому не утверждайте план выхода по общей картинке чужого репозитория.

Проведите инвентаризацию реального экспорта командами, которые оставят проверяемые следы. После клонирования в пустой каталог выполните:

git ls-files > exported-files.txt
git log -1 > export-commit.txt
find . -type l -print > symbolic-links.txt

Первый файл перечислит все, что находится под контролем версий. Второй привяжет проверку к коммиту и времени. Третий обнаружит ссылки, которые могут указывать за пределы скопированного дерева. Затем проверьте сценарии пакетов, файл блокировки версий, версию среды выполнения, ссылки на переменные окружения, миграции и сгенерированные файлы. ZIP-архив без истории Git подойдет как аварийная копия, но для передачи проекта он слаб: вы потеряете авторство, историю изменений, метки и точную связь между развернутым кодом и коммитом.

У синхронизации с GitHub есть и операционные ограничения. Lovable описывает один связанный репозиторий на проект, синхронизацию основной ветки и зависимость подключения от неизменности имени, владельца, организации и расположения репозитория. Переименование или перенос репозитория может разорвать связь. В документации также сказано, что существующий внешний репозиторий нельзя просто превратить в проект Lovable. С первого дня относитесь к связанному репозиторию как к инфраструктуре компании: разместите его в организации компании, включите многофакторную аутентификацию, ограничьте доступ приложения к репозиториям, защитите основную ветку и создавайте независимое зеркало или архив по расписанию.

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

Большая часть зависимости скрыта в рабочем состоянии

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

Рабочие строки базы данных существуют отдельно от миграций схемы. Миграция может заново создать таблицы, индексы, политики и функции, но не восстановит клиентов, заказы, журналы аудита, учетные записи для входа и историю согласий. Сделайте логическую резервную копию штатными средствами базы данных, зашифруйте ее, восстановите в чистом целевом окружении и сравните число записей и поведение приложения. Для большой или активно меняющейся базы определите, как сохранить изменения между первой копией и окончательным переключением.

Объектное хранилище переносится отдельно. Изображения товаров, пользовательские загрузки, сгенерированные отчеты и метаданные вложений могут ссылаться на имена контейнеров или адреса конкретного поставщика. Скопируйте объекты, сохраните типы содержимого и правила доступа, при необходимости перепишите ссылки, затем проверьте открытое и закрытое скачивание. Резервная копия базы, которая восстанавливает метаданные файлов без самих файлов, создает продукт, выглядящий исправным до первой попытки открыть старую запись.

Секреты не должны попадать в экспорт исходников. Их отсутствие подтверждает нормальную защиту и одновременно создает требование к выходу. Составьте контролируемый реестр переменных сборки и среды выполнения, ключей подписи, секретов вебхуков, ключей шифрования, служебных учетных данных и сертификатов. Передавайте значения через хранилище секретов, а не через репозиторий. Решите, какие учетные данные можно перенести, а какие нужно заменить, поскольку к ним имели доступ платформа или ушедший подрядчик.

Перенос идентификации сложнее, чем копирование столбца с адресом электронной почты. Хеши паролей могут не экспортироваться или оказаться несовместимыми. Вход через внешние сервисы зависит от приложений OAuth, адресов перенаправления, ключей подписи и проверки со стороны поставщика. Отдельного решения требуют ключи доступа, многофакторная аутентификация, активные сеансы, коды восстановления и шаблоны писем. При безопасной миграции пользователям иногда приходится сбросить пароль или снова войти. Команды продукта и поддержки должны подготовиться к этим неудобствам, а не узнать о них во время переключения.

Домены, записи DNS, репутация почтовых отправлений, задачи по расписанию, очереди, история аналитики, журналы, оповещения, резервные копии, ограничения частоты запросов, правила сетевого экрана и защита от злоупотреблений тоже находятся вне дерева исходников. Запишите каждый элемент. Именно незаметные активы часто превращают двухдневный перенос фронтенда в шестинедельную производственную миграцию.

Выбор бэкенда определяет объем повторной сборки

Перенести почти статический фронтенд намного легче, чем управляемый бэкенд. В документации Lovable сказано, что фронтенды можно запускать в распространенных средах Node.js или на инфраструктуре для статического хостинга. Если приложение вызывает переносимые сторонние API и почти не хранит состояние, другому хостингу могут понадобиться только команда сборки, переменные окружения, правила маршрутизации и переключение собственного домена.

Приложение на Lovable Cloud или Supabase несет с собой более широкую границу сервисов. Документация Lovable по самостоятельному хостингу предупреждает: одного сервера PostgreSQL недостаточно приложениям, которые зависят от аутентификации, хранилища, обновлений в реальном времени и пограничных функций в стиле Supabase. Описанный путь самостоятельного размещения применяет миграции из supabase/migrations/, меняет адрес Supabase и публикуемый ключ, а ваша команда берет на себя резервное копирование, исправления безопасности, политики доступа на уровне строк, развертывание функций, мониторинг, масштабирование и реагирование на инциденты.

Именно здесь проходит самая важная граница зависимости в проекте. Переносимость базы данных отвечает на вопрос, можно ли переместить таблицы и строки. Переносимость сервиса отвечает на вопрос, повторяет ли целевая система все действия вокруг этих строк. Замена управляемого хранилища одним PostgreSQL не заставит работать подписанные адреса файлов. Восстановление записей пользователей не обязательно сохранит сеансы. Развертывание исходника пограничной функции не воссоздаст расписания, секреты, сетевую политику и журналы.

В документации Cloud сказано, что перенос проекта Cloud в Supabase технически возможен, но непрост, а некоторые функции Cloud недоступны вне этой среды. Отнеситесь к оговорке серьезно. Перед выбором бэкенда для рабочего продукта составьте таблицу из четырех столбцов: используемая функция, текущий поставщик, переносимая замена и проверка миграции. Включите аутентификацию, хранилище, обновления в реальном времени, функции, вызовы ИИ, электронную почту, задачи по расписанию и административный доступ.

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

Проверка выхода в чистой среде находит пробелы

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

Нормальная проверка состоит из пяти этапов:

1. Зафиксируйте экспортный коммит и запишите текущую развернутую версию.
2. Соберите проект по файлу блокировки, ограничив доступ в сеть документированными реестрами.
3. Подготовьте пустое целевое окружение из версионируемой инфраструктуры и миграций.
4. Восстановите обезличенные данные, похожие на рабочие, и характерные сохраненные файлы.
5. Проверьте вход, роли, запись, фоновые задачи, почту, доступ к файлам, откат, журналы и доставку оповещений.

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

Положите в репозиторий небольшой файл приемки, чтобы определение выхода пережило смену сотрудников:

exit_test:
  source_commit: required
  clean_build: required
  database_restore: required
  object_count_check: required
  auth_role_tests: required
  background_jobs: required
  dns_rollback_plan: required
  owner: platform-lead

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

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

Для рабочего переключения нужны параллельный период и возврат

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

Начните с переноса данных. Для редко меняющегося внутреннего приложения хватит окна обслуживания и одной окончательной резервной копии. Для клиентского продукта с постоянными изменениями сначала сделайте основную копию, затем переносите последующие изменения, пока цель не догонит источник. Механизм может использовать репликацию базы данных, журнал событий приложения или короткий запрет записи. Выберите его заранее. Две доступные для записи базы без правил разрешения конфликтов создадут расходящиеся записи, которые не исправит никакой откат DNS.

Заранее уменьшите время жизни записей DNS, если поставщик и ваши правила это допускают, но не считайте, что DNS контролирует каждого клиента. Браузеры, корпоративные преобразователи имен, мобильные сети и долго работающие процессы могут сохранять старые адреса. Оставьте старую точку входа доступной на время параллельной работы и явно определите ее поведение. Она может работать только для чтения, перенаправлять запросы или отклонять запись сообщением об обслуживании. Молчаливое принятие записей обеими сторонами опасно.

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

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

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

После переключения отзовите старые учетные данные, удалите ненужные адреса перенаправления OAuth и вебхуки, закройте лишний сетевой доступ и заархивируйте окончательный экспорт поставщика с контрольной суммой и записью о договоре. Держите старое окружение только в течение утвержденного срока хранения. Брошенная среда с рабочими данными и забытыми учетными данными не считается резервной копией, она создает неконтролируемый путь для утечки.

Назначьте одного руководителя инцидента и одного протоколиста на время изменения. Инженеры не должны потом восстанавливать хронологию по личным сообщениям. Протоколист записывает каждую команду миграции, решение, время и наблюдаемый результат. Эти записи помогают откатиться во время события и делают следующую репетицию короче и безопаснее.

Условия договора должны давать время и пригодные материалы

Договор не сделает незадокументированную систему переносимой, но уберет лишнюю неопределенность при прекращении отношений. Юрист должен адаптировать формулировки к вашей юрисдикции и масштабу сделки. Основатель все равно может найти пропущенные темы до юридической проверки.

Начните с владения и объема лицензии. В соглашении должно быть сказано, что клиенту принадлежат его входные данные, код проекта, сгенерированный результат, конфигурация приложения и данные, а ранее созданная платформа поставщика и сторонние компоненты сохраняют свой статус. Подтвердите, что право использовать экспортированный результат действует после расторжения. Спросите, кто несет риск, если сгенерированный материал вызовет претензию по интеллектуальной собственности, и сопоставьте ответ с ограничением ответственности и исключениями из возмещения убытков.

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

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

Права на данные проверяйте отдельно от владения кодом. Публичные условия Lovable дают широкую лицензию на обработку клиентских данных для работы и улучшения сервисов и описывают отказ от их будущего использования для обучения моделей и других деловых целей. Версия, обязательная для вашей компании, может зависеть от тарифа, формы заказа, региона или даты вступления в силу. Сохраните принятую версию, оформите требуемый отказ и согласуйте ограничения для конфиденциального кода и персональных данных, не предполагая, что пункт о владении автоматически регулирует обработку.

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

Наконец, защитите домен и узнаваемые клиентами атрибуты вне платформы. Используйте домен, которым управляет компания, держите доступ к регистратору и DNS в учетных записях компании и укажите судьбу любого поддомена платформы. В публичных условиях Lovable сказано, что пользователи не владеют конкретным поддоменом lovable.app и должны использовать собственный домен для приложений, важных для бизнеса. Совет на редкость прямой, и я с ним согласен.

Зависимость нужно считать как стоимость, а не как ярлык

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

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

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

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

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

Сохраняйте скорость и правдоподобный путь выхода

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

Остаться разумно, когда платформа экономит больше инженерного времени, чем ожидаемая стоимость выхода, приложение соответствует поддерживаемой архитектуре, а проверки показывают, что важные активы можно восстановить. Риск можно снизить и без ухода: синхронизируйте код с репозиторием компании, независимо архивируйте его, используйте домен компании, поддерживайте резервные копии базы и объектов, учитывайте секреты, документируйте внешние учетные записи и проводите проверку в чистой среде.

Хуже всего обнаружить границу во время сбоя, перед закрытием финансирования или в споре с поставщиком. Уже сейчас положите одностраничный реестр выхода рядом с записью об архитектурном решении. Укажите каждый актив, способ экспорта, последнюю успешную проверку восстановления, владельца и нерешенную зависимость. Обновляйте реестр, когда новая функция добавляет сервис.

Командам, которые создавали функции запросами быстрее, чем успевали их документировать, Team & AI Audit от oleg.is поможет описать приложение, пробелы в эксплуатации и инженерную работу до решения о миграции. Аудит не заменяет проверку выхода. Полезный результат аудита сокращает список предположений, которые сможет проверить ваша команда.

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