Magvi: от проверки гипотезы за 5 недель до зрелого SaaS

Этап 1. Запустили MVP и проверили гипотезу

С чем пришёл основатель. Сергей пришёл с готовыми интерфейсами в Figma и идеей сервиса для создания инфографики карточек маркетплейсов с AI-удалением фона. На тот момент он работал в найме и финансировал проект из собственных средств, поэтому требовалось с минимальными вложениями собрать MVP и проверить, нужен ли такой редактор селлерам. Сергей выбрал Startup-IT, поскольку раньше работал с руководителем команды над проектом domru.ru в IT-Agency, а затем участвовал как дизайнер в проекте veshka — он уже знал подход команды.

Задача. Запустить базовую версию сервиса с ключевой пользовательской механикой, не расходуя бюджет на функции, которые не нужны для проверки спроса. Сергей ограничил первую версию базовыми функциями редактора и решил не включать приём платежей: первые пользователи получали доступ в обмен на отзыв.

Что сделали:

• декомпозировали требования на задачи до четырёх часов и подготовили детальную оценку;
• собрали упрощённые прототипы механик редактора, чтобы Сергей мог проверить их до начала основной разработки;
• для снижения стоимости использовали бесплатные плагины и API, сохранив возможность заменить их впоследствии;
• реализовали редактор с шаблонами, слоями, библиотекой иконок и AI-удалением фона, а также настроили продуктовую аналитику.

Результат:

• стабильная версия была готова на четвёртой неделе, а после доработок продукт запустили через пять недель;
• клиент привлёк первых пользователей, получил положительную обратную связь и решил продолжать развитие сервиса;
• стоимость разработки исходного объёма MVP составила 610 тыс. ₽, дополнительных работ — 170 тыс. ₽;
• число регистраций выросло примерно со 100 в ноябре–декабре 2023 года до 200 в январе и 630 в апреле 2024 года (по данным БД magvi.ai).

Этап 2. Превратили MVP в коммерческий продукт

Задача. После подтверждения спроса внедрить монетизацию.

Что сделали:

• создали упрощённую административную панель;
• добавили подписки на 1, 6 и 12 месяцев с рекуррентными платежами через T‑Bank;
• реализовали отдельную оплату AI-генераций;
• добавили тариф с ежемесячным лимитом генераций;
• сохранили прежнюю стоимость для действующих подписчиков после изменения тарифов.

Результат:

• продукт перешёл от выдачи доступа за отзыв к нескольким моделям монетизации;
• по данным БД на 28 февраля 2026 года, 24,8 % активных подписчиков используют тариф «Про» с дополнительными AI-генерациями;
• по данным БД на 28 февраля 2026 года, активная подписка была у 3,3 % пользователей, зарегистрированных в феврале 2026 года, против 0,7 % среди зарегистрированных в январе–феврале 2025 года.

Этап 3. Развили редактор и AI-возможности

Задача. Сделать сервис полезнее для продавцов маркетплейсов.

Что сделали:

• реализовали кадрирование, фильтры, текст по кругу и выравнивание объектов;
• разработали ластик, который позволяет стирать и восстанавливать области изображения;
• добавили мобильную версию редактора;
• внедрили генерацию фонов, улучшение качества изображений и виртуальную примерку одежды;
• вынесли модель удаления фона в отдельный Python-сервис;
• добавили фотофоны Unsplash и внешние библиотеки иконок.

Результат:

• по отзывам пользователей наиболее заметны генерация и выбор фонов, шаблоны, удаление фона и иконки;
• доля сгенерированных изображений, которые пользователи затем использовали, выросла с 10 % (1 187 из 11 972) в январе 2025 года до 46 % (5 126 из 11 228) в июне 2026 года — по данным БД magvi.ai.

Этап 4. Снизили нагрузку на устройства и защитили старые макеты от регрессий

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

Что сделали:

• во время редактирования стали использовать сжатые копии изображений, а полноразмерные оригиналы подставлять только при экспорте;
• разработали компактный формат хранения макетов, который сохраняет только данные, необходимые для их восстановления;
• перенесли генерацию итоговых изображений с браузера на сервер и перераспределили имеющиеся серверные ресурсы без увеличения расходов на инфраструктуру;
• переработали историю изменений: вместо полных состояний карточки стали хранить только разницу между ними;
• добавили визуальные тесты: перед релизом прогоняем 1000 реальных карточек в тестовой среде и попиксельно сравниваем полученные изображения с эталонными.

Результат:

• размер сериализованного описания макета, который в отдельных случаях достигал 8 МБ, сократился до 3–10 КБ;
• отмена и повтор действий стали выполняться без заметной задержки даже в сложных карточках;
• снизилась нагрузка на браузер: редактор стал стабильно работать на слабых устройствах;
• по наблюдениям команды и клиента, после внедрения визуальных тестов обращения из-за нарушения обратной совместимости прекратились.

Этап 5. Подготовили инфраструктуру к росту без лишних расходов

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

Что сделали:

• провели аудит и нагрузочно протестировали три потенциально уязвимых участка системы: серверный рендеринг, обращения к AI-моделям и генерацию итоговых изображений;
• не стали внедрять горизонтальное масштабирование там, где нагрузочные тесты подтвердили достаточный запас, а AI-модель, развёрнутую на собственной инфраструктуре, вынесли на отдельный сервер из-за другого профиля нагрузки;
• перенесли пользовательские файлы в S3 с локальным кешированием, чтобы сдержать рост расходов без снижения скорости доступа к изображениям.

Результат. Нагрузочные тесты подтвердили запас без дополнительного масштабирования:

• серверный рендеринг выдержал нагрузку в 20 раз выше исторического максимума;
• обращения к AI-моделям — вдвое выше пиковой и в 35 раз выше средней;
• генерация изображений — втрое выше максимальной.

По тарифам на момент переноса удельная стоимость основного хранения снизилась в 4,8 раза: с 12 ₽ за 1 ГБ на SSD до 2,5 ₽ в S3. Изображения сохраняются в SSD-кеше в течение месяца после последнего обращения, чтобы сохранить скорость доступа.

Этап 6. Защитили данные и подготовили сервис к сбоям

Задача. Снизить риски потери данных, незаметных отказов отдельных функций, ошибок в критичной логике и простоев из-за инфраструктурных сбоев.

Как снижали риски:

• Начали обнаруживать сбои до обращений пользователей. Настроили сбор серверных и браузерных ошибок, мониторинг технических и продуктовых показателей и оповещения в Telegram. Например, система сравнивает количество отправленных кодов авторизации с числом успешных входов и сообщает, если расхождение превышает 20 %. Другие оповещения срабатывают при ошибках внешних API, сохранения и скачивания карточек, снижении доли успешных AI-запросов или отсутствии свежих резервных копий.
• Снизили нагрузку при резервном копировании. Обнаружили, что полный дамп базы загружает CPU до 75–90 %. Резервное копирование перевели на pgBackRest с архивированием WAL, а полный дамп перенесли на время минимальной нагрузки. После изменений максимальная загрузка CPU составила 36 % и приходилась уже на обычный пользовательский трафик. Архивирование WAL также позволяет восстановить базу на нужный момент.
• Защитили пользовательские файлы от ошибочного удаления. Добавили ежедневную инвентаризацию файлов. Неиспользуемый файл сначала помещается в карантин на месяц, а перед окончательным удалением система повторно проверяет, не используется ли он.
• Снизили риск ошибок при выпуске обновлений. Платежи и управление изображениями покрыли модульными, интеграционными и функциональными тестами, а основные пользовательские сценарии редактора — e2e-тестами. В зависимости от модуля покрытие автотестами достигло 80–95 %.
• Сохранили доступ к внешним сервисам при сбое прокси. Фотофоны, библиотеки иконок и часть внешних AI-сервисов недоступны напрямую из России, поэтому magvi.ai обращается к ним через прокси. Команда автоматизировала развёртывание прокси в новой локации с помощью Ansible: когда серверы с действующим прокси стали недоступны, за 15 минут развернули прокси в другой локации, переключили трафик и восстановили доступ.

Этап 7. Запустили редактор в white-label-формате

Задача. Адаптировать magvi.ai под бренд крупного клиента и встроить редактор в его систему через sandboxed iframe без разрешения allow-same-origin.

Что сделали:

• отделили настройки бренда с помощью Nuxt Layers и адаптировали дизайн;
• заменили недоступное локальное хранилище собственной реализацией;
• настроили CORS для API и изображений, сохранив обязательную авторизацию API-запросов;
• изменили механизм загрузки изображений: начали работать с ними через Blob, чтобы ограничения canvas не блокировали экспорт карточек;
• согласовали с внешней командой разрешения на выполнение скриптов, скачивание файлов и работу с буфером обмена.

Результат. Редактор запустили внутри системы крупного клиента под его брендом. Название компании и детали интеграции не раскрываются.

Как было организовано сотрудничество, ошибки и выводы

Организация работы:

• клиент определял продуктовые приоритеты, принимал решения о развитии и формировал задачи на спринт;
• Startup-IT декомпозировала задачи, оценивала их и предлагала технические решения;
• за время сотрудничества завершено более 50 спринтов; команда поддерживает и развивает продукт с сентября 2023 года.

Ошибки и выводы. За время развития продукта команда столкнулась с двумя серьёзными инцидентами — оба повлияли на подход к работе с данными и критичной инфраструктурой:

• Ошибка в механизме очистки изображений. Фоновая задача очистки хранилища удалила часть пользовательских изображений. Задача выполнялась по расписанию и зависела от времени, поэтому её было сложно проверить вручную, а автотестов тогда не хватало. После инцидента изменили сам процесс удаления: теперь файл сначала помещается в карантин на месяц, а перед окончательным удалением система ещё раз проверяет, не используется ли он. Механизм управления изображениями плотно покрыли тестами.
• Сбой базы данных во время переезда. При переносе инфраструктуры из Timeweb в Yandex Cloud в конфигурацию базы попала ошибка: база перешла в режим чтения, журналы операций записались в неверном порядке, возникла ошибка консистентности. Сервис был недоступен около двух часов. Команда разобрала последовательность журналов, восстановила консистентность и вернула сервис без потери данных. Риск потери последних записей дополнительно снизили с помощью pgBackRest и непрерывного архивирования WAL.

Итог. magvi.ai начинался с ограниченного MVP, достаточного для проверки главной гипотезы. Архитектуру и инфраструктуру усложняли не заранее, а по мере возникновения подтверждённых продуктом задач — роста нагрузки, усложнения карточек и повышения требований к стабильности. Так разовый запуск перерос в долгосрочное техническое партнёрство: Startup-IT продолжает отвечать за разработку и эксплуатацию magvi.ai, помогая основателю развивать продукт без преждевременных технических затрат.

Отзыв клиента