Быстрое прототипирование в 2026: прототип приложения за вечер

Ещё в 2024-м прототип приложения выглядел так: неделя в Figma, экраны, которые никуда не ведут, и созвон, где вы голосом объясняете заказчику, что произойдёт после нажатия кнопки. InVision с тех пор закрылся, Adobe XD остался в режиме поддержки, а картинку, которую нельзя потрогать пальцем, показывать стало почти неприлично.

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

Ниже — что изменилось в быстром прототипировании к 2026 году, чем я собираю прототипы, сколько времени это занимает по факту (а не в пресс-релизах), где вайб-кодинг подкладывает свинью и что делать, чтобы прототип не пришлось выбрасывать вместе с деньгами.

Что изменилось за два года

Определение прототипа не поменялось: быстро собрать рабочую версию продукта и проверить на ней гипотезу до того, как потратите бюджет. Цикл «собрал — показал — сделал выводы» из Lean Startup работает как работал.

Поменялось три вещи.

Первое: экраны генерирует ИИ, а человек ими руководит. Раньше скорость упиралась в руки дизайнера, теперь — в то, насколько внятно вы формулируете задачу. Умение писать запрос стало таким же рабочим навыком, как раньше было умение расставлять констрейнты.

Второе: пропасть между макетом и кодом почти закрылась. Протокол MCP, который придумали в Anthropic и потом отдали в открытый стандарт, позволяет ИИ-помощнику залезать прямо в дизайн-файл. Агент не угадывает отступы по скриншоту, а читает структуру макета: иерархию фреймов, параметры автолэйаута, токены дизайн-системы. У Figma MCP-сервер отдаёт 16 инструментов с доступом к файлам на чтение и запись, а Code Connect связывает компонент в макете с реальным компонентом в кодовой базе.

Третье: прототип перестал быть декорацией. То, что собирает FlutterFlow Designer или Figma Make, работает с настоящими данными. Человек, которому вы это показываете, реагирует на реальное поведение приложения, а не на своё представление о нём. Качество обратной связи от этого меняется сильно: вместо «вроде понятно» вы получаете «а почему тут ничего не происходит».

Прототип отвечает на один вопрос. Выберите какой

Главная ошибка новичка — сразу лезть в высокую детализацию. Красивый прототип с настоящими данными стоит времени, а отвечает ровно на один вопрос, и этот вопрос надо выбрать заранее.

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

Сколько времени это занимает на самом деле

Цифры, которые публикуют разработчики инструментов, выглядят так:

Цифрам верить можно, но с поправкой. Тридцать секунд — это до первой картинки на экране, а не до чего-то показываемого. Мой обычный расклад на прототип, который не стыдно открыть при заказчике: минут двадцать на первую генерацию и разглядывание результата, час-полтора на доводку экранов и текстов, и ещё столько же, если нужны настоящие данные и вход по логину. Вечер. Против недели-полутора, как это было на макетах в Figma.

Экономия времени по разным замерам выходит в 3–5 раз, стоимость доведения до MVP падает примерно вдвое. Мой опыт примерно об этом же и говорит, но с важной оговоркой: экономится время на сборке, а не на понимании, что именно собирать. Второе не ускорилось вообще.

Чем собирать: инструменты прототипирования и оплата из России

Рынок расслоился на несколько групп, и выбирать стоит группу, а не конкретное название.

Генераторы приложений по описанию:

Редакторы кода с ИИ — Cursor, Claude Code, GitHub Copilot — это уже не про прототип, а про то, что происходит после него. Там вы получаете контроль и репозиторий, но платите за это тем, что надо уметь читать код.

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

Почему я всё равно доделываю во FlutterFlow

У генераторов вроде Lovable и Bolt есть одна общая особенность: прототип и продукт — разные вещи. Вы собрали за 12 минут работающую штуку, показали её людям, идея подтвердилась, а дальше начинается «теперь давайте сделаем нормально». И вот тут выясняется, что нормально придётся делать с нуля.

FlutterFlow ценен ровно этим: прототип из Designer переносится в проект и становится основой приложения. Не референсом, не картинкой для разработчика, а буквально теми же экранами, которые вы дальше обвешиваете логикой, подключаете к базе и собираете в apk и ipa. Проект в любой момент выгружается в чистый код Flutter и уезжает в ваш GitHub: код принадлежит вам, к платформе вы не привязаны.

Теперь про запрос, потому что от него зависит, сколько вы потом будете доводить руками. «Сделай приложение для доставки еды» даёт ровно то, что вы заслужили: набор безликих экранов, которые вы уже сто раз видели. Работает описание по такой схеме: что за приложение, для кого, какие экраны нужны, что человек на них делает, что обязательно должно быть, в каком стиле.

Приложение для записи в барбершоп, для мужчин 25–40 лет.
Экраны: список мастеров с фото и рейтингом, карточка мастера
с примерами работ, выбор услуги и времени, подтверждение записи,
мои записи, профиль. Внизу таб-бар из четырёх вкладок.
Тёмная тема, крупная типографика, минимум декора, акцент
терракотовый. Ключевое действие — записаться в два тапа
с экрана мастера.

Разница между «сделай приложение для записи» и описанием выше — часа два вашей последующей возни с экранами. Ещё сильнее помогает картинка-образец: приложите скриншот приложения, стиль которого нравится, и Designer оттолкнётся от него. Подробно, с примерами и разбором режимов, это описано в переводе документации: запрос к Designer.

И ещё, из личных грабель: генератор собирает экраны, но не собирает вашу дисциплину. Если вы дальше строите на этом реальный проект, стоит сразу навести порядок с темой, отступами и компонентами, иначе через две недели вёрстка расползётся. Правила, которые я держу в голове на каждом проекте, выписаны здесь: вёрстка в FlutterFlow.

Где живут данные: свой сервер вместо чужого облака

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

Причин три, и все скучные.

Персональные данные. По 152-ФЗ данные россиян должны храниться в базах на территории России. Прототип на облачном Supabase или Firebase — это база в чужой юрисдикции. Пока вы показываете экраны трём знакомым, это неважно. Как только регистрируется первый настоящий человек с настоящим телефоном, это уже важно.

Оплата и доступ. Облачный Supabase — это подписка в долларах с теми же проблемами оплаты, что и у всего остального. Свой VPS у российского провайдера оплачивается с обычной карты, стоит предсказуемо и не отваливается в неудачный момент.

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

Установка Supabase на свой сервер — процедура не самая простая, официальная инструкция от Supabase заметно расходится с тем, что происходит в жизни. Я разобрал её по шагам, вместе с S3-хранилищем, доменами и настройкой прокси: установка Supabase на свой сервер. Для self-hosted берите VPS от 2–4 vCPU и 4–8 ГБ памяти: внутри поднимается Docker с десятком сервисов, на двух гигабайтах он будет задыхаться.

Я держу всё это на Timeweb Cloud — российский провайдер, панель нормальная, поддержка отвечает быстро. Там же есть промокод flutterflow, который удваивает первый платёж: оплатили полгода — на балансе год. Работает один раз и только на аккаунтах, где ещё не было оплат, так что вводите его сразу, а не через три месяца.

Если приложению нужны SMS-коды, а не почта, вход через SMSC.ru прикручивается к Supabase SQL-функцией и хуком авторизации: подключение SMSC.ru к Supabase. Работает и в облаке, и на своей установке.

Где вайб-кодинг ломается

Слово «вайб-кодинг» придумал Андрей Карпати в феврале 2025 года: «полностью отдаться вайбу и забыть, что код вообще существует». Пост набрал больше 4,5 млн просмотров, а Collins English Dictionary назвал выражение словом года. Через год тот же Карпати стал говорить «agentic engineering» — потому что стало понятно, чем заканчивается «забыть, что код существует».

Заканчивается вот чем:

• CodeRabbit разобрал 470 пул-реквестов на GitHub: в коде, написанном с ИИ, серьёзных проблем в 1,7 раза больше, чем в написанном руками.
• Particula Tech протестировала три главные платформы вайб-кодинга и нашла уязвимости в 40–45 % сгенерированного кода.
• Сводные оценки по отрасли ещё жёстче: 68–73 % ИИ-кода содержит дыры, которые спокойно проходят юнит-тесты и вылезают уже в бою.
• В мае 2025 года из 1645 приложений, собранных в Lovable, у 170 обнаружилась возможность вытащить чужие персональные данные.
• Gartner предсказывает, что подход «из промпта в приложение» к 2028 году увеличит количество дефектов в софте на 2500 %, если ничего не менять.

Отдельная история — стартап Enrichlead. Весь код писал Cursor, продукт выглядел отлично, но вся проверка прав осталась на клиенте. Приложение сломали за 72 часа. Основатель не смог проверить 15 тысяч строк сгенерированного кода, проект закрыли.

Что ломается чаще всего:

Только счастливый путь. ИИ прекрасно собирает сценарий, где всё хорошо: интернет есть, данные пришли, пользователь ввёл правильное. Обрыв связи, таймаут, пустой список, две одновременные правки одной записи — ничего этого в сгенерированном приложении обычно нет. Оно просто молча ломается.

Потеря контекста. После пятнадцати-двадцати компонентов модель перестаёт держать проект в голове и начинает чинить одно, ломая другое. Пользователи Bolt рассказывали про тысячи долларов, потраченных на токены в попытках выбраться из этой петли.

Ключи в открытую. Ключ API в клиентском коде, никакой валидации ввода, CORS настежь. Для FlutterFlow с Supabase есть свой любимый вариант этой ошибки, и он стоит отдельного предупреждения.

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

Как проверить прототип на людях

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

Слой первый, синтетический. Прогоняете сырой прототип через ИИ-тестирование: виртуальные «пользователи» ходят по интерфейсу и находят битые переходы, тупики и дыры в структуре. Стоит копейки, ловит глупости, экономит время живых людей на очевидном.

Слой второй, живой. Даёте прототип настоящим людям. Здесь вылезает то, что синтетика не поймает в принципе: замешательство, раздражение, «а я думал, эта кнопка про другое». Nielsen Norman Group формулирует жёстко: синтетические пользователи — принципиально ненастоящие, они слишком логичны и склонны хвалить. Хвалебная обратная связь от машины — худшее, что может случиться со слабой идеей.

Слой третий, разбор. Расшифровки, записи и заметки со второго слоя скармливаете модели, она вытаскивает повторяющиеся паттерны и группирует замечания. Неделя разбора сжимается в пару часов.

В российских условиях второй слой обычно упирается в то, что UserTesting и Maze недоступны или неудобны. Работает простое: пять-семь человек из вашей же аудитории, звонок с демонстрацией экрана, прототип открыт по ссылке в вебе, вы молчите. Пять человек ловят большинство проблем — это старое правило Якоба Нильсена, и оно никуда не делось. Опубликовать прототип в вебе, чтобы просто скинуть ссылку, можно прямо из FlutterFlow: публикация в вебе.

Молчать, кстати, тяжелее всего. Каждый раз, когда человек тыкает не туда, хочется объяснить, как правильно. Вот именно в этот момент вы и узнаёте то, ради чего всё затевалось.

Чек-лист перед тем, как показывать

То, что я прохожу по прототипу перед демонстрацией. Занимает минут двадцать, экономит репутацию.

• Пустое состояние: что видно, когда данных ещё нет.
• Ошибка сети: выключите интернет и нажмите главную кнопку.
• Длинный текст: имя в 40 символов и название товара в три строки не должны ломать карточку.
• Вход и выход: авторизация, разлогин, повторный вход под другим человеком.
• Кнопки живые: если кнопка ничего не делает, уберите её, а не оставляйте «на будущее».
• Тексты не рыба: lorem ipsum на демонстрации крадёт всё внимание.
• Размер целей нажатия: по WCAG 2.2 интерактивный элемент — минимум 24×24 пикселя. Мелкие иконки в углу это нарушают почти всегда.
• Ключи и доступы: в клиенте нет секретов, в базе включён RLS.
• Проверка на реальном телефоне, а не только в браузере. В FlutterFlow для этого есть Test Mode и Test Pilot.

Про доступность отдельно: автоматические сканеры ловят только 30–40 % реальных проблем. Но 24 пикселя, контраст и видимый фокус они находят, а это уже половина типичных претензий.

От прототипа к приложению

Дальше начинается то, чего ИИ пока не делает за вас.

Прототип отвечает на вопрос «этим будут пользоваться». Приложение отвечает на вопросы «это выдержит тысячу человек», «это не потеряет данные» и «это пройдёт модерацию в сторе». Между ними — работа с ролями и правами, обработка ошибок, аналитика, тесты, сборка, подписи, магазины.

По моим проектам MVP на FlutterFlow с нормальным бэкендом занимает 3–5 недель. Прототип из этих недель — первый вечер. Всё остальное время уходит на то, что в прототипе можно было не делать, а в приложении нельзя.

Если хочется разобраться самому и вести проекты дальше руками, у меня есть курс: «Мобильный разработчик с нуля», десять модулей от интерфейса до публикации. Если проще отдать — сделаем под ключ, от прототипа до магазинов.

Куда это всё идёт

Несколько вещей видно уже сейчас.

Граница между прототипом и продакшеном продолжает стираться. FlutterFlow ровно этим и занимается: прототип и приложение — один и тот же проект, а не два разных артефакта.

Агентов становится больше, и они делятся по ролям: один пишет, другой ревьюит, третий гоняет тесты. Gartner ожидает, что к 2028 году агентный ИИ будет внутри трети корпоративного софта против меньше процента в 2024-м. Тот же Gartner предупреждает, что больше 40 % агентных проектов закроют к концу 2027 года из-за расходов и непонятной пользы, так что цифру стоит читать вместе с оговоркой.

Роль человека сдвигается в сторону постановки задач и приёмки. Майк Кригер, один из основателей Instagram, сформулировал это коротко: узкое место теперь не в наборе текста, а в принятии решений.

Дисциплина становится преимуществом. Когда собрать прототип может каждый, выигрывает не тот, кто собрал быстрее, а тот, у кого потом ничего не отвалилось.

Коротко

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

Скорость теперь бесплатна. Всё остальное — нет.