я знаю, ты видел в X, как все подряд собирают мобильные приложения с помощью агентов.
буквально каждый день кто-то постит: «запустился в iOS App Store за 24 часа», а через две недели: «вышел на $4k MRR». и ответы всегда одни и те же:
«на чем собирал?» «где взял юзеров?» «скинь рецепт»
насмотревшись на это, ты рано или поздно начинаешь думать:
«может, мне тоже пора делать мобилки?»
короткий ответ: ЕЩЕ БЫ БЛ*НЬ НЕТ.
особенно если последние пару лет ты пилил SaaS.
и особенно если ты убедил себя, что потребительские приложения — не твое, потому что ты «человек из b2b».
потому что есть неплохой шанс, что ты уже несколько лет продаешь обычным людям. просто перед ними висел дашборд от SaaS.
вот почему я считаю, что это разделение важно, и как именно я бы прошел путь от нуля до готового к публикации мобильного приложения максимально быстро.
возможно, ты уже в b2c
есть один стандартный стартап-совет, который повторяют на каждом углу:
- продавай бизнесу
- у бизнеса есть деньги
- b2b-клиенты остаются дольше
- обычные люди платить не хотят
звучит логично.
до тех пор, пока твой «b2b SaaS» — это аналитика за $19/месяц, которую покупают соло-фаундеры.
ты не сбежал из b2c.
ты просто выбрал одну из самых сложных аудиторий потребителей, какую только можно представить.
инди-хакеры и небольшие фаундеры невероятно чувствительны к цене. они понимают, как работает софт, сравнивают всё подряд и с удовольствием потратят три часа на поиск open-source альтернативы, лишь бы не платить тебе $20 в месяц.
а половина из них думает:
«да я и сам такое смогу собрать».
прикрученная подписка через Stripe магическим образом не делает продукт b2b.
гораздо полезнее смотреть на то, почему человек покупает.
компания обычно покупает софт по экономическим причинам. он экономит время сотрудников, снижает косты, увеличивает выручку, заменяет другой инструмент или упрощает какой-то процесс.
обычные люди покупают по совершенно другим причинам.
они хотят лучше спать.
лучше выглядеть.
больше копить.
перестать тратить время впустую.
стать сильнее.
лучше питаться.
чувствовать больше порядка.
чему-то научиться.
от чего-то отказаться.
меньше тревожиться.
стать увереннее.
или просто чувствовать, что двигаются вперед.
и эти проблемы огромны, потому что они есть практически у всех.
тебе не нужно убеждать отдел закупок, интегрироваться в чей-то стек из 14 инструментов или объяснять ROI на созвоне с продажами.
тебе нужно сделать так, чтобы один человек посмотрел на твой продукт и подумал:
«о, я хочу это».
это совсем другая игра.
и прямо сейчас мобильные приложения — один из самых простых способов в нее сыграть.
почему мобилки снова стали интересными
несколько вещей происходят одновременно.
1. ии уничтожил огромную часть технического барьера
раньше сделать нормальное мобильное приложение означало выучить Swift или Kotlin, разобраться в совершенно другой экосистеме, повоевать с Xcode, продумать архитектуру и, скорее всего, потратить месяцы, прежде чем появится что-то достойное показа.
сейчас это меняется невероятно быстро.
сфокусированное потребительское приложение может пройти путь от идеи в голове до рабочего продукта за один день.
узким местом всё чаще становится не:
«смогу ли я это собрать?»
а:
«стоит ли мне это собирать?»
а это куда более интересная задача.
2. каналы дистрибуции для потребителей теперь везде
TikTok, Reels и Shorts могут показать абсолютно неизвестный продукт миллионам людей, даже если у компании нет своей аудитории.
тебе не обязательно нужно SEO.
тебе не обязательно нужна платная реклама.
тебе не обязательно нужно 50 000 подписчиков в Twitter.
один удачный ролик может принести первые сотни или тысячи пользователей, которых хватит, чтобы понять, есть ли там вообще что-то стоящее.
3. мобилки идеально ложатся в эту дистрибуцию
увидел видео.
понял проблему.
скачал приложение.
попробовал продукт.
весь этот путь может занять пару минут на одном и том же устройстве.
переключения контекста почти нет.
4. идеи можно тестировать безумно быстро
пожалуй, это главное изменение.
если сборка MVP занимает три месяца, выбор идеи кажется вопросом жизни и смерти.
если MVP собирается за день-два, экономика полностью меняется.
тебе не нужно искать ту самую идею.
тебе нужно найти что-то достаточно интересное для теста, собрать минимальную версию, подтверждающую ключевое поведение, показать её людям и посмотреть, что будет.
если всем плевать — ты получил опыт.
если люди зашли один раз и не вернулись — ты получил другой опыт.
если 100 человек скачали приложение, и 25 открывают его спустя неделю — вот тут начинается самое интересное.
так вот, как бы я к этому подошел.
ПЕРВЫЙ ШАГ
1) найди спрос до того, как придумывать идею
не открывай пустую страницу в Notion, чтобы штурмить «идеи для стартапа».
скорее всего, ты придумаешь решения проблем, которые существуют только в твоей голове.
вместо этого начни наблюдать за людьми.
для потребительских продуктов одно из лучших мест для этого — TikTok.
скачай его.
трать 5–10 минут в день, целенаправленно выискивая паттерны.
не случайные вирусные ролики. человеческое поведение.
ищи:
- вещи, на которые постоянно жалуются
- привычки, от которых пытаются избавиться
- комплексы и неуверенность
- то, чем хвастаются
- то, что маниакально отслеживают
- новые эстетики и идентичности
- челленджи, которые внезапно начинают делать все
- навыки, в которых люди хотят стать лучше
- рутины, которыми постоянно делятся
- вещи, с которыми регулярно просят помочь
- действия, для которых уже придумали какой-то костыль
по сути, ты ищешь человеческие проблемы, спрятанные под трендами.
например:
есть тренд «underconsumption core» (эстетика осознанного потребления).
на поверхности — люди просто покупают меньше вещей.
очевидная реакция мозга фаундера:
«давайте сделаем приложение для underconsumption».
не надо.
вместо этого спроси, почему миллионам людей это откликается.
возможно, настоящие проблемы звучат так:
«я скупаю всё подряд, когда стрессую».
«я продолжаю покупать то, что мне не нужно».
«копить деньги — это скучно».
«я понятия не имею, куда каждый месяц уходят мои деньги».
«я хочу получать награду за то, что ничего не купил».
вот это уже гораздо интереснее.
теперь можно начинать придумывать реальные продуктовые циклы.
может быть, каждый раз, когда ты удержался от покупки, ты добавляешь вещь в приложение, и счетчик «сэкономленных денег» растет.
может быть, ты фоткаешь то, что собрался купить, а приложение заставляет тебя подождать 24 часа.
может быть, друзья соревнуются, кто избежал большего количества ненужных покупок за месяц.
тренд дал тебе сигнал.
скрытое поведение дает тебе продукт.
3 формата потребительских приложений, к которым я постоянно возвращаюсь
тебе не нужно изобретать совершенно новую категорию.
самые интересные потребительские приложения укладываются в несколько базовых структур.
трекер
превращает невидимое поведение в цифры.
траты. экранное время. сон. привычки. настроение. еда. фокус. тренировки. трезвость. чтение. учеба.
люди обожают видеть себя в цифрах, потому что абстракция внезапно превращается в осязаемый прогресс.
«последнее время я стал лучше концентрироваться» — это размыто.
«мое среднее время фокуса выросло с 41 до 76 минут» — это реально.
коуч
помогает человеку стать чуть лучшей версией себя.
ежедневные миссии. челленджи. планы. напоминания. персональные рекомендации. обратная связь.
людям часто не нужен еще один сложный инструмент с 40 кнопками.
им нужно что-то, что понимает их цель и говорит:
«делай вот это».
продукт становится ценным, потому что избавляет от необходимости принимать решения.
простая утилита
берет одну бесячую вещь и делает её приятной.
таймеры. списки. дневники. заметки. виджеты. планировщики. калькуляторы. сканеры.
функционал может быть смехотворно простым, если пользоваться им — кайф.
продукту не нужны 25 функций, чтобы заслужить место на домашнем экране.
иногда одна функция, которой пользуются каждый день, работает намного мощнее.
вори идеи из комментариев
еще один трюк:
когда находишь тренд, ищи в комментариях слово «приложение».
люди буквально пишут:
«кто-нибудь, сделайте для этого приложение»
или:
«есть приложение, которое это умеет?»
или:
«эх, если бы что-то трекало это автоматически».
это, по сути, бесплатное исследование продукта.
и оно гораздо полезнее, чем спрашивать людей:
«ты бы пользовался приложением, которое делает X?»
потому что они сами формулируют проблему, без того чтобы ты вкладывал им идею в голову.
2) определи цикл до того, как писать код
прежде чем касаться кода, ответь на один простой вопрос:
что человек будет делать внутри этого приложения снова и снова?
не какие в нем есть функции.
а какой цикл?
для приложения контроля трат это может быть:
почти купил → записал → удержался → увидел сэкономленные деньги → почувствовал прогресс → повторил
для фитнес-приложения:
открыл приложение → получил тренировку на сегодня → выполнил → увидел прогресс → вернулся завтра
для приложения фокуса:
выбрал задачу → запустил таймер → завершил сессию → увеличил серию → повторил
если ты не можешь объяснить основной цикл одним предложением, приложение, скорее всего, всё еще слишком сложное.
затем задай себе еще четыре вопроса:
почему человек его скачает?
должно быть очень очевидное обещание.
как он поймет суть за 10 секунд?
ценность не должна требовать туториала.
что даст ему первую победу?
доведи его до этого как можно быстрее.
почему он откроет его завтра?
это то, о чем фаундеры часто забывают.
скачивания — это приятно.
удержание — это и есть продукт.
тебе пока не нужны идеальные ответы. нужна лишь достаточная ясность, чтобы не просить ИИ придумать весь твой бизнес, пока он пишет код.
3) заимствуй паттерны, а не пиксели
когда у тебя есть идея и базовый цикл, не пытайся нарисовать всё с нуля.
ты, скорее всего, не продуктовый дизайнер.
я тоже.
вместо этого найди 5–10 успешных приложений вокруг той же проблемы или поведения пользователя.
им даже не обязательно быть прямыми конкурентами.
если ты делаешь приложение для накоплений, возможно, у одного приложения гениальный онбординг, у другого — отличная система серий, у третьего — залипательный экран прогресса, а у четвертого — пейвол, который тебе нравится.
скачай их.
реально попользуйся ими.
а потом заскриншоть всё:
- первый запуск
- регистрацию
- онбординг
- главный экран
- навигацию
- основное действие
- пустые состояния
- экраны прогресса
- серии
- уведомления
- предложения апгрейда
- пейвол
- настройки
полезны здесь не цвета и не скругленные углы.
а решения, которые за ними стоят.
где они задают вопросы?
сколько экранов в онбординге?
когда показывают сам продукт?
когда запрашивают доступ к уведомлениям?
когда просят деньги?
как быстро ты получаешь первую победу?
какая информация всегда на виду?
что спрятано?
что заставляет вернуться завтра?
эти компании уже протестировали тысячи мелких решений, о которых тебе иначе пришлось бы только гадать.
поэтому не изобретай каждое взаимодействие с нуля.
изучи то, что работает, пойми, почему это работает, совмести лучшие паттерны и добавь свой штрих.
для молодой потребительской аудитории мне обычно нравится:
- одно очевидное действие на экран
- гигантская типографика
- минимум текста
- видимый прогресс
- серии
- контрольные точки
- приятные глазу цифры
- ранняя персонализация
- очень понятная обратная связь при завершении действия
по сути:
сделай так, чтобы прогресс невозможно было не заметить.
если человек что-то завершил — отметь это.
если он пользуется приложением семь дней — покажи ему.
если он улучшил результат на 18% — покажи ему.
если он сэкономил $143 — сделай так, чтобы эту цифру нельзя было проигнорировать.
пользователь должен постоянно понимать:
«это работает».
4) преврати референсы в реальное приложение
вот здесь сборка становится до смешного простой.
я перепробовал большинство инструментов, с которыми люди собирают софт с помощью ИИ.
но если мне нужно быстро пройти путь от идеи до настоящего мобильного приложения, я использую Shipper.
на этом этапе у тебя уже должно быть:
- идея приложения
- твой основной пользователь
- результат, который ты обещаешь
- твой главный продуктовый цикл
- скриншоты приложений, которые хорошо решают похожие задачи
сначала отдай всё это в ChatGPT, Claude или Grok.
не пиши:
«собери мне приложение для бюджета».
ты даешь модели почти нулевой контекст.
вместо этого дай ей нормальную работу:
«я делаю мобильное приложение, которое помогает {user} достичь {outcome}. изучи прикрепленные референсы и разбери ux-паттерны, визуальную иерархию, онбординг, навигацию и взаимодействия, которые они используют. адаптируй эти паттерны под мой продукт. опиши каждый экран mvp, что происходит на каждом экране, полный путь онбординга, основную навигацию, ключевой цикл пользователя и один механизм, который даст пользователям причину возвращаться регулярно. убери всё, что не нужно для первой версии. в конце преврати всё это в подробный промпт для сборки».
теперь у тебя есть нечто гораздо ближе к продуктовому ТЗ, чем случайный промпт.
прочитай его.
убери бред.
добавь то, что модель упустила.
затем возьми этот текст, прикрепи свои скриншоты и загрузи всё в Shipper.
скажи ему ровно то, что хочешь.
экраны.
взаимодействия.
флоу.
логику.
мелкие детали.
а дальше общайся с ним так, будто рядом сидит разработчик:
«сделай этот экран проще».
«сдвинь пейвол на момент после того, как пользователь получит первый результат».
«добавь сюда 7-дневную серию».
«этот онбординг слишком длинный. сократи вдвое».
«сохраняй это состояние, когда пользователь закрывает приложение».
«сделай это взаимодействие более нативным для iOS».
«на этом экране слишком много выбора. сделай одно действие главным».
именно здесь люди неправильно понимают ИИ-билдеров.
тебе не нужно знать Swift.
тебе не нужно вручную создавать каждый компонент.
тебе не нужно поднимать огромный dev-окружение просто чтобы узнать, нужна ли кому-то твоя идея.
но тебе всё ещё нужен вкус.
и тебе всё ещё нужно принимать решения.
по сути, ты руководишь продуктом, пока Shipper его собирает.
и качество результата сильно зависит от качества этих решений.
главное отличие — в том, как ты говоришь с ИИ.
не проси его просто «сделать приложение».
постоянно заставляй его думать о пользователе:
- что он видит первым?
- что он должен здесь понять?
- какое действие самое важное?
- как быстро он получает главную пользу?
- где он может запутаться?
- какую информацию мы можем убрать?
- что делает процесс приятным?
- что даст ему причину открыть приложение завтра?
обычно это дает результат намного лучше, чем бесконечные запросы на новые фичи.
5) сделай первую версию достаточно хорошей, чтобы брать за неё деньги
когда основной флоу заработал, прекрати добавлять случайный функционал.
сосредоточься на трех вещах.
онбординг
относись к онбордингу как к отдельному продукту.
потому что для большинства пользователей он им и является.
они еще не попробовали твой продукт. у них нет к тебе лояльности. они могут закрыть приложение через две секунды и больше никогда о нем не вспомнить.
найди хорошие флоу онбординга, заскриншоть их и повтори тот же процесс работы с референсами.
твоя цель проста:
пользователь должен понять, зачем скачал приложение, и получить ценность за 30 секунд.
каждый экран онбординга должен отрабатывать свое существование.
если задаешь вопрос — используй ответ.
если просишь разрешение — объясни зачем.
если что-то может подождать — отложи на потом.
и если у тебя восемь экранов онбординга только потому, что у каждого второго приложения их восемь, ты делаешь что-то не так.
затем отдай эти референсы в Shipper и итерируй, пока всё не станет интуитивно понятным.
монетизация
когда продукт заработает, добавь подписку и пейвол.
не трать три дня на споры о том, должен ли годовой план стоить $27.99 или $31.99.
у тебя пока нет данных.
абсолютно нормальная точка старта:
- $4.99/неделя
- $29.99/год
цены протестируешь позже.
на старте важнее когда ты просишь деньги.
если возможно, дай пользователю сначала понять ценность.
дай ему что-то создать.
увидеть результат.
завершить первую сессию.
получить первый персональный план.
и только потом ставь пейвол на пути продолжения этой ценности.
ты хочешь, чтобы пользователь думал:
«я хочу еще».
а не:
«за что, черт возьми, я плачу?»
полировка
а затем пользуйся приложением.
много.
не смотри на главный экран, решая, что он выглядит готовым.
веди себя как настоящий пользователь.
начни с чистого аккаунта.
тыкай в кнопки в странном порядке.
отклоняй разрешения.
закрывай приложение на середине онбординга.
открывай снова.
оставляй поля пустыми.
вводи абсурдные данные.
вернись на следующее утро.
дай приложение друзьям без объяснений и смотри, где они застрянут.
ты обнаружишь невероятное количество мелочей, которые казались тебе абсолютно логичными, потому что ты сам это собирал.
каждое убранное непонятное взаимодействие делает продукт надежнее.
и всякий раз, когда что-то ощущается кривым, возвращайся в Shipper и описывай ровно то, что нужно изменить.
ты не пытаешься сделать первую версию идеальной.
ты пытаешься убедиться, что основной цикл ощущается завершенным.
6) релизь до того, как почувствуешь готовность
как только основной цикл заработал:
РЕЛИЗЬ.
не трать еще месяц на социальные фичи, достижения, ИИ-ассистентов, кастомные темы и 14 настроек только потому, что тебе страшно публиковаться.
первая версия не должна доказывать, что ты гений.
она должна ответить на один вопрос:
это вообще кому-то нужно?
опубликуй.
делай контент про проблему.
веди туда людей.
смотри, что они делают.
читай отзывы.
смотри, где отваливаются на онбординге.
смотри, сколько людей доходит до основного действия.
смотри, сколько возвращается на следующий день.
смотри, сколько возвращается через неделю.
смотри, кто платит.
затем почини то, что сломано, и релизнь снова.
лично я бы начал с iOS и задумался об Android только тогда, когда идея оправдает дополнительные усилия.
и я бы держал первую версию почти болезненно сфокусированной.
одна аудитория.
одна проблема.
одно обещание.
один основной цикл.
ты всегда сможешь расширить приложение, когда людям оно понравится.
а вот уменьшать то, в чем уже 30 фичей, гораздо сложнее.
странность создания потребительских приложений прямо сейчас в том, что технический барьер, который останавливал большинство из нас, практически исчез.
раньше ты тратил большую часть энергии на то, чтобы понять, как это собрать.
теперь ты можешь тратить её на то, что действительно заставляет продукт работать:
поиск реального поведения.
превращение его в продукт, который понимают мгновенно.
создание причины вернуться.
поиск каналов дистрибуции.
ты можешь выяснить, чего хотят люди, в TikTok, изучить приложения, которые уже забирают их внимание, превратить эти паттерны в нормальное ТЗ и дать Shipper это собрать.
а потом показать реальным людям.
тебе не нужно знать до старта, станет ли это приложением на $10k/мес.
тебе нужно просто отдать первую версию кому-то в руки.
желательно до того, как истечет таймер на 18 часов.
