Як зробити резервну копію свого застосунку на ШІ — і навіщо вона вам справді потрібна

Один засновник, з яким я спілкуюся, веде весь свій бізнес із бронювання — три локації, близько 200 клієнтів на тиждень — на застосунку, який він зібрав сам за допомогою конструктора застосунків на ШІ. Він показав мені його у вівторок і дуже ним пишався. У середу він запитав мене, трохи нервово: «Якщо ця штука зламається, я просто… втрачу все?»

Чесна відповідь була: можливо. Залежить, що ви маєте на увазі під «зламається». Залежить, яку резервну копію він мав (він не мав жодної). Залежить, чи зміг би він відтворити її вчасно.

Ця розмова — найпоширеніша з тих, що я веду з людьми, які зібрали застосунок зі ШІ. Сама побудова відчувається як маленьке диво. Питання «що станеться, якщо воно зникне» майже ніколи не виринає, доки застосунок уже не робить реальної роботи — а на той час наслідки його втрати стали серйозними.

Цей допис — для кожного, хто зібрав справжній, робочий застосунок, не кодуючи його сам, і тепер покладається на нього в чомусь важливому. Ми розглянемо, що насправді під ризиком, що зберігати, як часто і що робити, коли щось іде не так. Це не технічно. Жодних скриптів запускати. Мета — переконатися, що хай би що ви зібрали, ви не втратите його лише тому, що ніхто не сказав вам, що резервні копії існують.

Що насправді всередині вашого застосунку на ШІ (і що може зникнути)

Застосунок на ШІ складається з двох дуже різних речей, і кожну з них треба резервувати по-різному.

Перша — сам застосунок: екрани, логіка, дизайн, інтеграції. Це те, що згенерував для вас ваш конструктор на ШІ. Воно живе в акаунті вашого конструктора, зазвичай усередині проєкту. Якщо ви втратите доступ до цього акаунту, чи в конструктора буде збій, чи проєкт пошкодиться, ви це втратите.

Друга — ваші дані: користувачі, замовлення, повідомлення, бронювання, файли, які люди завантажили. Це зазвичай живе в базі даних десь. Іноді — всередині конструктора на ШІ. Іноді — в сервісі на кшталт Supabase, Firebase чи Airtable. Іноді розкидане по кількох місцях.

Ці дві речі мають цілком різні профілі ризику. Структура застосунку змінюється, коли ви просите ШІ її змінити. Ваші дані змінюються щоразу, коли користувач щось робить. Тож їм потрібні різні стратегії резервування.

Корисний спосіб про це думати: якби будівля згоріла, застосунок — це креслення, а дані — це те, що було всередині будівлі, коли вона горіла. Із креслення можна відбудувати. Те, що було всередині, не повернути.

Що під ризиком: чотири сценарії, що справді трапляються

Я бачив, як кожен із них стається з людьми, що будують із конструкторами застосунків на ШІ. Жоден із них не теоретичний.

1. Ви випадково кажете ШІ зламати застосунок. Ви втомлені, працюєте опівночі й кажете «прибери сторінку реєстрації користувачів», бо хочете її переробити. ШІ це робить. Він також прибирає частину застосунку, що дає змогу наявним користувачам входити. Тепер ніхто не може користуватися застосунком, а остання робоча версія ШІ зникла, якщо у вас не ввімкнена історія версій (у багатьох конструкторів вона за замовчуванням не ввімкнена).

2. У конструктора на ШІ збій чи проблема з даними. Рідко, але реально. У 2024 році популярна no-code-платформа мала 6-годинний збій, коли дані клієнтів були недоступні. Ніхто не втратив дані назавжди, але багато бізнесів втратили день. Якщо ваш застосунок для бронювання лежить у суботу зранку, коли клієнти намагаються забронювати на суботу пообід, це не «жодної втрати даних» — це втрачений дохід, який ви не повернете.

3. Ваш акаунт блокують. Можливо, проблема з оплатою, можливо, позначений вхід із нової локації, можливо, зміна e-mail, що не поширилася. Застосунок у порядку, дані в порядку, але ви не можете в нього потрапити. Якщо у вас немає експортованої копії, ви на милості термінів відповіді підтримки.

4. Ви залишаєте платформу. Ось чого люди не планують. За рік ви можете захотіти перейти на інший інструмент чи найняти розробника, щоб перебрати те, що ви зібрали. Якщо єдина копія вашого застосунку й даних живе всередині одного конструктора, ваші варіанти вузькі й дорогі.

У кожному з цих сценаріїв різниця між «дратівливо» і «катастрофічно» — у тому, чи була у вас резервна копія.

Що резервувати і як часто

Вам не потрібна вигадлива система. Вам потрібна звичка. Ось мінімум, який я раджу тому, хто будує зі ШІ без написання коду.

Ваші дані — щодня, автоматично, якщо можливо.

Якщо ваші дані живуть у чомусь на кшталт Supabase чи Airtable, обидва пропонують заплановані експорти чи резервні копії. Увімкніть це. Більшість людей пропускає, бо це три кліки, і вони вирішують зробити це пізніше. Зробіть це того дня, коли запускаєтеся.

Якщо ваші дані живуть усередині самого конструктора на ШІ й автоматичного експорту немає, поставте нагадування в календарі щонеділі вручну їх експортувати. Експортуйте як CSV для кожної таблиці. Зберігайте десь поза конструктором — Google Drive, Dropbox, зовнішній жорсткий диск. Будь-де, що не є тим самим сервісом.

Зберігайте принаймні чотири тижні цих експортів. Не перезаписуйте той самий файл щоразу. Якщо ваші дані пошкодяться у вівторок, а ви помітите це лише в п’ятницю, ви не хочете, щоб вашою єдиною резервною копією були вже зламані дані п’ятниці.

Структуру застосунку — щоразу, коли робите значну зміну.

Більшість конструкторів застосунків на ШІ мають якусь форму історії версій чи знімків. Знайдіть цю функцію. Користуйтеся нею. Перш ніж робити велику зміну в застосунку — а «велика» означає «таку, яку ви не змогли б відтворити з пам’яті за годину», — зробіть іменований знімок. Назвіть його корисно, на кшталт «перед додаванням екрана оплати» чи «перед зміною ролей користувачів».

Якщо ваш конструктор не має знімків, попросіть ШІ підсумувати, що робить застосунок, у довгому документі. Збережіть цей документ. Це не справжня резервна копія застосунку, але це рецепт — якщо станеться найгірше, ви можете використати цей документ як промпт для відбудови.

Ваші акаунти й облікові дані — один раз, того дня, коли запускаєтеся.

Запишіть в одному місці, де все живе. У якому акаунті конструктора застосунок. У якому сервісі бази даних дані. Який e-mail — адмінський логін. Який платіжний процесор під’єднано. Які інтеграції під’єднано.

Зберігайте це в менеджері паролів, а не в Google Doc. Якщо вас завтра зіб’є автобус, ваш бізнес-партнер має змогти все це знайти. Якщо ви самостійний засновник, ваше майбутнє «я» (за пів року, виснажене, що намагається згадати, що ви зробили під час запуску) теж має змогти це знайти.

Ваші файли — туди, куди завантажують ваші користувачі.

Якщо ваш застосунок приймає завантаження файлів — зображення, PDF, будь-що, — ці файли десь живуть. Знайдіть де. Більшість конструкторів використовує якесь сховище. Перевірте, чи воно резервується. Якщо ні, налаштуйте періодичне копіювання у власне сховище.

Проста рутина резервування, що займає близько 20 хвилин на тиждень

Недільного вечора, поки ви все одно вже не працюєте:

Відкрийте свій конструктор на ШІ. Зробіть іменований знімок поточного стану застосунку. Поставте дату.
Експортуйте кожну таблицю даних як CSV. Скиньте їх у датовану папку у вашому хмарному сховищі. (Більшість даних живе у 3–10 таблицях — невелика робота.)
Зирніть на своє сховище. Переконайтеся, що нічого дивного не відбувається (кількість файлів вибухає, підозрілі завантаження).
Оновіть свій документ «де все живе», якщо цього тижня щось змінилося.

Ось і все. Двадцять хвилин, раз на тиждень. Це дико непропорційна страховка щодо того, що вона захищає.

Якщо ви не хочете робити це вручну, подивіться, чи живуть ваші дані десь із вбудованим резервуванням. Supabase, наприклад, може робити автоматичні щоденні резервні копії за вас. Якщо ви на безкоштовному тарифі, ці копії обмежені; на платному вони сягають далі в минуле. Для бізнесу, що залежить від застосунку, цей платний тариф — найдешевша страховка, яку ви коли-небудь купите.

Що робити, коли щось іде не так

Якщо ваш застосунок ламається через баг конструктора на ШІ чи погану зміну:

Не промптуйте в паніці. Інстинкт — попросити ШІ виправити це негайно. Опирайтеся цьому десять хвилин. Панічне виправлення в неправильний бік може погіршити речі, і більшість конструкторів не легко скасовують ланцюжок промптів.
Відкотіться до останнього знімка. Якщо він у вас є. Це вся причина, чому ви його зробили.
Якщо знімка немає, попросіть конструктор на ШІ скасувати останню конкретну зміну. Будьте точні. «Скасуй зміну, де ми прибрали сторінку реєстрації» краще за «зроби, щоб знову працювало».

Якщо ваші дані пошкоджено:

Негайно зупиніть записи. Виведіть застосунок офлайн, якщо можете. Кожна нова дія користувача, поки ваші дані погані, — це більше даних, які доведеться звіряти пізніше.
Відновіть із найсвіжішої доброї резервної копії. Якщо ви не знаєте, яка добра, відновлюйте їх по одній у копію свого середовища, доки не знайдете останню чисту версію.
Звірте, чого бракує. Якщо ви відновлюєте недільну копію в п’ятницю, ви втратили п’ять днів активності. Напишіть постраждалим користувачам, попросіть їх переробити те, що вони робили, і вибачтеся. Люди напрочуд розуміючі, коли ви чесні й швидкі щодо цього.

Якщо ви втратили доступ до свого акаунту:

Негайно зверніться до підтримки. Не намагайтеся «перечекати». Черги підтримки конструкторів різняться; одні чудові, інші повільні.
Майте напоготові свою особу. Початковий e-mail реєстрації, дані платіжної картки, дата реєстрації, будь-які старі рахунки. Відновлення акаунту без цього важке.

Те, чого ніхто не сказав засновнику

Засновник із бронюванням, з якого я почав, купив платний тариф для свого сервісу даних після того, як ми поговорили. Він налаштував автоматичні щоденні резервні копії. Він зробив знімок свого застосунку. Він записав усі свої акаунти в менеджер паролів. Уся справа зайняла в нього близько години в неділю.

За місяць зміна зі ШІ, яку він попросив, випадково зламала його логіку повторюваних бронювань. Клієнти не могли бачити свої наступні зустрічі. Він помітив це за двадцять хвилин. Він відновив знімок у два кліки. Він зберіг дані, зберіг застосунок, і його клієнти нічого не побачили.

Потім він сказав мені, що це була найдешевша година, яку він коли-небудь витратив. Він не помиляється. Резервні копії застосунку на ШІ — це близько години налаштування й двадцять хвилин на тиждень звички. Те, від чого вони захищають, — це те, про що ніхто з тих, хто це втратив, ніколи не думав, що це з ним станеться.

Якщо ви зібрали щось справжнє, зробіть знімок сьогодні.