Проект "Феникс": как я возрождаю свой провальный стартап на Lovable

Мой первый стартап, AuditFlow, умер. Он прекратил свое существование. Это уже экс-стартап.

Мы привлекли 2 миллиона долларов на создание платформы, использующей ИИ для автоматизации документации соответствия SOC 2. Отличная идея, ужасное исполнение. За 18 месяцев и большую часть этих денег мы построили красивую, сложную машину командой из двенадцати человек. React-фронтенд, Python-бэкенд, Kubernetes - полный набор. К моменту запуска у нас был мощный, но хрупкий продукт. И у нас было ровно девять платящих клиентов. Расчеты не сходились. Мы исчерпали запас прочности, гоняясь за продуктом, который никому не был отчаянно нужен.

Сейчас 2026 год. Я вернулся. И я перестраиваю основную идею AuditFlow, но с новым названием - Complice - и новыми правилами. Ни команды, ни финансирования, ни 18-месячных циклов разработки. Только я, ноутбук и конструктор ИИ-приложений. Я делаю все это публично. Это журнал моего путешествия.

Призрак прошлых стартапов: что пошло не так?

Мой первый стартап потерпел неудачу, потому что мы чрезмерно усложнили продукт и потратили все деньги, так и не найдя соответствия продукта рынку. Мы влюбились в техническое видение вместо проблем наших клиентов. Каждое решение обсуждалось в комитетах. Простое изменение кнопки требовало дизайнера, фронтенд-разработчика, бэкенд-разработчика для API-конечной точки и менеджера проекта для координации. Мы выпускали "крупные" обновления каждые шесть недель, которые почти ничего не меняли.

Мы были одержимы масштабируемостью еще до того, как у нас появилось сто пользователей. Мы месяцами проектировали идеальную микросервисную систему, которая теоретически могла обрабатывать миллионы запросов. Ирония в том, что мы так и не приблизились к этому. Наш ежемесячный расход превышал 150 тысяч долларов. Это была гонка со временем, которую наш тщеславный проект был обречен проиграть. Мы построили линкор для битвы в пруду. Основная ошибка заключалась в измерении прогресса количеством написанного кода, а не количеством решенных проблем клиентов.

Перестройка: почему Lovable в этот раз?

Я выбрал Lovable для перестройки, чтобы сократить время разработки и сосредоточиться почти исключительно на итерациях продукта и обратной связи с пользователями. Цель - скорость. Не небрежная скорость, а скорость обучения. Мой провал с AuditFlow научил меня, что самый большой риск для молодой компании - это не технический долг, а создание того, чего никто не хочет. Lovable напрямую атакует этот риск. Он заставляет вас мыслить категориями пользовательских рабочих процессов и результатов, а не схем баз данных и API-контрактов.

Вместо команды из двенадцати человек моя команда - это я. Вместо ежемесячного расхода в 150 тысяч долларов, это примерно 150 долларов. Lovable абстрагирует 90% церемониального шаблонного кода, который пожирал мою старую команду. Он обрабатывает аутентификацию пользователей, подключения к базам данных, конвейер развертывания и, что самое важное, основную оркестровку ИИ. Я не 10-кратный инженер. Я 1-кратный основатель, который теперь может использовать 100-кратный инструмент. Этот проект не о том, чтобы доказать, что я умею кодировать. Он о том, чтобы доказать, что я могу построить бизнес.

Неделя 1: От идеи до работающего MVP

В первую неделю я перестроил основную функциональность моего старого стартапа в виде функционального MVP, используя готовые агенты и компоненты пользовательского интерфейса Lovable. Старый AuditFlow занял месяцы, чтобы получить работающую версию "hello world". С Lovable я получил работающее, ориентированное на пользователя приложение за три дня. Это был сюрреалистический опыт. Основной цикл моего приложения прост: пользователь загружает доказательства (например, скриншот своих настроек AWS), и ИИ-агент анализирует их на соответствие контролю SOC 2 и пишет черновик описания.

Разработка этого работающего продукта была пугающе быстрой. Я описал агента, который мне нужен: "ИИ-агент, который получает файл и текстовое описание контроля соответствия, затем анализирует файл на соответствие контролю и выводит подробное объяснение для аудитора". Я подключил его к бэкэнду Supabase для пользовательских данных и хранения. Затем я использовал конструктор пользовательского интерфейса Lovable для создания фронтенда. Это было похоже на игру с кубиками Lego, но конечным результатом было настоящее веб-приложение.

Конечно, не все было волшебством. Компонент загрузки файлов по умолчанию не поддерживал пакетную обработку, которую я хотел. Именно здесь проявляется версия этих инструментов 2026 года. Я использовал функцию Lovable "Eject to Code" для этого конкретного компонента. Она дала мне React и бэкенд код только для этой части. Я потратил несколько часов в воскресенье днем на его настройку, а затем вернул его в свой проект Lovable. No-code для скорости, code для специфичности. Это гибридная модель, которая действительно работает.

Публичная панель: прозрачное отслеживание прогресса

Я публично отслеживаю ключевые метрики, такие как регистрация пользователей, использование функций и доход, чтобы оставаться ответственным и получать обратную связь в реальном времени. Создание в публичном пространстве пугает. Это как быть голым на сцене. Но этот страх также является мощным мотиватором. Он заставляет соблюдать дисциплину. Когда вы знаете, что за вами наблюдают, вы с меньшей вероятностью потратите неделю на доработку функции, которую никто не просил. Вот необработанные цифры за мой первый месяц с Complice.

| Неделя | MRR | Активные пользователи | Основные действия | Ключевая идея | | :--- | :--- | :--- | :--- | :--- | | 1 | $0 | 12 | 25 | Друзья и семья. Основной цикл работает, но обработка ошибок плохая. | | 2 | $49 | 35 | 98 | Первый платящий клиент! Люди готовы платить за решение этой проблемы. | | 3 | $98 | 70 | 150 | Привлечено небольшое консалтинговое агентство. Им нужны командные функции. | | 4 | $249 | 160 | 412 | Добавлены базовые приглашения в команду через шаблон Lovable. Проблема подтверждена. |

Эти цифры крошечные. Но они представляют собой то, чего мой первый стартап так и не достиг - тесную, поддающуюся количественной оценке обратную связь. На первой неделе пользователи жаловались на запутанные ошибки. Я потратил четыре часа на улучшение ответов ИИ-агента в случае ошибок. На третьей неделе консалтинговое агентство попросило о командных аккаунтах. Несколько дней спустя я потратил день на реализацию базовой версии. Я строю не на основе грандиозного видения. Я строю на основе прямой обратной связи от платящих клиентов. Вот так.

За пределами MVP: стек конструктора ИИ-приложений 2026 года

Lovable отлично подходит для быстрого прототипирования и управления основной логикой ИИ, но масштабирование сложных, уникальных функций по-прежнему выигрывает от гибридного подхода с использованием других инструментов. Идея, что один инструмент решит все, - это мышление 2024 года. В 2026 году создание ИИ-нативного приложения - это искусство быть опытным системным интегратором, используя лучший инструмент для каждой задачи. Lovable - это "CEO" моего стека, определяющий направление и управляющий основным продуктом.

Но я также использую другие инструменты. Я использую v0 от Vercel, когда мне нужен конкретный, заказной компонент пользовательского интерфейса, который библиотека Lovable не охватывает. Я описываю его v0, получаю React-код и вставляю его в свой проект. Для сложного бэкенд-рабочего процесса, не связанного с пользовательским интерфейсом, например, ночного аудита всех данных клиентов, я могу использовать Bolt. Он отлично подходит для связывания API и моделей более детально, чем основной интерфейс Lovable, ориентированный на приложения.

И когда все остальное терпит неудачу, я использую Cursor, первый ИИ-ориентированный редактор кода. Я использую его для отладки извлеченного кода из Lovable или написания пользовательских SQL-запросов для моей инстанции Supabase. Стек современного соло-основателя - это не "без кода". Это "меньше кода" или "умный код". Речь идет о том, чтобы знать, когда позволить ИИ строить, а когда взять управление на себя. Ценность в вашем вкусе, выборе проблемы и скорости итераций - а не в вашей способности писать конфигурации webpack с нуля.

Действительно ли можно создать полноценный SaaS на Lovable?

Да, для огромной категории AI-нативных SaaS-продуктов вы абсолютно точно можете создавать и масштабировать на Lovable. Если ваша бизнес-логика может быть выражена как серия AI-агентов, пользовательских рабочих процессов и взаимодействий с данными, Lovable, вероятно, самый быстрый способ выйти на рынок. Он идеален для инструментов автоматизации рабочих процессов, приложений для генерации контента, платформ для анализа данных и других систем с "человеком в цикле".

Однако это не универсальный инструмент. Если вы создаете новую векторную базу данных с нуля, высокочастотный торговый алгоритм или движок ААА-видеоигры, вам все равно придется писать низкоуровневый код. Главное - понять основную направленность инструмента. Lovable ориентирован на создание интерактивных веб-приложений на основе агентов. Для Complice это идеальный вариант. Риск не в способности платформы к масштабированию, а в моей способности найти масштабируемую бизнес-модель.

Каково это - снова рисковать провалиться публично?

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

Эта публичная ответственность - это не баг, а фича. Она вынуждает к крайней степени честности. Я не могу лгать себе о выдуманном показателе, когда мне придется публиковать реальные цифры на следующей неделе. Это также создает сообщество. Каждый раз, когда я публикую обновление, я получаю личные сообщения от других основателей с предложениями, ободрением или аналогичными историями из личного опыта. Это одинокий путь, но создание в публичном пространстве делает его немного менее одиноким. Плюсы публичного успеха очевидны, но плюсы публичной ответственности могут быть еще более ценными.

Мой совет тому, кто начинает заново?

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

Для многих основателей в 2026 году таким инструментом будет конструктор ИИ-приложений, например Lovable. Забудьте о спорах о "настоящей" разработке. Единственное, что реально, - это уведомление от Stripe о новом клиенте. Ваша задача - не писать код. Ваша задача - создавать ценность. Отбросьте свое эго и используйте самый прямой путь к созданию этой ценности. Тогда, и только тогда, вы заслужите право беспокоиться о масштабе.