MVP за 90 дней: пошаговый план для стартапа

За 90 дней вы получите работающий продукт, которым можно пользоваться и продавать. Вот план, который мы используем в Softwhere.uz. Мы разберём реальный MVP development timeline, который отрабатываем в Softwhere.uz на десятках проектов.

Ключевые выводы

• 90 дней = 2 недели на подготовку, 4 недели на дизайн и прототип, 6 недель на разработку, 2 недели на запуск
• Функций в MVP должно быть не больше 3–5, иначе сроки удвоятся
• Первый прототип показываем пользователям на 4-й неделе, не позже
• Бюджет типичного MVP в Ташкенте — $8 000–25 000 в зависимости от сложности
• Запуск без метрик — это не запуск, а хобби

---

Что нужно иметь перед стартом

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

Понимание, кто платит. Не «все предприниматели», а «владельцы кофеен в Ташкенте, у которых нет системы лояльности». Чем уже, тем лучше.

Проверка, что проблема реальна. Разговоры с 10–15 потенциальными клиентами, не опросы в Telegram-каналах. Люди врут в опросах, но в личной беседе рассказывают правду.

Бюджет на 3 месяца работы + 2 месяца после запуска. Типичный MVP стоит $8 000–15 000 для мобильного приложения или веб-платформы средней сложности. После релиза нужны деньги на доработки по обратной связи — закладывайте 30% сверху.

Если чего-то нет — берём паузу на 1–2 недели и доделываем. Дешевле потратить время сейчас, чем переделывать половину продукта на 10-й неделе.

---

Шаг 1. Распаковываем идею в конкретные задачи (недели 1–2)

Что делаем

Берём лист A3 и пишем в центре: «Что пользователь делает в нашем продукте первые 5 минут». От этого рисуем три ветки: вход в систему, главное действие, результат, за который готовы платить.

Затем методом «вычёркивания» убираем всё, без чего пользователь всё ещё получит результат. Обычно уходит 60–70% «обязательных» фич.

Почему это важно

Каждая лишняя функция часто добавляет недели разработки. Мы видели проекты, где заказчик настаивал на чате внутри приложения для сервиса записи к врачу. Результат: +3 недели, нулевая вовлечённость, потому что все писали в WhatsApp.

Типичные ошибки

• «Нам нужна админка с аналитикой с первого дня» — нет, вам нужен Google Sheets и ручной ввод 2 месяца
• «Конкуренты делают X, значит и нам надо» — конкуренты 5 лет на рынке, у них другая задача
• «Пользователи сами разберутся» — в MVP никто ничего не разбирается, интерфейс должен вести за руку

Внимание: если на этом этапе у вас больше 5 функций в списке — вы делаете не MVP, а полноценный продукт. Сроки вырастут до 6–9 месяцев.

Результат этапа: документ «Функциональность MVP» на 1–2 страницы с user flow от входа до результата.

---

Шаг 2. Проектируем опыт, который работает (недели 2–4)

Что делаем

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

Потом — 5–7 интервью с реальными людьми из целевой аудитории. Даём поиграть с прототипом, молча наблюдаем. Где задержался взгляд — там проблема.

После правок делаем визуальный дизайн. Не «красиво», а «понятно с первого взгляда».

Почему это важно

Переписать код стоит в 10 раз дороже, чем передвинуть кнопку в Figma. Мы в портфолио показываем кейсы, где неделя прототипирования сэкономила 3 недели разработки.

Типичные ошибки

• Дизайн «как у Apple» для аудитории 50+ — они не поймут жесты и минимализм
• Пропуск тестирования прототипов — «и так всё ясно»
• Делать адаптив под 12 разрешений сразя — хватит iPhone и одного размера Android

Результат этапа: кликабельный прототип в Figma, проверенный на 5+ пользователях, финальный макет ключевых экранов.

---

Шаг 3. Выбираем технологию, которая не подведёт (недели 3–4, параллельно с дизайном)

Что делаем

Для большинства MVP мы выбираем из трёх вариантов:

Веб-приложение — React или Vue на фронтенде, Node.js или Python на бэкенде. Быстро, дёшево, работает везде.

Мобильное приложение — Flutter или React Native. Один код на iOS и Android, не два отдельных проекта.

Telegram-бот — если ваша аудитория уже сидит в Telegram, это может быть весь MVP. Сроки — 2–4 недели вместо 12.

Почему это важно

«Правильный» стек — тот, на котором вашу команду найти за разумные деньги и который не умрёт через год. Мы работаем с Flutter и React, потому что в Ташкенте десятки разработчиков их знают. Экзотика типа Rust для MVP — роскошь, которую не каждый стартап переживёт.

Типичные ошибки

• «Напишем сами на чистом коде, без фреймворков» — через полгода никто не разберётся
• «Сразу микросервисы, чтобы масштабироваться» — у вас пока 100 пользователей, монолит выдержит
• Выбор технологии по хайпу, а не по наличию разработчиков

На заметку: если планируете интеграцию с AI — ознакомьтесь с нашими решениями в этой области. Часто можно обойтись готовыми API вместо самописных моделей.

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

---

Шаг 4. Строим, измеряем, не отвлекаемся (недели 4–10)

Что делаем

Разбиваем 6 недель на двухнедельные спринты. Каждый спринт — рабочая часть продукта, которую можно потрогать. Не «написали половину авторизации», а «можно зарегистрироваться и увидеть свой профиль».

Ежедневные 15-минутные созвоны. Не для контроля, а для быстрого снятия блокеров: «застрял с оплатой — нужен доступ к тестовому кабинету банка».

Почему это важно

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

Типичные ошибки

• «Добавим ещё вот это, пока не поздно» — поздно, фиксируем scope
• Тестирование только в конце — баги накапливаются экспоненциально
• Игнорирование технического долга — «потом почистим» означает «никогда»

Результат этапа: работающий продукт на тестовом сервере, проходящий базовые сценарии использования.

---

Шаг 5. Проверяем на реальных людях, а не на себе (недели 9–10)

Что делаем

Набираем 10–15 человек из целевой аудитории, даём им реальные задачи: заказать услугу, оформить подписку, найти информацию. Сидим рядом, молча записываем, где тупят.

Фиксируем метрики: сколько дошло до конца, где бросили, сколько времени заняло. Не «понравилось/не понравилось», а цифры.

Почему это важно

Вы не ваш пользователь. Мы делали приложение для курьеров, где разработчики считали очевидным свайп влево для принятия заказа. Курьеры искали кнопку 20 секунд — в их мире свайп означал «удалить».

Типичные ошибки

• Тестирование на друзьях и родственниках — они лгут, чтобы не обидеть
• Объяснение, как «правильно» пользоваться — вы не будете сидеть у каждого клиента
• Исправление всего сразу — приоритизируем по частоте проблемы

Результат этапа: список правок, отсортированный по влиянию на конверсию, и план финальных двух недель.

---

Шаг 6. Запускаем, а не доводим до совершенства (недели 10–12)

Что делаем

Финальные правки — только критичные баги и блокеры. Всё остальное идёт в бэклог «после запуска».

Настраиваем аналитику: откуда приходят, где застревают, сколько платят. Без этого вы летите вслепую.

Делаем «мягкий запуск» — открываем для 20% аудитории, мониторим 48 часов, потом масштабируем.

Почему это важно

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

Типичные ошибки

• «Ещё одна неделя на тестирование» — потом ещё одна, и ещё
• Запуск без способа собирать обратную связь — форма, чат, хоть email
• Отсутствие плана на случай падения сервера в первый день

Помните: запуск — это начало, не конец. Продукт, который не меняется после запуска, мёртв.

Результат этапа: продукт в продакшене, первые реальные пользователи, работающая аналитика.

---

Шаг 7. Собираем обратную связь и двигаемся дальше (недели 12+)

Что делаем

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

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

Почему это важно

Самые ценные инсайты приходят в первый месяц после запуска. В одном проекте для ритейлера именно в первый месяц выяснилось, что 70% пользователей не находили кнопку оформления заказа, хотя на этапе прототипа проблемы не было. Мы передвинули её в зону большого пальца — конверсия выросла на треть.

Типичные ошибки

• Игнорирование данных, которые противоречат вашей гипотезе
• Попытка угодить всем — «добавим настройку» вместо чёткого выбора
• Забывание про retention в погоне за новыми пользователями

Результат этапа: приоритизированный роадмап на 3 месяца, основанный на реальных данных.

---

Рабочий пример: как это выглядит на практике

Продукт: мобильное приложение для записи в автосервисы Ташкента.

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

Что вошло в MVP:

• Выбор сервиса и времени из доступных слотов
• Запись с предоплатой 30% через Click/ Payme
• Уведомления за день и за час
• Личный кабинет с историей (без сложной аналитики)

Что НЕ вошло: чат с мастером, программа лояльности, интеграция с учётной системой 1С, мобильное приложение для мастеров.

Timeline и бюджет:

• Недели 1–2: интервью с 12 клиентами, согласование функциональности
• Недели 3–4: прототипы, тестирование, визуальный дизайн
• Недели 5–10: разработка на Flutter + Node.js, еженедельные демо
• Недели 11–12: тестирование с 15 реальными клиентами, правки, запуск

Итог: 12 недель, бюджет около $12 000. В этом вымышленном сценарии неявки снизились заметно, администраторы потенциально могли бы освободить несколько часов в день.

Это вымышленный пример, но цифры близки к типичным проектам, которые мы ведём в студии.

---

Что делать, если что-то пошло не так

«На 6-й неделе поняли, что выбрали не ту технологию»

Бывает. Оцениваем: сколько уже сделано, сколько стоит переписать, сколько — допилить текущее. Правило: если переписать меньше 40% — переписываем. Если больше — ищем обходные пути, фиксируем выводы для версии 2.0.

«Заказчик хочет добавить фичу посередине спринта»

Ставим в бэклог, оцениваем влияние на сроки. Если критично — убираем другую фичу равного размера. Scope не растёт, он меняется.

«Разработчики говорят, что не уложатся в срок»

Спрашиваем конкретно: что тормозит, какая задача, сколько часов уже потрачено. Часто проблема в одном неясном требовании, а не в лени.

«Пользователи не понимают интерфейс, хотя нам казалось очевидным»

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

---

Что дальше: после MVP

Немедленно: фиксируем метрики — retention на 1-й, 7-й, 30-й день, конверсию в целевое действие, среднее время на задачу.

В первый месяц: 2–3 спринта на горящие правки, которые видны пользователям.

В первые 3 месяца: решаем — расти (маркетинг, новые каналы) или pivot (менять модель, если метрики не растут).

Через 6 месяцев: планируем версию 1.0 с тем, что отложили. Уже с данными, а не догадками.

---

Нужна помощь с любым шагом? Мы подхватим

Мы в Softwhere.uz делаем fast MVP development для стартапов и бизнесов из Узбекистана, Казахстана, и не только. От проверки идеи до запуска — или на конкретном этапе, где застряли.

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

---

FAQ

Сколько реально стоит MVP в Ташкенте в 2026 году?

Типичный диапазон — от $8 000 для простого Telegram-бота или лендинга с логикой до $25 000 для мобильного приложения с серверной частью и интеграциями платежей. Сложные продукты с AI или интеграцией с ERP-системами могут выходить за эти рамки. Точнее — после короткого разговора о вашей задаче.

Можно ли уложиться в 90 дней, если стартую с одной идеей, без подготовки?

Можно, но первые 2 недели уйдут на то, что мы описали в «предварительных требованиях». Если идея сырыая — добавьте 2–3 недели на интервью и валидацию. Лучше выйти на 14-й неделе с рабочим продуктом, чем на 10-й с ненужным.

Почему нельзя сразу сделать «нормально», а не MVP?

Можно, если у вас 6–9 месяцев и бюджет x3. Но за это время рынок меняется, конкуренты запускаются, а ваши гипотезы могут оказаться неверными. MVP — это страховка от дорогих ошибок, не признак дешёвизны.

Нужен ли технический сооснователь для fast MVP development?

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

Что если через 90 дней никто не будет пользоваться продуктом?

Это тоже результат. Вы потратили $12 000 и 3 месяца, чтобы узнать, что рынок не готов — вместо $50 000 и года на «полноценный» продукт. Данные с реального запуска ценнее любых предположений. Главное — не бросать, а анализировать: не та аудитория, не та цена, не та проблема? И пробовать следующий виток.