Запуск AI приложения за месяц - от идеи до публикации

Цель этой статьи - рассказать, как можно запустить за месяц полноценное приложения-продукт с AI функционалом. От идеи до публикации в AppStore. С оплатами и всей нужной аналитикой, масштабируемое приложение без no-code

По-нашему мнению ключевые критерии успешности при разработке МВП - это:

1. Ограничение по одному юзкейсу, которое выполняет приложение
2. Скорость разработки данного юзкейса
   
3. Возможность собирать данные о поведении пользователей после релиза

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

Почему не надо упарываться в продукт при запуске

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

Поэтому сфокусироваться лучше на рекламе, странице в сторе (ASO материалах), онбординге и пейволе. Продуктовую часть можно будет подтянуть уже потом, после подтверждения интереса к приложению

Эти принципы мы применили при запуске приложения Summarizer для одного из наших клиентов.

Описание изначальной гипотезы приложения

Люди готовы платить за приложение, в которое можно загрузить запись рабочей встречи, а на выходе получить транскрипцию, суммаризацию и список to-do. Кажется, что тема уже заезжанная, но практически год назад, когда мы только запускали приложение, это было совсем не так)

Ограничение по одному юзкейсу

В общем-то все что можно было сделать в приложении - это загрузить видео и получить транскрипцию, суммаризацию и to-do встречи. Ну и подписку купить, чтобы к этому всему доступ был. Все) Никакой истории, авторизации, кастомизации результатов, профиля и другого “продуктового сахара”.

Почему? Потому что это не помогает проверить гипотезу, что пользователи готовы платить деньги за транскрибацию и суммаризацию видео

Единственное что мы добавили - это возможность не только загружать локальные файлы, но и вставлять ссылки на YouTube видео, чтобы охватить больше людей, но это никак не повлияло на скорость разработки

Скорость разработки юзкейса

Распишем тайм-лайн работы над проектом:

1. 19 июня 2023 началась первая неделя работы над проектом. За нее мы отрисовали основные ваерфреймы функционала, изучили апи для работы с youtube, whisper, gpt и начали писать интеграцию апи в проекте
2. за вторую неделю у нас уже был готов первый прототип приложения, в котором можно вставить ссылку на youtube видео и получить результат. Помимо этого завезли дизайн пейвола и онбординга, добавили возможность эксперимента с промптами прямо в приложении
   
3. к концу третьей недели был пейвол и необходимость оплачивать подписку для доступа к функционалу приложения, появился сервис аналитики подписок. Ну и для лучшего UX сделали анимации обработки видео и сообщений об ошибке
   
4. на четвертой неделе уже занялись украшательствами - сделали иконки и онбординг, подключили дополнительную аналитику, дорабатывали логику загрузки файлов и улучшали промпты
   
5. Последняя неделя ушла на подготовку приложения к публикации - настройку аккаунта разработчика, скриншоты, промо-тексты (я их писал тоже при помощи ChatGPT, рассказал об этом тут)

26 июля 2023 приложение прошло проверки AppStore и мы могли публиковать его. Как я восстановил такое точное описание? Все просто - мы еженедельно делали отчет об отработанных часах, сделанной работе и планах на следующую неделю

Возможность собирать данные после релиза

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

• Аналитика по подпискам. Чтобы считать главные финансовые метрики приложения - MRR, сколько пришло новых подписок, а сколько отвалилось, какая конверсия в продление подписки и тд. Для ее сбора, как и в целом для настройки работы подписок, мы используем сервис AppHud
• Аналитика по событиям в приложении. Что чаще загружают - локальные видео или ютуб, нравится им результат работы или нет и другие целевые действия. Изначально мы подключили Appmetrica, но потом приложение обросло целым букетом сервисов аналитики - AppsFlyer, Firebase, Facebook, Amplitude. Что-то из этого нужно для настройки рекламы, что-то для продуктовой аналитики
  

После публикации мы старались максимально быстро обрабатывать обратную связь от пользователей. Для этого мы выпускали небольшие точечные обновления по два раза в неделю. Это были небольшие доработки, улучшение промпта для работы с ИИ, правки и фиксы минорных багов. Параллельно у нас были в проработке полноценные фичи, такие как сохранение истории просмотров, интеграция работы через сервер и тд

Так же мы периодически освежали дизайн онбординга, главной, больше углубляясь в качество и лучше продумывая UX

Сейчас Суммаризатор - это активнорастущее приложение с аудиторией более 40.000 пользователей. Мы продолжаем развивать проект и сейчас. Выпускаем обновления каждую неделю. Вместе с фаундером приложения проводим еженедельные звонки, на которых показываем результаты работы продуктовой аналитики, обсуждаем планы по продукту на ближайшие две недели. У нас составлен бэклог, в которой отправляется все что мы нагенерили, продакт менеджер приоритезирует фичи в нем и делает описания для команды

Предлагаю вам звонок-экскурсию по нашим процессам. На ней мы подробнее расскажем, как мы развиваем IT продукты и быстро деливерим реальный результат. Для этого можно написать мне в телеграм @dmitrii_polushin “хочу экскурсию”