Как мы хотим создать Uber в мире low-code
Меня зовут Игорь Озеров, я основатель сервиса по подбору разработчиков и дизайнеров Swiftle. Хочу рассказать о том, как мы реализовываем low-code проекты и как мы превратились из обычной студии в сервис-платформу.
Большая часть Low- No-code решений полностью закрыта, то есть сам продукт размещается на серверах компании, ваш продукт построенный на этом продукте размещается на сервере компании, ваши данные и данные ваших пользователей находятся на все тех же серверах компании. По результату получаем такой жесткий вендорлок, которого даже в кровавом энтерпрайзе не встретишь.
Для проверки и тестирования гипотез - ок, но опять же, смотря на стоимость часа no-code разработчика, это не так уж и выгодно, потому что стоимость порой превышает косты сеньоров в 2, а иногда и в 3 раза. Скорость? Да, она существенно выше, но есть некоторая вероятность того, что стоимость будет примерно такая же как и классическая разработка. А если взять студентов говнокодеров то nocode начнет проигрывать по цене и возможно по срокам. Но что потом делать с говнокодом спросите вы? А что потом делать с непонятным продуктом, который вам не принадлежит и вы не можете свободно им распоряжаться?
Давайте по честному, чтобы сделать серьезный продукт нужно ответить на эти вопросы:
1. Что будет с продуктом если платформа закроется, сервера заблочатся, основатели улетят в далекую далекую галактику? Как вернуть свой продукт в который вы инвестировали свои миллионы (мы же о крупных и сложных системах говорим)?
2. Сценарий попроще, что делать с продуктом, если платформа в какой то момент перестанет развиваться? Как вносить критический фиксы безопасности?
3. Что будет если хакеры похитят данные ваших пользователей? Кто будет за это отвечать? Платформа или вы? Как снизить репутационные риски, когда от вас ничего не зависит?
4. Как вы думаете, что станет с вашим бюджетом на инфраструктуру когда у вас резко вырастет число пользователей и их активность в системе? Вы уверены что подрядчик сможет обеспечить хоть какую то кластеризацию по тому же геопризнаку?
5. GDPR и ФЗ-152 - что делать будем? И кто в данном случае будет оператором персональных данных? Как вы будете гарантировать пользователям что вся информация о них действительно удалена? А если она окажется не удалена и сохранится где то в недрах платформы и это вскроется - кто будет за это отвечать?
6. Что делать с рисками изменения условий обслуживания? Платформа решила резко увеличить косты, например в 3 раза, что делать в этом случае? Уйти на другую платформу невозможно и получается владельцы платформы могут делать из ваших яичек оригами?
7. Инвестиции всегда подразумевают их возврат - как вы будете продавать продукт, который вам не принадлежит? Кто согласится его купить?
Разложил по полочкам! Я как раз хотел уточнить у топикстартера, почему он называет типичный saas no-code решением, если произведенный продукт я не могу импортировать как самостоятельную единицу и использовать на собственной инфраструктуре?
Всеми руками поддерживаю!
На эти вопросы адепты no/low code предпочитают не отвечать.
Слишком меняется "картина мира" если признать, что no/low code это маркетинговая уловка наряду с бигдатой и блокчейном.
Гибридная разработка, блин! Хотя бы погуглили термин для смеха.
А на самом деле это просто очередной framework, выросший из инструментария разработчика, созданного на нескольких проектах. (ну не пропадать же добру)
Совершенно справедливые замечания. Тем более, что подавляющее большинство платформ не отдаст исходный код вашего приложения. Однако, есть ноу-лоу-код инструменты, которые отдают свой код - webflow, например. Но у него очень много ограничений.
Все перечисленные проблемы можно обойти, оставаясь в ноу-коде. Это Wappler. Он ставится на рабочий комп, и генерит чистый butstrap-код со всеми необходимыми js-библиотеками. Этот код вы можете в пару кликов оттуда же залить на Digital. Ocean или куда захотите с помощью докера. Там же вы можете добавить и базу данных, и автоматизации. Все это выглядит как привычный ноу-код, но на самом деле это ваш код, который можно на лету править прямо в редакторе.
Думаю, рано или поздно такие решения займут устойчивую долю на рынке. Потому что людям важно сохранять управление, что бы ни случилось с платформой.
Берёте n8n, nocodb, posgres/MySQL и ставите их на свои сервера. Не вижу проблемы)
Просто автор сразу же написал что решил зарабатывать на no code, отсюда нюансы
this guy do business
Если честно, касательно цены, мне кажется, что те ноукодеры о которых вы говорите, слабо предстпвляют себе рынок. Просто от балды дают ценник.
У меня в штате несколько разрабов мидлов. Мы пытались давать ценник 25-30$/час. На российском рынке вообще нерабочая расценка. Пока давали такие ставки - вообще продаж не было. Как немного просели по цене - сразу дело пошло.
Так что дороговизна No-code/Low-code разработки - это миф. Это просто люди нн понимающие рынок заламывают ценник, только и всего.
Здравствуйте, спасибо, что уделили время! Эти вопросы действительно часто задают наши клиенты, и вот что мы отвечаем:
1. Мы используем только проверенные собой сервисы, любой уважающий себя сервис предупредит о возможных издержках или проблемах (например закрытии). Например Bubble.io ни раз предупреждал о повышении цен на свои услуги. Мы также предоставляем возможность поддержки наших клиентов, а также возможный переход на полноценный код. Хочу заметить, что мы можем использовать в основе не low-code сервис, а обычный код, но дополнять его значимыми деталями в виде интеграций этих сервисов, поэтому здесь риски - минимальны.
2. Да, это действительно проблема, которую еще можно не сразу заметить и получить не малые издержки, в данном случае если система использует low-code сервисы, использовать ее в качестве прототипа для разработке ее на коде.
3. За потерю данных будет отвечать компания, кому принадлежит сайт. (Не сервис, где размещен этот сайт). Если компания уверенна, в своей невиновности и считает, что это уязвимость сервиса, она может подать иск.
4. Да, сможет. Но к сожалению, при большом количестве пользователей, если Ваша инфраструктура полностью завязана на сервисе "no-code", Вам придется перейти на код. Это связанно с тем, что большинство сервисов еще не научились оптимизировать приложения под большие нагрузки.
5. Сразу хочу предупредить, что я не совсем юрист. Однако наиболее используемый нами сервис спокойно поддерживает этот формат: https://bubble.io/blog/bubble-gdpr/
Что же касается Ф3-152, мы встречались с разными вариантами решения этой проблемы, однако не забывайте, что Ваша система может состоять лишь на 40% из внешних интеграций и проблем с этим пунктом не возникнет.
6. В данном случае, уйти на другие платформы все таки возможно. Не вижу причин, чтобы этого нельзя было сделать, однако обычному пользователю будет явно не приятен тот факт, что такое может произойти. Поэтому возвращаясь к первому пункту, использовать свое приложение - как прототип, и переходить на код.
7. У нас в статье приведен пример, ребят, которые тоже сделали приложение полностью на No-Code и привлекли инвестиции. Еще более глобальные примеры ребят, которые привлекли инвестиции: Plato(YC W16), Dividend($365M raised), Conet ($13M raised).
Однако мы не рекомендуем использовать только No-Code, мы понимаем. сложности масштабирования и поддержки, поэтому отталкиваемся исходя из запроса клиента. Если клиенту нужно быстро и дешево, мы предлагаем варианты, которые не очень масштабируются в будущем. Однако прекрасно подходят под MVP.