Привет! Меня зовут Илья Шмяк, я саунд-дизайнер. Моя работа — создавать звук для игр, кино, брендов. Я не программист, но у меня была гипотеза: можно ли в одиночку, используя только ИИ-ассистента, построить с нуля полноценный веб-сервис?
Спойлер: можно. Этот путь занял 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 может вырасти из пет-проекта в ценный ресурс для разработчиков игр, видеомейкеров и дизайнеров.
Если вам интересен этот кейс, поделитесь им с теми, кому он может быть полезен.
Спасибо, что уделили время! Буду рад ответить на любые вопросы в комментариях.
Автор: InDevSounds
