Нажать чтобы Перейти на сайт
Я помню свой первый MVP как ночь без сна, переписанные модули и ощущение, что я сам себе враг. В тот раз я пытался показать всё и сразу: React на фронтенде, Node.js с PostgreSQL на бэкенде, Redis для кэширования, Docker для деплоя и ещё пару фреймворков «на вырост». Через две недели я понял, что продукт так и не запустился, а я уже не хотел открывать редактор. С тех пор я веду себя иначе. Перед выбором стека я отвечаю себе на три вопроса: что именно я хочу проверить у пользователей, сколько времени у меня есть и кто будет поддерживать код после запуска. Если цель — проверить спрос, не нужно строить архитектуру на десять лет вперёд. Я выбрал для своего второго MVP связку из Python с Flask, SQLite и готового хостинга. Никакого микросервиса, никакого Docker. Записал всё в один день, запустил за выходные и начал собирать обратную связь. Главный инсайт, который я вынес, — это правило «достаточно, а не идеально». Каждый дополнительный слой технологии — это дополнительный слой поддержки, документации и отладки. Если фреймворк не решает конкретную боль, которой я уже пережил, я откладываю его в сторону. В третьем проекте я чуть перегнул: захотелось попробовать новый язык и написал бэкенд на Go, хотя не знал его глубоко. Результат — потерянные три недели, которые я потратил не на продукт, а на самообразование. С тех пор я позволяю себе изучать новое только после релиза MVP, когда есть время и результат, на который можно опереть MEMORY. Мой подход теперь простой: берите то, что вы знаете на уровне интуиции, что сможете объяснить коллегам за пять минут и что ваш будущий пользователь не заметит, потому что для него важен результат, а не то, что крутится на сервере. И последнее — не бойтесь упрощать. Если ваш MVP можно сделать на Google Таблицах с Zapier за два дня, сделайте это. Продукт, который никто не увидел, — это не продукт. А выгорание — это цена, которую платит каждый разработчик, который пытался быть слишком умным раньше времени. А какой стек вы выбрали для своего последнего MVP и что оказалось избыточным в ретроспективе?
Узнать подробнее →
По теме советую почитать: CI/CD: как мы сократили время релиза в 4 раза
Я помню свой первый MVP как ночь без сна, переписанные модули и ощущение, что я сам себе враг. В тот раз я пытался показать всё и сразу: React на фронтенде, Node.js с PostgreSQL на бэкенде, Redis для кэширования, Docker для деплоя и ещё пару фреймворков «на вырост». Через две недели я понял, что продукт так и не запустился, а я уже не хотел открывать редактор. С тех пор я веду себя иначе. Перед выбором стека я отвечаю себе на три вопроса: что именно я хочу проверить у пользователей, сколько времени у меня есть и кто будет поддерживать код после запуска. Если цель — проверить спрос, не нужно строить архитектуру на десять лет вперёд. Я выбрал для своего второго MVP связку из Python с Flask, SQLite и готового хостинга. Никакого микросервиса, никакого Docker. Записал всё в один день, запустил за выходные и начал собирать обратную связь. Главный инсайт, который я вынес, — это правило «достаточно, а не идеально». Каждый дополнительный слой технологии — это дополнительный слой поддержки, документации и отладки. Если фреймворк не решает конкретную боль, которой я уже пережил, я откладываю его в сторону. В третьем проекте я чуть перегнул: захотелось попробовать новый язык и написал бэкенд на Go, хотя не знал его глубоко. Результат — потерянные три недели, которые я потратил не на продукт, а на самообразование. С тех пор я позволяю себе изучать новое только после релиза MVP, когда есть время и результат, на который можно опереть MEMORY. Мой подход теперь простой: берите то, что вы знаете на уровне интуиции, что сможете объяснить коллегам за пять минут и что ваш будущий пользователь не заметит, потому что для него важен результат, а не то, что крутится на сервере. И последнее — не бойтесь упрощать. Если ваш MVP можно сделать на Google Таблицах с Zapier за два дня, сделайте это. Продукт, который никто не увидел, — это не продукт. А выгорание — это цена, которую платит каждый разработчик, который пытался быть слишком умным раньше времени. А какой стек вы выбрали для своего последнего MVP и что оказалось избыточным в ретроспективе?
Узнать подробнее →
По теме советую почитать: CI/CD: как мы сократили время релиза в 4 раза