MVP за 30 дней: стек, бюджет и грабли, о которых мне никто не сказал

Artyom_Harris

New member
Год назад я уволился из аутсорса с мыслью «хватит кодить чужое» и решил проверить одну идею — сервис для автоматизации записи в барбершопы, потому что мой знакомый мастер до сих пор ведёт клиентов в бумажном блокноте. Идея казалась простой до неприличия, и именно это меня и подкупило. Я дал себе жёсткий срок — 30 календарных дней на работающий MVP с живыми первыми пользователями. Не «прототип», не «лендинг с формой предзаказа», а продукт, которым можно пользоваться и за который кто-то готов заплатить. Сегодня, спустя время, могу честно разобрать, что сработало, сколько это стоило и где я наступил на грабли, которых мог бы избежать.

Первое, что я сделал — и это, пожалуй, самое ценное решение за весь месяц — сократил объём работ в четыре раза. Изначально в голове была полноценная платформа: личные кабинеты салонов, онлайн-оплата, аналитика, мобильное приложение, уведомления в мессенджерах. Я выписал все фичи на лист и безжалостно вычеркнул всё, без чего клиент физически не сможет записаться, а мастер — увидеть запись. Осталось три экрана, одна роль пользователя и один сценарий. Остальное ушло в файл «после MVP», который, кстати, до сих пор живёт и пополняется. Правило, которое я вынес: если фичу можно описать словами «было бы круто» — она в следующую версию.

По стеку я не изобретал велосипед и выбрал то, что знал лучше всего, а не то, что модно в твиттере. Фронтенд — React с TypeScript, потому что типы спасали меня десятки раз, когда я правил код ночью. Бэкенд — Node.js с Fastify, простая реляционная база на Postgres, развёрнутая в managed-варианте у облачного провайдера. Авторизацию не писал сам, а взял готовый сервис аутентификации — это сэкономило мне, по ощущениям, дня четыре. Отдельно скажу про инфраструктуру: я сознательно не полез в Kubernetes, не строил микросервисы и не настраивал CI с нуля. Обычный сервер, докер-контейнер, автоматический деплой по пушу в основную ветку. Скучно — да. Работает — абсолютно.

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

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

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

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

Заканчиваю на позитиве: MVP за 30 дней — это абсолютно реально, если относиться к себе как к подрядчику с жёстким контрактом, а не как к художнику в поиске вдохновения. Мой сервис не стал единорогом и, честно говоря, не стал даже стабильным бизнесом, но он дал мне то, что не купишь ни за какие деньги: понимание, как быстро превращать мысль в работающую вещь и не сгорать по дороге. А теперь вопрос к вам, форумчане: какой самый короткий срок вы себе ставили на запуск своего проекта и что стало главным ускорителем — или главным тормозом? Делитесь опытом, мне правда интересно сравнить.
 
Назад
Вверх