В предыдущей главе 4 «Создаём вместе с ИИ» у вас появилось что-то работающее. Отсюда начинается Фаза 4 «Выпустить» — этап, на котором вы проверяете тестами, ничего ли не ломается, затыкаете дыры в безопасности и наконец показываете результат миру. Не останавливайтесь на «заработало» — доведите продукт до состояния, когда к нему может спокойно прикоснуться посторонний человек. Звучит сложно, но и здесь ИИ станет вашим напарником.
«Пусть даже незавершённое. Главное — безопасно показать хотя бы одному человеку»
«Сделал» и «готов выпустить» — это разные вещи
То, что работает на вашем компьютере, и то, к чему может безопасно прикоснуться посторонний, — это разные вещи. Вы знаете «правильный способ использования», поэтому у вас всё работает как задумано. Но стоит опубликовать — и прилетят ввод, действия и злой умысел, которых вы не предполагали. Кто-то отправит пустую форму, кто-то вставит гору спецсимволов, кто-то попробует подсмотреть чужие данные.
Но это не повод напрягаться. В инди-разработке первое, что нужно сделать, — всего три базовых пункта: «не ломается ли», «не утекают ли секреты», «защищены ли чужие данные». Эта глава о том, как пройти этот минимум вместе с ИИ и уверенно опубликовать проект.
Вы работаете только по правильной последовательности. Если вылезет ошибка — сами и почините. Появятся секретные данные на экране — вас это не тревожит.
Приходит непредвиденный ввод. Через экран ошибки утекает внутренняя информация. А из случайно опубликованного ключа может прилететь огромный счёт или утечка данных.
Поручите тестирование и ревью искусственному интеллекту
«В разработке в одиночку рядом нет старшего коллеги, который сделает ревью кода» — вот эту роль как раз и поручите ИИ. Пусть код, который вы написали (или заставили написать ИИ), ещё раз проверит ИИ с другого ракурса. Автор кода (будь то человек или ИИ) плохо замечает собственные ошибки. Поэтому так эффективно поставить отдельного «аудитора».
Способ прост. Вставьте код и попросите буквально следующее: «Перечисли баги, опасные вводимые данные и пропущенные тесты в этом коде». В ответ придёт список дыр, которых вы сами не замечали. Дальше — исправляйте по одной, начиная с самых приоритетных. Не пытайтесь чинить всё разом: исправили одно замечание — проверили работу, затем следующее. В этом весь секрет.
Когда просите ИИ провести аудит, точность вырастет, если явно указать такие аспекты.
«В каких случаях падает?», «А если передать пустое значение или ноль?» Пусть ИИ ищет условия, при которых всё ломается.
Вредоносные строки, гигантские объёмы данных, некорректные файлы. Спросите: «Как бы это атаковал злоумышленник?»
«Какие случаи стоило проверить, но вы их не проверяете?» Пусть ИИ выявит граничные значения и исключения.
«Нет ли в коде API-ключей или паролей, прописанных напрямую?» Срежьте ростки утечки заранее.
💡 Тесты — это «механизм автоматической проверки». На практическом маршруте пусть ИИ напишет и сам код тестов. Попросите: «Напиши тесты для этой функции. И для нормального сценария, и для случаев с пустым или некорректным значением» — и после следующей правки вы сможете одной кнопкой перепроверить, не сломалось ли что-то. На вводном маршруте достаточно и того, что вы вручную «нарочно попробуете странные действия».
Три минимальных правила безопасности
Безопасность — глубокая тема, но при публикации инди-проекта запомните сначала лишь три обязательных пункта. Если упустить их, можно разом потерять деньги, доверие и чужие данные. И наоборот — если соблюсти хотя бы это, для первой публикации будет достаточно.
Не пишите напрямую в коде API-ключи, пароли и токены. Выносите их в файл переменных окружения вроде .env, а сам этот файл исключите из публикации (добавьте в .gitignore).
Если есть вход в аккаунт, сделайте так, чтобы пользователь А не мог видеть чужие данные. Обязательно добавьте проверку владельца — «действительно ли эти данные принадлежат именно этому человеку?» — и попросите ИИ её проконтролировать.
Ключи внешних сервисов и права доступа к БД давайте ровно в нужном объёме. Не раздавайте ключ, которым «можно всё». Выпускайте ключи под конкретную задачу — одноразовые, только для чтения и т. п.
🚨 Никогда не публикуйте секретный ключ. Это самая частая и самая дорогая ошибка в инди-разработке. Если опубликовать на GitHub и подобных сервисах код с API-ключом, прописанным напрямую, его за минуты-часы автоматически находят и используют во вред. С платным API бывает, что к моменту, когда вы замечаете, приходит счёт на сотни тысяч — такое реально случается. Перед публикацией обязательно попросите ИИ проверить, «не осталось ли ключа в коде». А если ключ хоть раз попал в публикацию, удаления недостаточно — обязательно отзовите его и выпустите новый.
Если вам кажется, что «это сложно», просто спросите ИИ так: «Объясни новичку, что нужно сделать с точки зрения безопасности перед публикацией этого кода». В ответ вы получите конкретный чек-лист под ваш код.
Как безопасно запускать автоматизацию (для практиков)
Этот раздел в основном для 🔧практического маршрута. Если ИИ-агенту вроде Claude Code автоматически поручить работу с файлами и выполнение команд, разработка резко ускоряется. Но при этом не нулевой остаётся и риск «выхода из-под контроля» — что агент «сам удалит важный файл» или «запустит непреднамеренную команду».
Здесь важна идея «изоляции (песочницы)». Давая ИИ большие права, запускайте его внутри коробки, где ущерб не страшен. Конкретно — заприте его в отдельной рабочей папке или контейнере так, чтобы он не мог дотянуться до боевых данных и секретов. Тогда автоматизацию можно спокойно доверить ИИ.
📦 «Пробуем внутри коробки, а боевое — не спеша» — таков принцип. Не запускайте автоматическое выполнение ИИ сразу на боевом окружении или на важных данных. Конкретные способы изоляции подробно разобраны в руководстве по настройке песочницы Claude Code. Тем, кто идёт вводным маршрутом, достаточно просто знать, что «есть такая мера безопасности».
Публикация — от кода до выхода в сеть
Наконец публикация. «Опубликовать» — значит разместить то, что лежит на вашем компьютере, в сети так, чтобы любой мог открыть это по URL. Это называется деплой. Звучит грозно, но сегодня разместить проект на бесплатном сервисе можно в несколько кликов.
В общих чертах процесс состоит из трёх шагов. Первую публикацию в инди-разработке полностью покрывает бесплатный тариф. Тратить деньги можно тогда, когда пользователей станет больше.
Сохраните код на GitHub и подобных сервисах. Не забудьте исключить секретный файл (.env). Это станет фундаментом публикации.
Свяжите GitHub с бесплатным хостингом вроде Vercel. Секретные данные внесите как переменные окружения через панель управления.
Проект автоматически соберётся в сети, и вам выдадут публичный URL. Остаётся лишь передать этот URL одному человеку.
✅ Даже незавершённое — опубликуйте и покажите одному человеку. «Ещё не хватает функций», «дизайн так себе» — именно с этими мыслями откладывают публикацию, и это главная причина, по которой инди-проекты умирают. Хватит и на 60 баллов. Доведите дело до конца — отправьте публичный URL одному близкому человеку. Его фраза «вот здесь неудобно» ценнее ста часов ваших раздумий.
Конкретные шаги — от сохранения на GitHub до публикации на Vercel и настройки переменных окружения — разобраны со скриншотами в материале «Как собрать в Claude Code / Cursor и опубликовать на Vercel». Если застрянете, прямо спросите ИИ: «На этом экране вылезла ошибка, что делать?» — и в большинстве случаев выберетесь.
- Даже в одиночку роль ревьюера — на ИИ. Просьбой «Перечисли баги, опасные вводимые данные и пропущенные тесты» запускайте аудит и правьте по одному.
- Безопасность — минимум три пункта: секреты в переменные окружения / защита чужих данных / права по минимуму.
- Секретный ключ никогда не публикуйте. Утёк — не удаляйте, а отзывайте и перевыпускайте. Перед публикацией проверьте с ИИ.
- Публикация (деплой) — бесплатного тарифа достаточно. Доведите до конца — передайте URL одному человеку даже с незавершённым продуктом.
Итак, вы дошли до «сделать и безопасно выпустить». Но настоящая борьба начинается отсюда. Финальная фаза — сделать так, чтобы продуктом пользовались, улучшать его и придать ему форму, в которой его можно поддерживать дальше. Переходите к следующей главе 6 «Растим — привлечение аудитории и монетизация».