Сарайчик или музей: как выбирать между быстрым MVP и идеальной архитектурой
<img src="https://habrastorage.org/getpro/habr/upload_files/68d/d39/6e8/68dd396e8dc3511e722f5b062c84d777.jpg" /><p><strong>В разработке почти всегда приходится выбирать между быстрым решением и технически идеальным. И почти всегда правильный ответ находится где-то между крайностями.</strong></p><p>За последние годы я видел два почти зеркальных примера.</p><p>Первый сервис буквально дышит на ладан. Операционка съедает больше половины времени команды, релизы заставляют нервничать, а часть конструкции держится на подпорках и знаниях нескольких старожилов.</p><p>Но сервис коммерчески успешен. Он нашёл аудиторию, приносит деньги и продолжает расти.</p><p>В соседнем мире команда построила решение, которое можно ставить в музей. Красивые контракты, современный стек, продуманная архитектура и почти физическое удовольствие от того, насколько всё правильно устроено.</p><p>Только стоимость разработки оказалась в разы выше потенциальной прибыли — и сервис закрыли.</p><p>Прощаться со вторым проектом бывает даже тяжелее, чем с первым. В него вложено столько сил, что хочется продолжать уже не ради продукта, а чтобы оправдать предыдущие инвестиции.</p><p>Эти два случая хорошо показывают неприятную вещь: коммерческий успех не доказывает качество технического решения. Но и техническое совершенство ничего не говорит о ценности продукта.</p> <a href="https://habr.com/ru/articles/1078738/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1078738#habracut">Технический долг — не моральная категория</a>