Привет! Меня зовут Илья Шмяк, я саунд-дизайнер. Моя работа — создавать звук для игр, кино, брендов. Я не программист, но у меня была гипотеза: можно ли в одиночку, используя только ИИ-ассистента, построить с нуля полноценный веб-сервис?

Спойлер: можно. Этот путь занял 7 месяцев и привел к запуску noise pw — библиотеки уникальных звуков. Это не просто история успеха, а разбор факапов, технических решений и текущей экономики проекта.

Этап 1. Гипотеза и MVP: Иллюзия простоты и первые ошибки фронтенда

Все началось с идеи создать платформу для продажи моих звуков и музыки. Моим единственным техническим специалистом стал ChatGPT.

Я начал с анализа референсов, чтобы понять технологический стек. ИИ порекомендовал Jekyll — генератор статических сайтов, как «быстрый, безопасный и простой». На тот момент я не осознавал концепции бэкенда и считал, что сайт — это просто набор HTML-страниц. Весь первый этап был посвящен созданию клиентской части (фронтенда):

• UI/UX итерации: Я часами двигал элементы, менял шрифты и тестировал модальные окна. ИИ часто генерировал нерабочий код, требуя постоянных уточнений.

• Решение микро-задач: Простые, на первый взгляд, вещи («остановить другой трек при нажатии на Play», «корректное отображение модального окна») превращались в многодневные квесты с отладкой кода, сгенерированного нейросетью.

• Баланс между идеей и реализацией: Я постоянно сталкивался с дилеммой: отказаться от сложной фичи (например, динамической визуализации волны) или разбить ее на десятки микроскопических шагов, понятных для ИИ.

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

Этап 2. Первый релиз и столкновение с реальностью: Проблемы бэкенда

Я разместил статические файлы на GitHub Pages. Сайт заработал онлайн. И тут же возник пул задач, которые я не предусмотрел: корзина, скачивание файлов после оплаты, регистрация и аутентификация пользователей, подтверждение email, прием платежей.

Стало очевидно, что нужен бэкенд — серверная логика, которая будет всем этим управлять.

Этап 3. Поиск стека, урок по 152-ФЗ и полный рестарт

Я начал хаотично тестировать разные решения, которые предлагал ChatGPT. Пытался интегрировать Auth0 для авторизации и Supabase для базы данных, развернуть Node.js на хостинге Beget. Все это было похоже на сборку монстра из непонятных мне частей.

В итоге я выбрал бюджетную и удобную связку Yandex Cloud + Auth0. И тут же совершил две критические ошибки:

• Операционная ошибка: Случайно подключил платную услугу в Yandex Cloud, что привело к блокировке аккаунта и долгу в 5000 рублей. Пришлось регистрировать новый аккаунт и переносить весь фронтенд.

• Архитектурная ошибка: Я не учел требования ФЗ-152 о хранении персональных данных граждан РФ на территории России. Мой сервис аутентификации Auth0 с серверами за границей не подходил.

Вся архитектура бэкенда снова рассыпалась. Пришлось начинать с нуля, в третий раз.

Этап 4. Финальная архитектура: Отладка и запуск на Yandex Cloud

Я принял решение — строить всю инфраструктуру на serverless-компонентах одного Yandex Cloud, а для рассылок я подключил Unisender. Этот этап превратил меня из «промпт-инженера» в настоящего отладчика.

• Проблема №1: Аутентификация облачной функции. Первая же функция, которая должна была обращаться к базе данных Yandex Database, выдавала ошибку Unauthenticated.

  • Расследование: Логи указывали на отсутствие прав. Я выдал сервисному аккаунту необходимую роль (ydb.editor), но это не помогло.

  • Решение: Проблема была в коде от ИИ. Он был написан для локального запуска и искал статические секретные ключи. В облачной среде аутентификация происходит через временные IAM-токены. Пришлось глубоко изучить документацию и заставить ИИ переписать логику авторизации с использованием нативного SDK. На это ушло несколько недель.

• Проблема №2: Политика CORS. После настройки бэкенда фронтенд не мог к нему достучаться из-за политики безопасности браузера.

  • Расследование: Браузер блокировал кросс-доменные запросы, так как API-шлюз не отправлял разрешающие заголовки.

  • Решение: Потребовалось создать отдельную "пустую" облачную функцию cors-handler и настроить в API Gateway так, чтобы она отвечала на все OPTIONS запросы, подтверждая, что мой домен имеет право обращаться к API.

• Проблема №3: Внезапное изменение тарифа стороннего сервиса, сломавшее регистрацию.

  • Расследование: В один момент письма для подтверждения регистрации просто перестали доставляться новым пользователям. Я потратил несколько дней на проверку DNS-записей (DKIM, SPF), предполагая, что проблема в спам-фильтрах, но всё было настроено корректно. Обращение в техподдержку Unisender вскрыло реальную причину. Их API перестал работать для отправки писем на адреса, которых еще нет в базе контактов. Это полностью блокировало флоу регистрации: новый пользователь физически не мог получить письмо для подтверждения своего email.

  • Решение: Здесь стоит отдать должное поддержке Unisender. Они не только оперативно объяснили причину, но и, войдя в положение, предоставили 1000 бонусных рублей на счет для плавного старта проекта. Их ключевая рекомендация — перейти на их же специализированный сервис для транзакционных писем Unisender Go. Он изначально предназначен для таких задач, как подтверждение регистрации, и оказался даже более выгодным по стоимости. Я оперативно переписал код интеграции под новое API, и регистрация заработала. Этот случай стал хорошим уроком о том, как важно учитывать риски, связанные с изменением условий использования сторонних сервисов.

Продукт и стек: Как это работает сейчас

В итоге получилась полностью serverless-архитектура, построенная на сервисах Yandex Cloud:

• Фронтенд: Статические HTML/CSS/JS файлы в Yandex Object Storage.

• CDN: Yandex Cloud CDN для быстрой доставки контента по всему миру.

• Бэкенд (Бизнес-логика): 10 serverless-функций (Yandex Cloud Functions) на Node.js (регистрация, платежи, генерация ссылок на скачивание и т.д.).

• База данных: Serverless-СУБД Yandex Managed Service for YDB (пользователи, балансы, транзакции).

• API: Yandex API Gateway для управления запросами к функциям.

• Файловое хранилище: Приватный бакет в Object Storage для хранения аудиофайлов.

• Инфраструктура и безопасность: IAM (управление доступом), Lockbox (хранение секретов), Certificate Manager (бесплатный SSL), Cloud DNS.

Текущая экономика и ключевые выводы

Выводы из 7-месячного марафона:

• ИИ — это инструмент, а не разработчик. Слепое копирование кода ведет в тупик. ИИ ускоряет, но не заменяет необходимости разбираться в документации и основах.

• Архитектура и юридические аспекты — первичны. Фокус на фронтенде без понимания бэкенда и законодательных требований — это потеря времени.

• Отладка — это 90% работы. Написание кода с ИИ — быстро. Поиск причин, почему он не работает в реальной среде — долго.

Операционные расходы на текущем этапе:

• Yandex Cloud: ~164 ₽/мес. (стоимость будет масштабироваться с ростом нагрузки).

• Почта на домене (Beget): 600 ₽/мес. (требование для корректной работы DKIM).

• Домен: 3600 ₽/год.

• Транзакционные письма (Unisender Go): 400 ₽/мес.

• Маркетинговые рассылки (Unisender): Бесплатный тариф, с ростом базы — 8064 ₽/год.

Итого, минимальные ежемесячные расходы на поддержание проекта: ~1464 рублей.

Что дальше?

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

Я верю, что Noise. pw может вырасти из пет-проекта в ценный ресурс для разработчиков игр, видеомейкеров и дизайнеров.

Если вам интересен этот кейс, поделитесь им с теми, кому он может быть полезен.

Спасибо, что уделили время! Буду рад ответить на любые вопросы в комментариях.