Softr: клиентский портал или сайт из таблицы без кода

Скажем, у тебя есть данные, которые и так ведутся в таблице — заказы клиентов, список учеников курса, каталог товаров, база заявок. И тебе нужно показать эти данные людям: чтобы клиент зашёл по логину и увидел только свои заказы, ученик — свои материалы, а партнёр — свой каталог. Классический путь — писать бэкенд, базу данных, авторизацию, фронтенд. Для новичка это недели работы даже с ИИ-ассистентом. Есть путь короче: Softr — no-code конструктор, который превращает таблицу в полноценный сайт с личными кабинетами без единой строки кода. Ниже разберём, что такое Softr, как он устроен, чем отличается от других конструкторов и когда он действительно экономит время.

Что такое Softr простыми словами

Softr — это конструктор веб-приложений и сайтов, который строится поверх готовых данных. Ключевая идея: данные у тебя уже есть — в Airtable, Google Таблицах, Notion или другом источнике (Softr поддерживает больше 15 вариантов подключения). Softr не заставляет тебя проектировать базу данных с нуля и писать серверную логику. Он берёт твою таблицу и превращает её в красивый сайт с кнопками, формами, поиском и личными кабинетами.

Проще говоря, таблица остаётся «мозгом» проекта — в ней живут записи, статусы, файлы. А Softr становится «лицом» — тем, что видит пользователь в браузере. Изменил строку в таблице — на сайте данные обновились. Клиент заполнил форму на сайте — в таблице появилась новая строка. Связь двусторонняя и работает без программирования.

Главная специализация Softr — именно клиентские порталы и сайты с личным кабинетом. Это его ниша, а не побочная возможность. Конструктор изначально заточен под сценарий «у меня есть люди, каждому из которых нужно показывать его собственный кусок данных». Клиент видит только свои заказы, ученик — только свои уроки, менеджер — только свои сделки. Именно за это Softr ценят небольшие студии, онлайн-школы, агентства и фрилансеры.

Чтобы не путать: обычный конструктор сайтов вроде Tilda или Wix умеет показывать всем одни и те же страницы — это витрина. Softr умеет различать, кто зашёл, и показывать каждому своё — это портал. Если тебе нужна просто страница-визитка, Softr избыточен. Если нужен сайт, куда люди заходят по логину и работают со своими данными, — это как раз его территория.

Ещё одно важное отличие — от самописной разработки, пусть и с ИИ-ассистентом. Когда Claude Code пишет тебе приложение, ты получаешь полную свободу: любой дизайн, любая логика, любой масштаб. Цена этой свободы — время на постановку задач, отладку, развёртывание и дальнейшую поддержку кода. Softr меняет эту сделку на противоположную: свобода ограничена готовыми блоками, зато рабочий результат появляется за часы и не требует поддержки кода вообще. Это не конкуренты, а разные точки на шкале «скорость против гибкости», и грамотный вайбкодер выбирает точку под задачу, а не один инструмент на всё.

Из чего состоит портал на Softr

Портал в Softr собирается из двух слоёв: источник данных и блоки интерфейса.

Источники данных

Первый слой — то, откуда приходят данные. Softr подключается к Airtable, Google Таблицам, Notion и другим источникам — всего больше 15 вариантов. Для новичка самые понятные два:

• Airtable — таблица на стероидах: в ячейках могут жить файлы, ссылки на другие записи, галочки, статусы. Хорошо подходит как основа портала.
• Google Таблицы — привычный всем формат, который почти наверняка уже используется в твоём проекте.

Если ты ещё не определился, как вообще устроены базы данных и чем таблица отличается от полноценной БД, загляни в статью Базы данных для новичка — там это разобрано на пальцах.

Как выбрать источник для старта? Если данные уже живут в Google Таблицах — начни с них, не переноси ничего заранее: портал соберётся поверх того, что есть. Если проект новый и таблицы ещё нет, присмотрись к Airtable: он изначально проектировался как основа для приложений, в нём удобнее связывать записи между собой — например, заказ с клиентом, а урок с учеником. Такая связность сильно упрощает настройку прав доступа дальше: «показать клиенту его заказы» работает через связь «заказ → клиент», а не через ручные фильтры.

Блоки интерфейса

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

• Списки — карточки записей: каталог товаров, список уроков, доска вакансий. С поиском, фильтрами и сортировкой.
• Таблицы — классическое табличное представление для тех, кому нужны строки и колонки.
• Формы — сбор данных от пользователей: заявка, заказ, отзыв, загрузка файла. Заполненная форма уходит обратно в твою таблицу новой записью.
• Канбан-доски — карточки по колонкам-статусам: «новые», «в работе», «готово». Удобно для заказов и задач.
• Диаграммы — визуализация чисел из таблицы: продажи по месяцам, статистика заявок.

Страница собирается перетаскиванием блоков, каждый блок привязывается к таблице и колонкам. Никакого кода — только настройки в боковой панели.

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

Формы заслуживают отдельного слова, потому что они превращают сайт из «витрины для чтения» в рабочий инструмент. Клиент не просто смотрит свои заказы — он оформляет новый через форму, прикрепляет файлы, оставляет комментарий. Заполненная форма становится новой строкой в твоей таблице, и дальше ты работаешь с ней привычным способом или запускаешь автоматизацию. Круг замыкается: данные идут из таблицы на сайт и с сайта обратно в таблицу, а ты остаёшься в привычной среде.

Права доступа: как работает личный кабинет

Самая важная часть Softr — разграничение прав. Без него получился бы просто сайт с общими данными, а с ним — настоящий портал.

Логика такая: ты определяешь типы пользователей (группы) и для каждого блока или страницы настраиваешь, кто что видит. Классический пример из практики — «клиент видит только свои заказы». В таблице заказов есть колонка с клиентом, у пользователя портала есть его аккаунт, и Softr при показе списка заказов фильтрует записи: каждому — только его строки.

Это решает задачу, которая в обычной разработке требует авторизации, сессий, запросов к базе с учётом прав и аккуратной проверки «а точно ли этот пользователь имеет право видеть эту запись». В Softr всё это настраивается галочками и правилами в интерфейсе. Для новичка, который пока не готов писать бэкенд с авторизацией сам, это огромная экономия времени и избавление от целого класса ошибок безопасности — ведь случайно показать чужие данные в самописном коде проще, чем кажется.

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

Права в Softr работают на двух уровнях, и полезно различать их с самого начала. Первый уровень — доступ к страницам: какие разделы портала вообще видны конкретной группе. Скажем, страница «Все заказы» доступна только менеджерам, а «Мои заказы» — всем вошедшим клиентам. Второй уровень — доступ к записям внутри страницы: двое клиентов открывают одну и ту же страницу «Мои заказы», но каждый видит в списке только строки, привязанные к нему. Именно второй уровень и есть тот самый личный кабинет: страница одна, содержимое у каждого своё.

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

От таблицы к порталу: как выглядит путь

Весь путь от «данные лежат в таблице» до «клиенты пользуются порталом» укладывается в простую цепочку:

flowchart TB
    A["Таблица данных: Airtable или Google Sheets"] --> B["Блоки Softr: список, форма, канбан"]
    B --> C["Права доступа пользователей"]
    C --> D["Опубликованный портал"]
    D --> E["PWA: установка на телефон в один клик"]

Разберём каждый шаг:

1. Готовишь данные. Приводишь таблицу в порядок: у записей должны быть понятные колонки, у клиентских записей — привязка к конкретному клиенту. Это самая «ручная» часть работы, и она в любом случае полезна.
2. Собираешь страницы из блоков. Добавляешь списки, формы, канбан-доски и привязываешь их к таблицам и колонкам.
3. Настраиваешь права. Заводишь группы пользователей и прописываешь, кто какие страницы и какие записи видит.
4. Публикуешь. Портал получает публичный адрес и начинает работать.
5. При желании — превращаешь в PWA (об этом ниже).

Никакого деплоя, серверов и настройки хостинга — публикация и обслуживание лежат на Softr.

Обрати внимание, чего в этой цепочке нет: нет шага «написать код», нет шага «настроить сервер», нет шага «поднять базу данных». Не потому, что они где-то спрятаны, а потому, что они не нужны: базой выступает твоя таблица, сервером — инфраструктура Softr, кодом — готовые блоки. Твоя работа смещается туда, где её нельзя отдать инструменту: решить, какие данные показывать, кому и в каком виде. Это и есть постановка задачи — тот самый навык, который курс тренирует на промптах для ИИ, только здесь «промптом» служит настройка блоков и правил.

PWA: приложение из портала в один клик

Приятный бонус: портал на Softr можно превратить в PWA — устанавливаемое веб-приложение — буквально в один клик. PWA (Progressive Web App) — это сайт, который пользователь может «установить» на телефон: на домашнем экране появляется иконка, открывается он без адресной строки браузера и ощущается как обычное приложение.

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

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

Автоматизация: workflows и связка с Make, Zapier, n8n

Портал редко живёт сам по себе: заявку надо обработать, клиенту — отправить письмо, менеджеру — уведомление в мессенджер. Для этого в Softr есть встроенные workflows — правила вида «когда произошло событие, сделай действие»: например, при отправке формы создать запись и уведомить ответственного.

Если встроенных сценариев не хватает, Softr подключается к внешним сервисам автоматизации — Make, Zapier и n8n. Там строятся цепочки посложнее: новая заявка из формы → создать сделку в CRM → отправить клиенту письмо → написать уведомление в чат команды. Про n8n у нас уже есть отдельный разбор — n8n: автоматизация без кода; если ты его освоил, связка «Softr + n8n» покроет почти любой сценарий: Softr отвечает за интерфейс и данные, n8n — за логику и интеграции.

Как разумно делить работу между ними? Правило такое: всё, что видит и нажимает пользователь, — это Softr (страницы, формы, кнопки, кабинет). Всё, что должно происходить «само» после действия пользователя или по расписанию, — это workflows или внешняя автоматизация. Клиент отправил заявку через форму — это Softr. Дальше заявка улетает менеджеру в уведомление, а через день без реакции — напоминание — это уже территория автоматизации. Такое разделение держит систему понятной: в конструкторе не разрастается непрозрачная логика, а в автоматизаторе не пытаются рисовать интерфейсы.

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

Тарифы: что важно знать

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

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

Как понять, что пора переходить на платный? Сигналы честные и измеримые: число пользователей или записей приблизилось к лимиту бесплатного тарифа, клиенты реально пользуются порталом каждую неделю, а не зашли один раз из вежливости, и портал уже приносит пользу проекту — экономит твоё время или помогает продавать. Если всё это сходится, подписка — не расход «на красивый сайт», а стоимость работающего инструмента. Если не сходится — портал пока остаётся экспериментом, и бесплатного тарифа достаточно.

Чем Softr отличается от AppSheet и других конструкторов

На курсе мы уже разбирали похожие инструменты, и важно не путать их ниши.

Softr против AppSheet. AppSheet (разбор здесь) тоже делает приложение из таблицы, но заточен под внутренние рабочие инструменты для сотрудников: учёт, инвентаризация, полевые отчёты. Он живёт в экосистеме Google и опирается на Google Таблицы, а результат выглядит как служебное приложение для команды. Softr заточен под клиентские порталы и сайты с логином: работает с более широким набором источников данных, включая Airtable, и результат выглядит как полноценный публичный сайт, а не внутренняя утилита. Коротко: AppSheet — «инструмент для своих», Softr — «кабинет для клиентов».

Softr против универсальных no-code платформ. В обзоре no-code и low-code платформ 2026 мы смотрели на Bubble, FlutterFlow и другие конструкторы, которые позволяют строить почти произвольные приложения с собственной логикой и базой. Это гибче, но заметно сложнее и дольше. Softr занимает конкретную нишу «портал из таблицы» и в ней выигрывает за счёт скорости: то, что на универсальной платформе собирается неделями, здесь часто собирается за вечера — ценой меньшей свободы в логике и дизайне.

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

Кому Softr подходит, а кому нет

Честная рамка важнее восторгов, поэтому разложим по полочкам.

Softr подходит, если:

• данные уже ведутся в таблице (Airtable, Google Таблицы, Notion) или ты готов вести их там;
• нужен сайт, куда люди заходят по логину и видят каждый своё — заказы, уроки, документы, статусы;
• скорость запуска важнее уникальности: проверить идею на живых пользователях нужно за дни, а не за месяцы;
• команда маленькая или ты один, и содержать самописный бэкенд некому.

Softr не подходит, если:

• данных в таблице ещё нет и самого процесса нет — портал строится поверх данных, а не вместо них;
• нужна нестандартная логика, которой нет в готовых блоках: сложные расчёты, необычные сценарии взаимодействия, уникальный интерфейс — здесь разумнее универсальная no-code платформа или полноценная разработка с ИИ-ассистентом;
• нужен внутренний инструмент для сотрудников на Google Таблицах — для этого профильнее AppSheet;
• проект быстро вырастет за пределы тарифов, а стоимость подписки критична — лимиты по записям и пользователям стоит прикинуть заранее.

Хорошая новость: выбор Softr — не билет в один конец. Данные остаются в твоей таблице, а не заперты внутри конструктора. Если проект вырастет из no-code, таблицу можно перенести в полноценную базу данных и построить на ней собственный сервис — тот же путь, который курс проходит с Supabase в пятом модуле. Портал на Softr в этом сценарии становится не тупиком, а быстрой первой версией, которая проверила спрос.

Зачем Softr вайбкодеру: сценарии применения

Где это реально пригодится тебе на курсе и после него:

• Личный кабинет учеников. Запустил платный мини-курс или мастер-класс? Таблица с учениками и материалами + Softr = кабинет, где каждый ученик видит свои уроки и файлы. Без написания бэкенда.
• Портал для клиентов побочного проекта. Делаешь услуги — дизайн, монтаж, консультации? Клиент заходит и видит статус своего заказа, сдаёт правки через форму, скачивает готовые файлы. Выглядит как серьёзная компания, собирается из таблицы заказов.
• Витрина с приёмом заявок. Каталог товаров или услуг из таблицы + форма заказа, которая падает обратно в таблицу. Дальше заявки разбираешь сам или через автоматизацию.
• Внутренний каталог или база знаний для небольшой команды — когда Google Таблица уже неудобна, а писать сервис рано.

Общий паттерн во всех сценариях: данные уже ведутся в таблице, и недостаёт только «лица» для людей. Если таблицы ещё нет и данных тоже — Softr не отправная точка: сначала появляется процесс и данные, потом портал.

Заметим, как это стыкуется с тем, что ты уже умеешь после курса. «Змейка» из учебных модулей хранит рекорд в localStorage — данные живут только в браузере одного пользователя. Пятый модуль переносит рекорды в Supabase, и появляется общая таблица, видимая всем. Softr — следующий логический шаг той же лестницы, но в сторону бизнеса: данные лежат в таблице, а каждый пользователь видит строго свой срез. Меняется инструмент и масштаб задачи, но идея та же самая — сначала данные, потом интерфейс поверх них, потом права доступа.

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

С чего начать: первый портал за вечер

Практический план первого знакомства:

1. Выбери самый простой сценарий. Не «портал мечты», а одна страница: например, список уроков из таблицы, доступный только по логину.
2. Приведи таблицу в порядок. Понятные названия колонок, у клиентских записей — колонка с владельцем. Половина качества будущего портала решается здесь.
3. Собери страницу из блоков. Список для показа данных, форма для приёма — этого хватит на первую версию.
4. Настрой права доступа. Заведи тестового «клиента» и проверь главное: он видит только свои записи. Проверь и обратное — выйди из аккаунта и убедись, что гость не видит лишнего.
5. Опубликуй и дай ссылку одному живому человеку. Реальный пользователь за пять минут найдёт больше непонятных мест, чем ты за вечер самостоятельных кликов.
6. Включи PWA, если порталом будут пользоваться с телефона — это один клик, а восприятие меняет сильно: вместо закладки в браузере у клиента появляется иконка приложения.

Только после того, как пилот заработал и лимиты бесплатного тарифа реально мешают, имеет смысл смотреть на платные планы.

Типичные ошибки первого портала

Несколько грабель, на которые наступают почти все новички при сборке первого портала из таблицы:

• Начинать с интерфейса, а не с данных. Если в таблице бардак — дубли, пустые колонки, заказы без привязки к клиентам, — никакой конструктор это не спасёт: портал честно покажет бардак каждому пользователю. Сначала порядок в данных, потом блоки.
• Пытаться собрать всё сразу. Личный кабинет, каталог, блог, форум и чат в первой версии — верный способ не запуститься никогда. Одна страница, один сценарий, один тип пользователя — и в бой.
• Не проверить права чужими глазами. «Клиент видит только свои заказы» надо проверять за тестового клиента, а не из аккаунта владельца — владельцу-то видно всё. Заведи второй тестовый аккаунт и убедись, что он не видит записи первого.
• Игнорировать телефон. Клиенты чаще всего откроют портал с мобильного. Проверь, как страницы выглядят на узком экране, и включи PWA — это один клик.
• Покупать платный тариф заранее. Бесплатного хватает на пилот. Плати, когда упёрся в реальный лимит, а не в воображаемый.

Частые вопросы

Чем Softr отличается от обычного конструктора сайтов?

Обычный конструктор показывает всем посетителям одни и те же страницы — это витрина. Softr умеет различать пользователей по логину и показывать каждому его данные из таблицы — заказы, уроки, документы. То есть он строит не витрину, а портал с личными кабинетами, и в этом его основная ниша.

Нужно ли уметь программировать, чтобы собрать портал на Softr?

Нет. Страницы собираются из готовых блоков — списков, таблиц, форм, канбан-досок, диаграмм — а права доступа настраиваются правилами в интерфейсе. Код не нужен ни для сборки, ни для публикации: хостинг и обслуживание берёт на себя сам сервис. Умение ясно сформулировать, что должен видеть каждый тип пользователя, важнее любых технических навыков.

Какие источники данных можно подключить?

Airtable, Google Таблицы, Notion и другие — больше 15 вариантов. Для старта чаще всего берут Airtable или Google Таблицы: первый удобнее как основа приложения со связанными записями, вторые обычно уже есть в проекте и не требуют переноса данных.

Есть ли у Softr бесплатный тариф?

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

Можно ли сделать из портала приложение для телефона?

Да. Портал превращается в PWA — устанавливаемое веб-приложение — в один клик: у клиента на домашнем экране появляется иконка, и сервис ощущается как обычное приложение, без публикации в магазинах.

Когда Softr — плохой выбор?

Когда данных в таблице ещё нет, когда нужна сложная нестандартная логика, которой нет в блоках, или когда нужен внутренний инструмент для сотрудников на Google Таблицах — тогда ближе AppSheet или универсальные no-code платформы. Подробнее рамка разобрана в разделе «Кому Softr подходит, а кому нет».

Заключение

Softr закрывает конкретную и очень частую задачу: превратить таблицу с данными в сайт, где у каждого пользователя есть свой личный кабинет. Таблица остаётся источником данных, блоки собирают интерфейс, права доступа решают «кто что видит», публикация не требует серверов, а PWA делает из портала приложение в один клик. Автоматизация — встроенными workflows или связкой с Make, Zapier и n8n — доводит портал до полноценного рабочего процесса.

Для вайбкодера это быстрый способ дать своему проекту «лицо» для клиентов — кабинет учеников, портал заказов, витрину с заявками — не погружаясь в бэкенд-разработку. При этом навыки курса никуда не деваются: умение ставить задачи, работать с данными и проверять результат пригодится и здесь, а если проект вырастет из no-code, данные из таблицы переедут в полноценную базу, и на смену конструктору придёт собственный код, написанный вместе с ИИ.

Начни с бесплатного тарифа и одного простого сценария: если данные уже живут в таблице, первый работающий портал — это вопрос одного вечера.