Как сделать резервную копию приложения, созданного с ИИ,

Один основатель, с которым я общаюсь, ведёт весь свой бизнес по бронированию — три точки, около 200 клиентов в неделю — через приложение, которое он сам собрал в ИИ-конструкторе приложений. Он показал мне его во вторник и очень им гордился. А в среду он спросил меня, слегка нервничая: «Если эта штука сломается, я что, просто… всё потеряю?»

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

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

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

Что на самом деле внутри вашего приложения на ИИ (и что может исчезнуть)

Приложение, созданное с ИИ, состоит из двух очень разных вещей, и каждую из них нужно копировать по-своему.

Первое — само приложение: экраны, логика, дизайн, интеграции. Это то, что сгенерировал для вас ИИ-конструктор. Оно живёт в аккаунте вашего конструктора, обычно внутри проекта. Если вы потеряете доступ к этому аккаунту, или у конструктора случится сбой, или проект повредится — вы потеряете именно это.

Второе — ваши данные: пользователи, заказы, сообщения, бронирования, загруженные людьми файлы. Обычно они хранятся в какой-то базе данных. Иногда — внутри самого ИИ-конструктора. Иногда — в сервисе вроде Supabase, Firebase или Airtable. Иногда они разбросаны по нескольким местам.

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

Удобный способ это представить: если бы здание сгорело, то приложение — это чертёж, а данные — то, что было внутри здания в момент пожара. По чертежу можно отстроить заново. А то, что было внутри, уже не вернуть.

Что под угрозой: четыре сценария, которые реально случаются

Каждый из этих сценариев я видел у людей, которые собирали приложения в ИИ-конструкторах. Ни один из них не теоретический.

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

2. У ИИ-конструктора сбой или проблема с данными. Редко, но бывает. В 2024 году у одной популярной no-code-платформы был 6-часовой сбой, во время которого данные клиентов были недоступны. Никто не потерял данные навсегда, но многие бизнесы потеряли целый день. Если ваше приложение для бронирования лежит в субботу утром, когда клиенты пытаются забронировать на субботний вечер, — это не «данные не потеряны», это упущенная выручка, которую вы уже не вернёте.

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

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

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

Что копировать и как часто

Вам не нужна навороченная система. Вам нужна привычка. Вот тот минимум, который я рекомендую человеку, собирающему приложения с ИИ без кода.

Ваши данные — каждый день, по возможности автоматически.

Если данные живут в чём-то вроде Supabase или Airtable, оба сервиса предлагают плановый экспорт или резервные копии. Включите это. Большинство пропускают этот шаг, потому что это три клика, и они думают, что сделают позже. Сделайте это в день запуска.

Если данные живут внутри самого ИИ-конструктора и автоматического экспорта нет, поставьте напоминание в календаре на каждое воскресенье — вручную их экспортировать. Выгружайте по CSV на каждую таблицу. Сохраняйте куда-то вне конструктора — Google Drive, Dropbox, внешний жёсткий диск. Куда угодно, кроме того же сервиса.

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

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

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

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

Ваши аккаунты и доступы — один раз, в день запуска.

Запишите в одном месте, где что находится. В каком аккаунте конструктора лежит приложение. В каком сервисе базы данных лежат данные. Какая почта — это вход администратора. Какой платёжный сервис подключён. Какие интеграции подключены.

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

Ваши файлы — туда, куда загружают ваши пользователи.

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

Простая рутина резервного копирования примерно на 20 минут в неделю

Воскресным вечером, когда вы и так уже не работаете:

Откройте ИИ-конструктор. Сделайте именованный снимок текущего состояния приложения. Поставьте дату.
Выгрузите каждую таблицу данных в CSV. Сложите их в датированную папку в облачном хранилище. (Большинство данных живёт в 3–10 таблицах — это не огромная работа.)
Загляните в хранилище файлов. Убедитесь, что не происходит ничего странного (число файлов взрывообразно растёт, подозрительные загрузки).
Обновите документ «где что находится», если за неделю что-то изменилось.

Вот и всё. Двадцать минут, раз в неделю. Это до нелепости щедрая страховка по сравнению с тем, что она защищает.

Если не хотите делать это вручную, посмотрите, не живут ли ваши данные где-то с встроенным резервированием. Supabase, например, может делать за вас автоматические ежедневные копии. На бесплатном тарифе они ограничены; на платном — хранятся дольше. Для бизнеса, который зависит от приложения, этот платный тариф — самая дешёвая страховка из всех, что вы когда-либо купите.

Что делать, когда что-то пошло не так

Если приложение сломалось из-за бага ИИ-конструктора или неудачного изменения:

Не паникуйте и не строчите промпты. Инстинкт подскажет немедленно попросить ИИ всё починить. Сдержитесь на десять минут. Паническая правка не в ту сторону может сделать только хуже, и большинство конструкторов не дадут легко откатить цепочку промптов.
Откатитесь к последнему снимку. Если он у вас есть. Ради этого вы его и делали.
Если снимка нет, попросите ИИ-конструктор отменить последнее конкретное изменение. Будьте точны. «Отмени изменение, где мы убрали страницу регистрации» — лучше, чем «сделай, чтобы снова работало».

Если данные повредились:

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

Если вы потеряли доступ к аккаунту:

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

То, чего основателю никто не сказал

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

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

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

Если вы собрали что-то настоящее — сделайте снимок сегодня.