Скорость разработки прототипов

Успешность MVP решения напрямую связанна со скоростью его создания, с этим никто не будет спорить (надеюсь). Но из чего складывается скорость создания?
Мне кажется есть 3 основополагающих фактора:

1. Глубина знания стека
   На сколько досконально вы понимаете инструментарий на котором строите свой MVP. Т.е. если вы пишете виртуозно на python, но не знаете ELM, наверное не стоит на нем делать фронтенд для вашего прототипа. А вот если вы досконально знаете php и python, но собрались реализовывать сервер для мультиплейрного рогалика, то выбирать C/C++ не обязательно, для MVP вполне подойдет python просто из-за скорости разработки логики с вашей стороны. При сборке прототипа чем меньше вопросов будет у вас к документации и стеку тем больше времени вы потратите на сам продукт, а это важно.
2. Универсальность стека
   Если вы пишете только на php и вдруг решили делать мобильное приложение или десктопное приложение, или что-то другое экзотическое, то скорее всего у меня для вас плохие новости. Если у вас в руках молоток, все конечно становится гвоздями, но не каждый молоток подходит под любой гвоздь, некоторые просто не забьются, а часть просто загнутся и сломаются и это я даже про шурупы не заикаюсь. Ровно тоже самое и со стеком – чем более он универсален, тем больше возможностей он дает. Но! Чем более инструмент пытается мимикрировать под серебренную пулю, тем вероятнее у него больше ограничений. А это в свою очередь приводит к подводным камням во время реализации и иногда к недельным сражениям с ветряными мельницами, что может негативно сказаться на качестве прототипа, ибо вам следует думать о функционале идеи и пользовательском опыте, а не о том почему приведение типов на разных процессорах дает разный результат..
3. Широта кругозора за пределами стека
   Нельзя просто так взять и написать эффективное веб приложение в 22ом году. Есть, конечно, разного рода варианты как можно упростить себе жизнь, но если вы всю жизнь писали только админки на любом высокоуровневом фреймворке, а деплоем, тестированием, маркетингом, упаковкой и администрированием во всех смыслах занимались другие люди - скорее всего во время сотворения своего продукта вас ждут увлекательные пешие прогулки за гриндом знаний в песочницы соседних детских садиков. Чем богаче опыт у вас, как у автора разрабатываемого MVP, тем вероятнее более целостным выйдет решение. Читали книжку про UX - класс, это пригодится. Поработали с Figma и знаете как там нарисовать прототип и визуализировать свои идеи - отлично. Знаете как настраивать linux сервера - идеально! Умеете фотографировать, писать тексты, настраивать рекламные компании и т.д.? Кажется тогда вам может и стоит начать писать прототип. Ну а если не умеете, не видели, не щупали и вообще не хотите ничего нового решать, а хотите код писать?... То тогда четко должны понимать, что между идеей и презентацией этой идеи аудитории существует не только разработка, а еще и увлекательнейший мир сопутствующих направлений, без которых даже гениальная идея и божественная реализация на лучшем стеке всех времен и народов обречена на безвестность и провал.

Так из чего складывается скорость разработки прототипов?

Из опыта разработки и сопровождения прошлых продуктов.
Существует конечно маленькая вероятность, что без этого опыта у вас что-то получится. И такие примеры есть, но учитывая кол-во этих примеров - скорее это ошибки выживших. Прежде чем сейчас бросаться в жерло возможностей импортозамещения и заживо сгорать в агонии несовершенства этого мира - лучше объединитесь в команду с разносторонним опытом на начальном этапе. Прототип создаваемый в одно жало имеет еще меньшую частотность доведения до готового продукта и без описанных 3 факторов выше. Пресловутая градация нас всех на стартеров и финишеров играет в этом не последнюю роль. =)