Почему через 3 года 80% no-code проектов будут убыточными

...и что сделать, чтобы ваш был в оставшихся 20%

Из каждого утюга слышно: "Запусти MVP за выходные", "Не плати разработчикам", "Собери свой Uber на коленке". Правда в том, что к успеху придут в лучшем случае 20% бодро стартовавших проектов. Как не ошибиться в расчётах на старте и не сгореть за пару лет?

Наблюдая за рынком, видим не только радугу — есть то, что вызывает тревогу. Проекты, запущенные на эйфории 2022-2023 годов, начинают умирать. Не потому, что идеи у них плохие или руки непрямые. И деньги тоже не всегда причина. Они умирают потому, что попадают в ловушку масштабирования, когда поддерживать ноукод-решение становится дороже, чем нанять в команду разрабов.

Разберем три главные причины, почему математика ноукода перестает сходиться, и как не пополнить кладбище проектов.

Ноукод продает нам дешёвый старт. $59 за Bubble, $9 за Make (бывший Integromat), бесплатный Airtable. Кажется, что так будет всегда. Проблема в том, что в классической разработке на коде при росте нагрузки ваши расходы растут линейно, а в ноукоде — экспоненциально.

И в том же Bubble вы начали с $59, но количество заказчиков растёт, приложения развиваются, и вот внезапно обнаруживается, что 4 недели ещё не закончились, а вы уже вышли из лимита в 500 000 WU. И пора перебираться на Enterprise, который стартует примерно с $2000 в месяц.

Для сравнения: VPS-сервер, который способен переварить этот же объем на Python/Go, стоит около $20-40 в месяц.

И здесь есть хитрая ловушка: маржинальность вашего бизнеса падает по мере его роста. Каждый новый пользователь обходится дороже предыдущего из-за особенностей тарификации ноукод-платформ. Вы платите налог на простоту.

Главный плюс ноукода это гибкость: захотел — добавил фичу за 5 минут. Ну а главный минус — отсутствие дисциплины. В коде (мы не имеем в виду говнокод) есть стандарты, ревью, модульность. В no-code обычно царит принцип “лишь бы работало”. А потому через несколько месяцев активной разработки проект может превратиться в монструозный клубок из вебхуков, костылей и заплаток.

Сложность изменений: чтобы добавить одну кнопку, нужно 3 дня разбираться с тем, как это связано с остальными 50 сценариями.

Bus Factor = 1: если из проекта уйдёт один человек, который собирал его и знает о нём всё (чаще всего это сам фаундер или фрилансер-одиночка), то можно закрываться. В этом хаосе никакой внешний эксперт не станет разбираться — проще и дешевле сделать с нуля.

В итоге, вместо масштабирования бизнеса, вы занимаетесь бесконечным тушением пожаров в сценариях, которые ломаются от каждого чиха.

Представьте, что вы построили роскошный особняк. Но земля под ним принадлежит дяде, который может завтра поднять аренду в 10 раз или вообще сказать: “Съезжай, я продаю участок”. Именно так проявляется в реальности Vendor Lock-in (зависимость от поставщика).

Когда вы пишете на чистом коде (JS, Python, PHP), ваш актив принадлежит вам. Вы можете перенести его на другой сервер, сменить хостинг, отдать другим разработчикам.

В no-code вы арендуете технологии. И всегда зависите от того, сколько стоит разработка на платформе, во сколько обойдётся переезд с неё (такая опция если и доступна, то обычно на старших тарифах).

Если платформа закроется, заглючит или попадет под санкции (заблокирует доступ пользователям из РФ) — ваш бизнес остановится мгновенно. И у вас не будет бэкапа, который можно развернуть на своем сервере.

Конечно, от no-code отказываться не нужно. И было бы странно, если бы именно мы вдруг начали к этому призывать :) Но подходить к нему нужно с холодной головой.

Чтобы ваш проект не утонул в техническом долге и счетах за подписку, придерживайтесь трех правил «Здорового Ноукода».

Перестаньте складывать все яйца в одну корзину. Самая устойчивая схема сейчас выглядит так:

В чем профит?

Если Bubble завтра поднимет цены в 5 раз, вы просто меняете фронтенд (условно, переверстываете интерфейс на WeWeb или пишете на React), а вся ваша база пользователей, логика и данные остаются в безопасности на бэкенде. Вы больше не заложник.

Считайте Unit-экономику не на старте, а в масштабе. Задайте себе главный вопрос: "Сколько мне будет стоить обслуживание одного пользователя, когда их станет 10 000?"

Если на старте ваша маржа 90%, а при масштабировании она падает до 10% из-за стоимости операций в Make, — это не бизнес, а благотворительность в пользу ноукод-платформ. В этом случае нужно сразу закладывать бюджет на кастомную разработку узких мест (например, написать один скрипт на Python за $200, который заменит 50 000 операций в Make).

No-code — это идеальный разгон. Но вы должны знать, где финиш.

Определите метрику, после которой вы начинаете переписывать проект на код. Вот примеры:

Это убережет вас от момента, когда переписывать уже поздно, потому что система слишком сложная, а поддерживать текущую — невозможно дорого.

No-code перестал быть игрушкой и стал мощным инструментом бизнеса. Но молоток может и дом построить, и пальцы переломать. Всё зависит от того, в чьих он руках.

Те 80% проектов, что закроются, — это жертвы иллюзии и жажды халявы. Оставшиеся 20% — это те, кто использует no-code как инженерный инструмент: с расчетами, правильной архитектурой и планом "Б".

А вы считали, во сколько вам обойдется ваш проект через год активного роста? Или предпочитаете не расстраиваться заранее? Пишите комментарии или в личку - обсудим ;) И присоединяйтесь к движу на нашем канале в Телеграм!