Как создать веб-приложение: гид основателя по разработке MVP

Если вы думаете, как создать веб-приложение для нового продукта, короткий ответ такой: сделайте минимально жизнеспособный продукт, MVP. Выберите один сценарий пользователя, доведите его до конца в веб-приложении и покажите реальным людям через несколько недель, а не через полгода. Всё остальное (вторая функция, мобильное приложение, интеграции) ждёт, пока вы не посмотрите, как люди пользуются первой версией.

Этот гид для основателей, которым нужен работающий продукт, а не прототип для презентации: что такое MVP и чем он не является, как урезать объём до того, что реально закончить, что обязательно должно быть в первой версии, от чего зависит цена и что планировать после запуска.

Что такое MVP и чем он не является

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

Веб-приложение в формате MVP закончено на одном пути и молчит обо всём остальном. Пользователь регистрируется, делает то единственное, что обещает продукт, и видит результат. Если этот путь работает, вам есть на чём учиться.

Как урезать объём до одного сценария

Большинство первых продуктов проваливаются на объёме ещё до первой строки кода. Запишите единственный путь, который платящий пользователь проходит от входа в приложение до пользы, и стройте только его:

1. Сформулируйте обещание одним предложением. Например: «Бухгалтер на аутсорсе загружает документы клиента и получает сводку за месяц».
2. Перечислите все экраны, которые нужны для этого предложения. Обычно их пять-восемь, а не тридцать.
3. Для каждого экрана запишите, что пользователь обязан уметь сделать. Всё с пометкой «было бы неплохо» уходит в список отложенного.
4. Про каждый оставшийся пункт спросите: если его не будет, пользователь всё равно получит результат? Если да, вычёркивайте.

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

No-code или своя разработка

Первая развилка: собрать продукт на no-code конструкторе или заказать своё веб-приложение. Оба пути нормальные, ошибка только в том, который потом обходится дороже.

Наше правило: если продукт это форма, список и дашборд, начните с no-code. Если продукт это логика (подбор, расчёт цены, процессы, деньги между сторонами), делайте своё веб-приложение сразу. Переписывать взлетевший no-code MVP это частый и вполне предсказуемый проект.

Стек значит меньше, чем объём

Чаще всего про MVP спрашивают, какой фреймворк выбрать. Для первой версии это почти неважно. Типовой набор сегодня: фронтенд на TypeScript (Next.js или похожий), управляемая база PostgreSQL, проверенная библиотека для входа и хостинг. Скучно, хорошо документировано и недорого в работе.

Важнее другое: команда может поддерживать приложение или чисто передать его, данные выгружаются, а через год второй разработчик сможет прочитать код. В Казахстане есть ещё одно условие: если приложение хранит персональные данные граждан, база должна находиться на территории республики (Закон РК от 21.05.2013 № 94-V «О персональных данных и их защите», ст. 12 п. 2, текст на adilet.zan.kz). Сервер в Казахстане лучше выбрать сразу, чем переезжать после запуска. Если часть данных уходит в зарубежный сервис (почта, аналитика, ИИ), это трансграничная передача, и о ней нужно сказать в согласии пользователя.

Что обязательно должно быть в первой версии

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

• Вход. Регистрация, вход, восстановление доступа, удаление аккаунта. Можно по номеру телефона с одноразовым кодом.
• Основной сценарий. Тот самый путь из упражнения с объёмом, пройденный от начала до конца, с пустыми состояниями и понятными ошибками.
• Оплата, если берёте деньги. Платёжная страница банка или счёт через Kaspi, один тариф и документы, которые примет бухгалтер.
• Админка. Страница, где вы видите пользователей и что они сделали, и исправляете запись без захода в базу. Основатели пропускают её и жалеют в первую же неделю.
• Аналитика и отслеживание ошибок. Три-четыре события, которые показывают, что сценарий пройден, и система, которая пишет вам, когда что-то сломалось.
• Правовой минимум. Политика обработки персональных данных, согласие на обработку с отдельной галочкой, пользовательское соглашение, а если продаёте онлайн, то публичная оферта.

MVP не нужна дизайн-система, но основной сценарий должен быть понятен с телефона. Короткий этап продуктового дизайна до разработки (пути пользователя, прототипы экранов, одно визуальное направление) окупается: он убирает экраны, которые иначе построили бы и выбросили.

Как идёт работа над MVP: этапы

С зафиксированным объёмом, небольшой командой и основателем, который отвечает на вопросы в тот же день, первую рабочую версию можно показать за несколько недель. Точный срок зависит от объёма и записывается в договор после брифа. Как мы проходим эти этапы, подробно описано в статье как мы разрабатываем MVP.

Срок растягивают две вещи: объём, добавленный посреди работы, и медленные решения. Основатель, который смотрит промежуточные версии и отвечает в течение дня, держит график. Если ваша идея не новый продукт, а кабинет для существующих клиентов, этапы те же; подробнее в статье что такое личный кабинет клиента и когда он нужен.

От чего зависит стоимость MVP

Стоимость MVP складывается в основном из объёма и из того, кто делает. Фрилансер обычно дешевле всех, но разброс по качеству и срокам большой, а дизайн, тестирование и поддержка часто не входят. Небольшая студия берёт больше, зато отвечает за дизайн, тестирование и запуск командой. Крупное агентство дороже всего: в цену входят менеджеры, согласования и накладные расходы.

В Pazl веб-приложение или MVP стоит от 1 000 000 ₸. Цена фиксируется в договоре до старта, в неё входят дизайн согласованных экранов, разработка, тестирование, развёртывание на сервере и гарантия 6 месяцев. Что входит в стартовый объём, смотрите на странице цены на MVP. Сумма растёт вместе с экранами, интеграциями и ролями, а не с количеством идей в презентации.

Что поднимает цену, по степени влияния: интеграции с внешними системами (1С, Kaspi, ИС ЭСФ, CRM, логистика), роли и права доступа, функции в реальном времени, свой дизайн вместо библиотеки компонентов и нативное мобильное приложение рядом с веб-версией. Чем меньше этого в первой версии, тем быстрее и дешевле вы узнаете главное.

Как проверить MVP на реальных пользователях

Знать, как построить MVP, это половина работы. Вторая половина в проверке. MVP, которым пользовалась только ваша команда, не проверен. Спланируйте пилот до конца разработки:

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

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

Частые ошибки при создании веб-приложения

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

Что подготовить перед брифом разработчику

• Обещание продукта помещается в одно предложение.
• Основной путь пользователя записан списком экранов (обычно пять-восемь).
• Всё остальное лежит в списке отложенного с причиной, почему может подождать.
• Понятно, платят ли пользователи в первой версии и как: картой, через Kaspi, по счёту.
• Понятно, кому нужна админка и что там должно исправляться.
• Есть диапазон бюджета и дата запуска, которая вас устроит.
• Есть пять-десять реальных людей для пилота.
• Понятно, кто будет отвечать пользователям после запуска.

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

После запуска: поддержка и итерации

День запуска это начало дорогой части, а не конец проекта. Запланируйте три вещи.

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

Итерации. Возьмите список отложенного, вычеркните то, что по итогам пилота никому не нужно, и выпускайте по одному улучшению раз в одну-две недели.

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