Содержание
Mottorable и Base44 можно сравнить на задаче личного кабинета: клиент входит, видит свои обращения и создаёт новое, а сотрудник обрабатывает назначенные записи. Для такого приложения особенно важен доступ к данным. Успешный вход не подтверждает, что один клиент не сможет прочитать обращение другого.
Сравнение ниже опирается на документацию и действующие данные продукта. Практический прогон двух генераций не выполнялся, поэтому здесь нет рейтинга качества или измеренной стоимости результата.
Сначала определите, чей это кабинет
Кабинет клиента и кабинет сотрудника решают разные задачи. Клиенту нужны свои обращения и ответы; сотруднику может требоваться общий список и распределение задач. Назначьте права чтения и изменения для каждой роли до генерации.
Для пилота достаточно двух вымышленных клиентов, сотрудника и нескольких обращений. Не подключайте реальные заказы, документы и оплату, пока не проверили основной маршрут и защиту записей.
Что подтверждается документацией
| Критерий | Mottorable | Base44 |
|---|---|---|
| Старт приложения | Задание в чате, последующие правки | Создание приложения с ИИ и доработка |
| Первое знакомство | без оплаты, без банковской карты | Действующие лимиты и планы проверяйте у Base44 |
| Код | В Бизнесе заявлено скачивание исходников | Документирована двусторонняя интеграция с GitHub, требуется Builder или выше |
| Правила доступа | Требуют постановки и проверки в созданном приложении | В платформе разработчика описаны правила доступа к строкам и полям |
| Подготовка кабинета | Есть сценарий личного кабинета | Структура данных и разрешения зависят от приложения |
Документация Base44 о GitHub описывает синхронизацию и условия плана. Эти сведения проверены 20 октября 2026 года; перед выбором сверьте их с текущими тарифами Base44. Актуальные цены и состав планов Mottorable смотрите на странице тарифов.
Раздел Base44 о безопасности сущностей различает доступ к записям и доступ к отдельным полям. Это возможности платформы разработчика, а не подтверждение настроек любого сгенерированного кабинета. Серверные функции с повышенными правами требуют собственных проверок доступа.
Подготовьте одинаковое задание
Создай учебный личный кабинет для обращений клиентов.
Роли: клиент и сотрудник поддержки.
Обращение: номер, тема, описание, автор, статус, ответ, дата создания.
Статусы: Открыто, В работе, Закрыто.
Клиент входит, читает только свои обращения и создаёт новое.
Сотрудник видит назначенные обращения и добавляет ответ.
Экраны: вход, мои обращения, создание, карточка обращения.
Используй вымышленных Клиента А и Клиента Б.
Клиент А не должен получить запись Клиента Б через прямую ссылку или запрос.
Защити чтение и изменение на сервере, а не только скрытием кнопок.
Сохраняй записи после обновления. Обработай пустые поля и повторную отправку.
Не подключай реальные письма, платежи и клиентские документы.
Если функция не реализована, явно укажи это.Адаптируйте задание и проверьте свою версию по критериям статьи.
Запустить ТЗ в MottorableСохраните одинаковые условия прогона: тариф, дату, исходное ТЗ и последовательность правок. Если одна платформа попросила уточнение, запишите его, чтобы было понятно, почему задания перестали совпадать.
Проверьте четыре разных вида доступа
Войдите клиентом А, создайте обращение и сохраните адрес карточки. Затем под клиентом Б проверьте чтение этой ссылки, поиск записи в списке и попытку изменения. После выхода из аккаунта повторите открытие.
Отдельно проверьте поля сотрудника: клиент не должен менять назначенного ответственного или внутреннюю заметку, если таких прав у него нет. Прямой запрос к данным важен не меньше видимости кнопки. Такой класс ошибок разобран в рекомендациях OWASP по доступу к объектам.
Проверки удобно записывать так:
| Действие | Ожидание |
|---|---|
| Клиент А открывает своё обращение | Запись доступна |
| Клиент Б открывает адрес обращения А | Чужие сведения не выдаются |
| Неавторизованный посетитель открывает карточку | Рабочие сведения закрыты |
| Клиент меняет внутреннее поле | Операция отклонена |
| Сотрудник отвечает на назначенное обращение | Ответ сохраняется и виден нужному клиенту |
Сравните условия дальнейшей работы
После доступа проверьте обновления и восстановление. Что происходит с обращениями после изменения формы? Как вернуть данные после ошибочного удаления? Можно ли получить записи и вложения в пригодном формате?
Выгрузка кода не заменяет выгрузку обращений. Для Mottorable также уточните соотношение заявленного скачивания исходников и ограничений пункта 5.3.9 оферты. Не планируйте самостоятельное размещение только по наличию кнопки экспорта.
Условия хранения, обработки запросов ИИ и внешних сервисов разберите отдельно для каждого выбранного варианта. Памятка есть в статье о данных и владении.
Принимайте решение по проверенному маршруту
В журнале сравнения отделяйте описание функции от собственного результата. Можно записать: «Документация предусматривает правило доступа; на нашей записи проверка ещё не выполнена». Отметка «не проверено» помогает не выдать ожидание за готовность к клиентскому запуску.
Добавьте фактический расход, время обязательных исправлений и поддержку по модели эксплуатации. Если кабинету нужны интеграции и доступы, которые команда не умеет проверять, подключите разработчика перед пилотом с рабочими сведениями.
Частые вопросы
Авторизация защищает все обращения автоматически?
Авторизация определяет пользователя. Доступ к каждой записи и действию задаётся отдельно и проверяется на сервере. Пройдите сценарии двух клиентов и неавторизованного посетителя.
Есть ли у Base44 правила доступа к данным?
В документации платформы разработчика описаны правила для записей и полей. Их наличие не доказывает, что конкретная генерация настроена правильно.
Какая платформа победила в тесте кабинета?
Сравнительный прогон не проводился. В статье приведены подтверждаемые возможности и одинаковое задание для собственной проверки.
Что потребуется до приглашения клиентов?
Проверенные права, сохранение, понятные ошибки, условия обработки данных и процедура обращения в поддержку. До этого используйте учебные аккаунты и вымышленные записи.