Zugo или Softr: портал на таблицах или свой код

Zugo или Softr: портал на таблицах или свой код

Softr собирает клиентский портал поверх уже существующей таблицы: данные остаются в ней, а интерфейс складывается из готовых блоков. Zugo по описанию генерирует сам проект с кодом, базой через Supabase и оплатой через Stripe, а исходники отдаёт в GitHub. Различие в том, где живёт логика.

Чем Zugo и Softr различаются по устройству?

Softr это надстройка над данными. У вас уже есть таблица с клиентами, заказами или объектами, и задача состоит в том, чтобы показать её нужным людям в удобном виде: списки, карточки, фильтры, права доступа. Интерфейс собирается из готовых блоков, а источником правды остаётся таблица.

Zugo это генератор проекта. Из описания получается настоящий сайт или приложение со своей структурой данных, своей логикой и своим кодом, который можно выгрузить в GitHub. Таблицу он не надстраивает, он создаёт базу.

Разница чувствуется в первый же день. В Softr вы думаете о том, какие поля показать и кому. В Zugo вы описываете продукт целиком, включая то, чего в таблице ещё нет.

Из этого следует и разное отношение к изменениям. В блочном конструкторе изменение вида это перестановка блоков, и предсказать результат легко. В билдере изменение вида это формулировка, и результат иногда шире задуманного.

В чём Softr объективно сильнее?

Данные уже на месте. Если рабочая таблица живёт в Airtable или в таблицах Google, портал поверх неё собирается за день, и переносить ничего не нужно. Это самый весомый аргумент, и он снимает половину работы.

Права и группы пользователей. Показать клиенту только его заказы, подрядчику только его задачи, а руководителю всё сразу это профильный сценарий Softr, разложенный по понятным настройкам. В Zugo такое разграничение делается через Supabase и требует более внимательной постановки задачи.

Обслуживание без разработчика. Правка содержимого это правка строки в таблице, и её делает любой сотрудник. Ничего пересобирать не надо.

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

В чём сильнее Zugo?

Свобода формы. Продукт не ограничен набором блоков: лендинг, многостраничная платформа, приложение с оплатой и браузерная 2D-игра выходят из одного и того же поля запроса.

Собственный код. Исходники выгружаются в GitHub, деплой можно увести на свой аккаунт Vercel. Проект остаётся вашим активом, а не арендованной конфигурацией.

Своя структура данных. База проектируется под задачу, а не подстраивается под существующую таблицу. Как это устроено, разобрано в статье про базу и вход через Supabase.

Оплата внутри продукта. Stripe подключается как часть проекта, поэтому подписка или разовая покупка живут там же, где остальное.

Скорость первой версии. Простая сборка занимает около минуты, многостраничная платформа несколько минут. Правка стоит 3 кредита и формулируется фразой.

Как выглядит сравнение по пунктам?

Свои цены называем прямо: Free даёт 5 кредитов, Pro стоит $25 в месяц за 200 кредитов, Business стоит $99 в месяц за 800 кредитов. Тарифы Softr меняются, сверяйте их на их сайте.

Где живут данные и кто их правит?

Это главный вопрос выбора, и он важнее любого списка функций.

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

Сценарий второй: данных пока нет, они появятся вместе с продуктом. Тогда таблица это лишний посредник. Проще сразу спроектировать базу под задачу, тем более что заявки, пользователи и заказы всё равно должны быть связаны между собой.

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

Есть и промежуточный путь: собрать витрину в Zugo, а внутренний учёт оставить в таблице. Данные тогда переносятся вручную или через выгрузку, и это осознанный компромисс, а не решение.

Что выбрать под конкретную задачу?

Если задача звучит как «личный кабинет с оплатой и закрытым разделом», посмотрите разбор в статье про сайт с закрытым доступом: там разложено, из каких частей он состоит.

Сколько стоит собрать и содержать такой проект?

У Zugo счёт идёт за действия. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 кредита за каждую следующую. На Pro 200 кредитов это примерно 16 полных платформ, или 33 быстрых сборок, или 66 правок в месяц.

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

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

Отсюда практический вывод. Если пользователей мало, а изменений много, дешевле счёт за действия. Если продукт стабилен, а людей в нём сотни, внимательно посчитайте стоимость по числу пользователей до начала работы.

Что происходит, когда портал перерастает блоки?

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

Первый признак: нужное поведение не описывается настройками. «Показать скидку только тем, кто оплатил два месяца подряд» это уже правило, а не фильтр. В конструкторе такие вещи обходят дополнительными полями в таблице, и через полгода никто не помнит, зачем их семь.

Второй признак: таблица начала обслуживать интерфейс, а не работу. Появляются служебные колонки вроде «показывать в разделе» или «сортировка вручную». Это верный знак, что данные и вид срослись, а разделить их потом будет дорого.

Третий признак: вы платите за пользователей, которых сами же приглашаете. Портал, который выгодно раздавать клиентам, и портал, где каждый новый клиент увеличивает счёт, ведут себя по-разному.

Что с этим делать. Пересобрать продукт как проект с собственной базой, где правило живёт в коде, а не в поле таблицы. Данные при этом переносятся выгрузкой, а старый портал стоит подержать доступным, пока новый не подтвердит, что работает.

Какие границы честно назвать у обоих?

У Zugo. Он не надстраивается над Airtable или таблицами Google: данные придётся заводить в базу проекта. Разграничение прав это отдельная работа, а не переключатель. Zugo не заменяет команду разработки на сложном продукте, специфичная логика доводится серией правок. Набор интеграций конечный: Supabase, Stripe, GitHub, Vercel, Resend, Google Analytics, свой домен.

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

Общее. Ни один инструмент не наведёт порядок в ваших данных и не придумает, зачем клиенту заходить в кабинет. Это работа, которая остаётся человеку.

Что делать дальше

Начните с вопроса о данных: они уже есть и живут в таблице, или их предстоит завести вместе с продуктом. Первый ответ ведёт к Softr, второй к Zugo. Всё остальное детали, которые проверяются за вечер.

Если ближе второй вариант, опишите задачу на zugo.dev: 5 кредитов бесплатного тарифа хватает на сборку и правку. Для внутренних инструментов посмотрите ещё разбор про сборку CRM: там те же вопросы про роли и данные, но на конкретном примере.