Когда один продукт превращается в два: как разделить приложение на ИИ, не начиная с нуля
Ваше приложение на ИИ начиналось как один продукт. А потом вы поняли, что втайне их было два. Вот как аккуратно разделить ИИ-приложение — не отказываясь от того, что вы уже выпустили.
Вы начали с одной идеи. Вы описали её ИИ-конструктору приложений, посмотрели, как он сгенерировал экраны, подправили шероховатости и выпустили что-то настоящее. Люди начали этим пользоваться. А потом, поначалу медленно, в отзывах проступил один узор: половине ваших пользователей хотелось одного, второй половине — чего-то другого. Они не спорили об одной и той же функции. Они просили два разных продукта.
Это тот момент, когда многие основатели паникуют и начинают второй проект с нуля. И зря. Есть более аккуратный способ разделить ИИ-приложение, когда ваш единый продукт оказывается двумя, — и он обычно сохраняет почти всё, что вы уже построили. Эта статья о том, как распознать момент для разделения, когда его проводить и какие три формы оно обычно принимает.
Как вы узнаёте, что у вас два продукта
Сигнал почти никогда не выглядит как запрос на функцию. Он выглядит как трение.
У одного приложения для продуктивности, за которым я наблюдал, история была наглядной. Его продавали как «личный планировщик». Пользователи начали приходить в двух разновидностях. Одна группа планировала с его помощью свою неделю и относилась к нему как к личному блокноту. Другая руководила небольшими командами и хотела назначать задачи другим людям. И те и другие были достаточно довольны, чтобы продолжать пользоваться одним и тем же продуктом, но каждый релиз радовал одну группу и раздражал другую. Команда думала, что у неё проблема с приоритизацией функций. На самом деле у неё была проблема с брендом. У них были личное приложение и командное приложение, делящие одну кодовую базу, одну главную страницу и одну страницу с тарифами.
Вы поймёте, что пересекли эту черту, когда станет верным хотя бы одно из этого:
- Вашей лендинговой странице приходится прятать свой настоящий питч за обтекаемыми формулировками, потому что две аудитории не поверят одним и тем же словам.
- У каждой новой функции есть оговорка «но для другого типа пользователей это должно работать иначе».
- Ваши ответы в поддержке начинают ветвиться: «если вы пользуетесь этим для себя…» против «если вы управляете командой…».
- Заметное число пользователей заводят два отдельных аккаунта, чтобы держать два режима порознь.
Если вы наблюдаете два или больше из этих признаков — у вас не проблема с функциями. У вас назревшее разделение продукта.
Три формы разделения
Вам не нужно выбирать форму в первый же день. Обычно можно сначала попробовать самую лёгкую и при необходимости усложнить. Но полезно знать меню до того, как вы начнёте описывать это своему ИИ-конструктору, потому что слова, которые вы используете, определят то, что будет сгенерировано.
Форма 1: одно приложение, две двери
Самый лёгкий вариант. Вы сохраняете одну кодовую базу. Вы добавляете вопрос при первом запуске — «Вы здесь для себя или для команды?» — и по ответу показываете разный набор страниц и разную навигацию. Одно хранилище данных. Один вход. Один биллинг. Просто разная поверхность.
Большинство ИИ-конструкторов приложений хорошо справляются с этим, если описать это как «приложение с двумя режимами». Следить нужно за тем, чтобы два режима не делили экраны с условными показами и скрытиями повсюду. В итоге это выглядит как одно загромождённое приложение, притворяющееся двумя. Скажите конструктору, что две двери раздельны: разные главные страницы, разные страницы настроек, разные пустые состояния. Те немногие экраны, что действительно пересекаются (настройки аккаунта, биллинг), могут быть общими.
Когда это работает: когда двум аудиториям нужна разная подача, но одни и те же базовые объекты. Пример «планировщик против команды» сюда подходит. То, что вы планируете, по-прежнему остаётся задачей; меняются только правила вокруг назначения, обмена и уведомлений.
Когда это не работает: когда две аудитории ожидают совершенно разных объектов. У «портала клиента» и «внутреннего админ-инструмента» почти нет пересечений, даже если кажется, что они об одном и том же бизнесе.
Форма 2: два приложения, один бэкенд
Средняя форма. Вы разделяете лицевую часть продукта на два отдельных приложения — два URL, две лендинговые страницы, два сценария онбординга, две таблицы тарифов, — но оба читают из одной базы данных под капотом. У клиента может быть аккаунт в обоих. Администратор может видеть данные из обоих.
Именно это мы недавно сделали в компании, которая ведёт этот блог. У нас было одно приложение, пытавшееся обслуживать две аудитории: инженеров, оценивающих нашу агентную платформу, и тех, кто строит приложения нашим ИИ-конструктором приложений. Один бэкенд, одна авторизация, одна база данных — но у фронтенда выросло две головы, и сообщение запуталось. Мы разделили его на два фронтенд-приложения, по одному на аудиторию. Бэкенд остался ровно тем же.
Эта форма — верный ответ, когда:
- Две аудитории покупают по разным причинам.
- Их бы запутал или оттолкнул маркетинговый текст другой аудитории.
- Данные, которые им важны, в основном одинаковой формы, но поданы по-разному.
- Вы не хотите поддерживать две базы данных или две настройки биллинга.
Скажите своему ИИ-конструктору, что вам нужно «второе фронтенд-приложение, которое использует существующий API». Большинство современных ИИ-конструкторов могут создать дочерний проект и направить его на ваш существующий бэкенд. Ловушка, которой стоит избегать: копировать компоненты первого приложения дословно, а затем вечно править обе копии. Попросите конструктора вынести общие части (экраны авторизации, типовые виджеты форм) в небольшую библиотеку, которой пользуются оба приложения. Вы сэкономите себе месяцы дублирующихся правок в будущем.
Форма 3: два приложения, два бэкенда
Самое тяжёлое разделение. У вас на самом деле два продукта. Они не делят данные, не делят пользователей и не должны делить дорожную карту. Правильный ход — полностью их разделить: отдельные кодовые базы, отдельные базы данных, отдельные домены.
Это правильный ход реже, чем думают. Он соблазнителен, потому что кажется чистым. Реальность в том, что два полностью раздельных приложения означают по два экземпляра всего, что нужно поддерживать в рабочем состоянии: два конвейера деплоя, два дежурства, две интеграции биллинга, два набора справочной документации. Не тянитесь к этой форме, если продукты не пересекаются по-настоящему. Хороший тест: если пользователь продукта А никогда бы не стал пользователем продукта Б, вам, вероятно, действительно нужна Форма 3. Если большинство ваших пользователей правдоподобно могли бы хотеть оба — вам почти наверняка нужна Форма 2.
Когда вы делаете это с ИИ-конструктором, проще всего скопировать ваш существующий проект как стартовую точку для второго, а затем попросить конструктор убрать функции, которые туда не относятся, и добавить те, что относятся. Не начинайте второй проект с чистого листа. Вы уже многому научились, строя первый, и ИИ-конструктор подхватит этот контекст, если вы ему позволите.
Что сделать перед тем, как что-либо разделять
Прежде чем описывать разделение своему ИИ-конструктору, сделайте три небольших вещи. Они стоят больше, чем звучат.
Во-первых, напишите новую главную страницу для каждой стороны. По два абзаца на каждую. Питч, аудитория, одно действие, которого вы от них хотите. Если вы не можете написать две разные главные страницы, значит, у вас пока нет двух продуктов — у вас просто два сегмента одного продукта, и решать это нужно сообщением, а не архитектурой.
Во-вторых, перечислите, какие экраны общие, а какие нет. Будьте честны. «Вход общий. Онбординг разный. Дашборд разный. Настройки в основном общие. Биллинг общий.» Этот список становится брифом, который вы передаёте ИИ-конструктору. Он экономит массу переписки туда-сюда.
В-третьих, решите, что одинаково под капотом. Одни и те же пользователи? Одни и те же данные? Одни и те же платежи? Каждое «да» тянет вас к Форме 1 или 2. Каждое «нет» тянет к Форме 3. Правильного ответа нет — есть только тот, что соответствует тому, как ваш продукт работает на самом деле.
Что меняется после разделения
Две вещи становятся легче, а одна — труднее.
Маркетинг становится легче. У каждого приложения появляется свой ясный питч. Каждая лендинговая страница может обращаться к одной аудитории без оговорок. Ваша конверсия обычно растёт хотя бы на одной стороне, иногда на обеих.
Онбординг становится легче. Новый пользователь попадает на страницу, которая о нём, а не на страницу, пытающуюся быть обо всех сразу.
Труднее становится держать общие части в синхроне. Если вы чините баг в сценарии входа, вы хотите, чтобы он был починен в обоих приложениях. Если вы меняете внешний вид экрана биллинга, вы хотите, чтобы оба приложения это отразили. Дисциплина, которая вам нужна — и это верно независимо от того, занимаетесь ли вы вайб-кодингом с ИИ-конструктором или строите с командой живых разработчиков, — это держать общие части по-настоящему общими. Не дублируйте. Не форкайте. Либо вынесите общий экран в небольшую библиотеку, которой пользуются оба приложения, либо примите тот факт, что у вас два действительно раздельных приложения, и владейте этим.
Небольшой вопрос напоследок
Если бы вы прогнали питч своего нынешнего приложения мимо пяти незнакомцев и каждый описал бы его по-своему — но в две отдельные корзины, — вы, вероятно, уже живёте с разделением. Вопрос лишь в том, продолжаете ли вы платить налог одного запутанного продукта или делаете работу по тому, чтобы честно признать, что продукта два.
Решать сегодня не обязательно. Но в следующий раз, когда ваш ИИ-конструктор приложений спросит «что мне построить дальше?», подумайте о том, что самый полезный ответ — возможно, не новая функция. Это может быть новая входная дверь.
Если это отозвалось, вам может понравиться и наша более ранняя статья про создание для своей команды против создания для клиентов — тот же тип решения, на шаг раньше в жизни вашего продукта.