Дейв Хекер, Член совета по технологиям Forbes в разделе инновация, Технический директор iTechArt, компании по разработке программного обеспечения высшего уровня, которая создает отличные продукты для стартапов, поддерживаемых венчурным капиталом.
До недавнего времени идея создания MVP на no-code платформе приводила к прогнозам грандиозного провала из-за проблем с масштабируемостью, стабильностью и функциональностью, не говоря уже о нескольких закатываниях глаз. Движение no-code появилось здесь, чтобы остаться, и достигло точки, когда создание no-code MVP может быть жизнеспособным и разумным вариантом для стартапа.
Преимущество использования no-code неоспоримо: его создание дешевле и быстрее, чем пользовательский код. Однако no-code платформа не может соответствовать практически безграничной гибкости и расширяемости, которые может обеспечить пользовательский код, не говоря уже о потенциале безопасности и масштабируемости. Однако этот разрыв сокращается, поскольку такие платформы, как bubble, Webflow и Bildr, за последние годы значительно эволюционировали, став впечатляюще надежными и универсальными. Многие no-code платформы начинают предлагать некоторую no-code функциональность, которая обеспечивает расширяемость за счет фрагментов кода и значительно снижает риск попадания в коробку с чистой no-code системой. Для стартапа это означает, что если от их MVP не ожидается гипермасштабирования и не требуется какой-либо необычно сложной функциональности, было бы очень реалистично и даже стратегически построить его без кода. Как руководитель стартапа должен оценивать отсутствие кода по сравнению с пользовательским кодом и принимать правильное решение?
Мой совет - игнорировать шумиху и ненависть вокруг no-code инструментов и сосредоточиться на своей цели. Многие стартапы создают MVP, чтобы завоевать рынок и/или продемонстрировать бизнес-модель в надежде получить финансирование, и no-code MVP может очень эффективно поддерживать эти цели. Камнем преткновения для многих является то, что если их стартап будет широко успешным, они почти наверняка перерастут no-code решения и должны будут все перестроить. Каким бы нелогичным это ни казалось, в долгосрочной перспективе это может сработать хорошо.
Перестройка приложения - это не пикник, но она имеет несколько предсказуемую стоимость и уровень усилий, которые могут быть частью вашей дорожной карты и бюджета. Есть также реальная выгода: no-code миграция - это шанс сделать это “правильно”, основываясь на большом количестве накопленных знаний. В конце концов, с живым MVP, поддерживающим реальных пользователей и реальным пониманием вашего продукта, вы будете принимать гораздо лучшие решения о функциональности, выборе стека, интеграции и т. д. Создав no-code MVP вы, по сути, создали себе окончательную спецификацию программного обеспечения. Кроме того, имейте в виду, что MVP с пользовательским кодом не дает гарантии того, что кодовая база будет изящно эволюционировать в ваше приложение продукта. Подумайте о бесчисленных стартапах, которые создали свой MVP в пользовательском коде, затем развили его с помощью нескольких поворотов и в итоге получили дорогостоящий в обслуживании и громоздкий беспорядок кода-спагетти. Даже при самых благоприятных обстоятельствах в первые годы произойдет отток кода и рефакторинг, и большой процент вашего исходного кода MVP все равно будет заброшен.
В случае с кодом по сравнению с no-code лучше всего просто принять вероятность полной перестройки в будущем и включить это в свою дорожную карту. Это делает его математическим, а не техническим, что не так уж плохо.
Это может не всегда получаться, но когда это происходит, это выглядит так: Стоимость no-code MVP + затраты на последующую перестройку - накладные расходы на поддержание пользовательского кода = затраты на достижение цели.
Постарайтесь реалистично оценить, сколько денег требуется для создания и поддержки пользовательского кода — потенциальная экономия существенна. Если ваш no-code MVP запускается за 20 % от стоимости за 50 % времени, которое потребовалось бы для пользовательского кода, этот дополнительный бюджет может значительно повлиять на нетехнические усилия, такие как маркетинг или продажи. Экономия времени может означать выход на рынок первым или использование выгодных маркетинговых возможностей. Для компаний, которые финансируются самостоятельно, no-code может быть единственным способом получить достаточную поддержку, чтобы быть замеченным и в конечном итоге получить финансирование.
Необходимость в конечном итоге перестроить ваше приложение - не единственное важное соображение при использовании no-code MVP. Переход на no-code платформу означает, что ваша судьба связана с платформой, поэтому не забудьте оценить, насколько легко вы сможете покинуть платформу, когда придет время. Редко бывает простой способ справиться с этим, но такие вещи, как возможность Webflow экспортировать интерфейс в виде статического кода, могут значительно упростить задачу. Также убедительной является приверженность Bubble открытому исходному коду своей платформы, если компания когда-либо пойдет на спад, что предлагает систему безопасности, хотя и болезненную и громоздкую. Наиболее распространенные болевые точки, по моему опыту, менее драматичны и включают изменение структуры ценообразования, неуклюжую политику безопасности и бесконечную борьбу с громоздкими или ограниченными аспектами выбранной платформы.
А еще есть суровая реальность, что очень многим людям просто не нравится no-code. Ненавистников предостаточно. Скептицизм по поводу no-code по-прежнему распространен в мире стартапов, несмотря на иронию в том, что использование no-code для MVP четко вписывается в повсеместный подход к бережливому запуску. С другой стороны, конечные пользователи не знают или не заботятся о том, что находится под капотом, поэтому в конечном счете это может не иметь значения. Большая база пользователей и положительный доход говорят громче, чем ненависть к no-code, поэтому он остается простым способом продемонстрировать бизнес-модель. Инвесторы все более открыты для финансирования стартапа, но ожидайте некоторого отката и убедитесь, что ваши шаги включают в себя полный план перестройки в дорожной карте.
Должен ли основатель стартапа отказаться от кода для своего MVP - сложное решение со многими движущимися частями, но, в конце концов, оно сводится к одному вопросу: будут ли более быстрые и дешевые варианты no-code продвигать ваш стартап к успеху больше, чем инвестиции в пользовательский код? Если вы сможете переформулировать вопрос, включив в него менталитет запланированного устаревания и прагматичный взгляд на то, что может и не может сделать никакой код, это может оказаться выигрышным для вашего стартапа.
Источник: https://www.forbes.com/sites/forbestechcouncil/2021/09/24/a-ctos-perspective-on-no-code-mvps/?sh=28e309ad54b3