Архитектура no-code приложения: как продумать структуру до сборки

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

Кстати, на этапе проектирования больше всего времени съедает жонглирование сервисами: в одном окне формулируете сущности, в другом рисуете экраны, в третьем пишете описание для подрядчика. В Zerocoder 25+ нейросетей живут в одном рабочем пространстве — работают из России без VPN, оплата российскими картами, а при регистрации начисляются бесплатные кредиты, которых хватает на черновик документа и первые прототипы.

1. Почему в no-code проектируют до сборки, а не «по ходу»

Грамотная архитектура no-code приложения — это фундамент, который определяет, будет ли ваша система работать стабильно или «рассыплется» при появлении сотого пользователя. В традиционном программировании разработка структуры базы данных и проектирование API стоят в первом ряду задач. В no-code легкий порог входа создает иллюзию, что можно сразу переходить к сборке UI-элементов. Однако цена поздних изменений в no-code часто оказывается даже выше, чем в традиционном коде, из-за ограниченных инструментов автоматической миграции данных в визуальных платформах.

Цена поздней правки: что происходит при смене типа поля и структуры связей

Когда вы создаете поле типа «Текст» для хранения даты или статуса, а спустя месяц решаете изменить его на «Дата» или «Связь с таблицей», платформы вроде Bubble или Adalo не могут автоматически конвертировать накопленная значения. Вам приходится вручную экспортировать CSV-файлы, очищать базу, менять тип поля, заново создавать связи и переписывать все динамические выражения на каждом экране. Ошибка в одной связи на этапе чертежа стоит 15 минут размышлений, а после запуска — 20–30 часов рутинной технической работы.

Три признака, что структура не продумана

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

2. Что такое архитектура приложения: пять слоёв на одном листе

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

Терминологический минимум, который пригодится при проектировании:

• Сущность — объект реального мира, который хранится в базе (например, «Пользователь», «Заказ», «Услуга»).
• Атрибут (поле) — конкретная характеристика сущности (например, «Цена», «Статус», «Email»).
• Связь — логическое соотношение между объектами двух таблиц.
• Роль — наборы прав доступа для конкретной группы пользователей.
• Вебхук — механизм мгновенного уведомления одного сервиса о событиях в другом через HTTP-запрос.

Данные — какие сущности и как связаны

Нижний слой архитектуры — модель данных. В ней фиксируются все таблицы (сущности), их типы полей и правила взаимодействия между собой. Если этот слой спроектирован некорректно, все верхние слои будут работать со сбоями.

Логика — что происходит и по какому триггеру

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

Интерфейс — экраны и переходы

Слой UI/UX описывает пользовательский путь (User Flow) и структуру экранов. Он показывает, какую информацию видит пользователь на каждом шаге и куда переходит после совершения действия.

Доступы — кто что видит и меняет

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

Интеграции — что приложение не делает само

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

3. Шаг 1. Сформулировать продукт и вытащить сущности

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

Одно предложение по формуле «кто → что делает → чтобы»

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

Из user stories в список существительных

Запишите 3–5 основных пользовательских историй (User Stories) и выделите в них все существительные. В 90% случаев именно существительные становятся будущими таблицами базы данных:

«Клиент выбирает Услугу конкретного Мастера, находит свободный Слот в расписании, создает Запись и оставляет Отзыв после визита».

Пример разбора: сервис записи к мастеру

Из приведенного примера выписываем шесть базовых сущностей, которые образуют модель данных сервиса:

1. Пользователь (Клиент / Мастер): хранит профиль, контактные данные и роль.
2. Мастер: расширенный профиль специалиста (описание, опыт, рейтинг).
3. Услуга: наименование, длительность, стоимость.
4. Слот: дата, время начала, время окончания, статус доступности.
5. Запись (Заказ): связывает клиента, мастера, услугу и конкретный слот.
6. Отзыв: оценка, текст, привязка к записи.

4. Шаг 2. Схема данных: таблицы, поля, связи

Схема данных no-code приложения — это список сущностей, их полей и связей между ними; для MVP обычно достаточно 5-9 сущностей и трёх типов связей. Задача этого шага — превратить абстрактные существительные в строгую техническую структуру.

Таблица полей: имя, тип, обязательность, значение по умолчанию

Для каждой сущности создается карточка с полем каждого типа. Ниже представлен пример описания сущности «Запись» для сервиса услуг:

Три типа связей на человеческом языке

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

• Один к одному (1:1): У одного «Пользователя» может быть только один «Паспортный профиль». В no-code это часто объединяют в одну таблицу, если нет жестких требований к безопасности.
• Один ко многим (1:M): У одного «Мастера» может быть много «Услуг», но конкретная «Услуга» принадлежит только одному мастеру. Это самый частый тип связи.
• Многие ко многим (M:M): Один «Заказ» может включать много «Услуг», и одна «Услуга» может входить в тысячи разных «Заказов».

Как обойти «много:много» там, где платформа это не умеет

Некоторые визуальные конструкторы плохо работают со связями M:M напрямую (или делают базы медленными). Стандартное архитектурное решение — создание связующей таблицы (Junction Table). Вместо прямой связи «Заказ ↔ Услуга» создается промежуточная сущность «Позиция_Заказа», где каждая строка хранит ссылку на один заказ и ссылку на одну услугу.

Справочники и статусы вместо свободного текста

Никогда не используйте текстовые поля для статусов вроде «Новый», «В работе», «Завершен». Ввод текста вручную или через разные формы приводит к опечаткам («завершен» vs «Завершено»), из-за чего ломается фильтрация списков. Используйте только Option Sets (перечисления / Enum). Текст меняется в одном месте — и обновляется по всему приложению.

Когда дублировать данные — это нормально (денормализация)

В классическом программировании правила нормализации запрещают дублировать данные. В no-code денормализация часто необходима ради скорости загрузки экранов и сохранности истории. Пример: стоимость услуги в карточке мастера может измениться с 3000 до 4000 рублей. Если в старом заказе хранилась только ссылка на услугу, сумма старого заказа задним числом изменится. Поэтому в момент создания заказа поле total_price копирует текущую цену текстовым или числовым значением.

Что заложить сразу: системные поля

Каждая таблица в любом no-code приложении с первого дня должна содержать четыре системных поля: created_at (дата создания), updated_at (дата обновления), created_by (автор) и is_deleted (флаг мягкого удаления Soft Delete). Удалять записи из базы физически — плохая практика: вы потеряете аналитику и разрушите связанные данные.

5. Шаг 3. Роли и матрица прав

Настройка доступов — самый критичный слой безопасности. Попытка добавить роли «как-нибудь потом» приводит к тому, что клиент видит чужие заказы или административные кнопки на своем экране.

Три-четыре роли максимум на MVP

Не усложняйте ролевую модель на старте. Для большинства сервисов достаточно четырех базовых ролей:

1. Гость (Аноним): видит лендинг, каталог услуг, ценники и форму регистрации.
2. Пользователь (Клиент): видит свои заказы, свой профиль, может создавать новые записи и отменять их.
3. Исполнитель (Мастер): видит только назначенные на него записи, свое расписание и свой доход.
4. Администратор: имеет полный доступ к просмотру и редактированию всех таблиц приложения.

Матрица «роль × сущность × действие»

Перед настройкой платформ составьте табличную матрицу прав (CRUD: Create, Read, Update, Delete):

Частая дыра: безопасность в UI vs Privacy Rules в базе

Скрытие кнопки «Удалить» в визуальном редакторе не защищает данные. Опытный пользователь может открыть консоль разработчика и отправить REST API запрос к вашей базе данных напрямую. Безопасность должна быть настроена на уровне бэкенда (Privacy Rules в Bubble, Row Level Security в Xano или Supabase). Если компания создает внутренние инструменты для компании, утечка реестра клиентов через незащищенный API приведет к серьезным репутационным и юридическим последствиям.

Персональные данные и 152-ФЗ

Для проектов, работающих в РФ, важно помнить о требованиях 152-ФЗ. Паспортные данные, сканы документов и полные банковские реквизиты лучше вообще не хранить на первых этапах внутри базовых платформ, если их серверы находятся за пределами РФ. Используйте специализированные российские сервисы хранения или минимизируйте запрашиваемый состав данных на этапе MVP.

6. Шаг 4. Карта экранов и переходы

Карта экранов показывает путь пользователя (User Flow) и логику переходов. Проектирование экранов должно идти после схемы данных, так как каждый экран опирается на конкретные сущности и поля.

Правило одного действия на экран

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

Минимальный набор экранов для MVP

Для большинства веб- и мобильных сервисов базовый стек экранов состоит из 6 типовых блоков:

• Авторизация / Регистрация: входы по SMS, Email или соцсетям.
• Дашборд / Главная: список основных категорий или текущих активных заказов.
• Экран детализации (Карточка): детальный просмотр одной сущности (мастера, услуги, товара).
• Форма ввода / Создания: шаг оформления записи или отправки заявки.
• Профиль и настройки: редактирование личных данных и просмотр истории.
• Панель управления (Админка): реестр всех данных для модератора.

При этом важно заранее решить технический формат проекта: если вы сомневаетесь, стоит ли делать приложение под iOS/Android или остановиться на веб-версии, прочитайте разбор мобильное приложение или веб — в чём разница. Чтобы быстро визуализировать логику интерфейса на старте, можно собрать черновой прототип экрана из описания с помощью ИИ-инструментов.

Happy path и три граничных случая

Основатели часто проектируют только «идеальный путь» (Happy Path), когда пользователь нажимает нужные кнопки, интернет работает быстро, а в базе есть все данные. Но хорошая архитектура учитывает три обязательно возникающих состояния:

1. Empty State (Пустое состояние): пользователь впервые зашел в раздел «Мои записи». Вход не должен показывать пустой белый экран — покажите понятную иллюстрацию и кнопку «Записаться на услугу».
2. Error State (Ошибка): пропала связь с сервером или отклонен платеж. Пользователь должен получить понятное сообщение и кнопку повторной попытки.
3. No Access State (Нет прав): попытка перейти по прямой ссылке в админку должна отправлять на страницу авторизации с предупреждением.

7. Шаг 5. Границы логики: что внутри платформы, а что вынести наружу

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

Что делать внутри платформы

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

Что выносить во внешние сервисы

Внешние сценарии необходимы там, где требуется сложная фоновая обработка или интеграции с несколькими системами:

• Отправка триггерных рассылок (Email, Telegram, SMS).
• Регулярные тяжелые отчеты и ночные пересчеты аналитики.
• Обработка вебхуков от платежных систем.
• Запросы к нейросетям и сложным алгоритмам.

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

Отдельный бэкенд: когда стандартного конструктора недостаточно

Если проект предполагает работу с сотнями тысяч записей, сложными правилами обработки данных или планирует выходить на несколько фронтенд-платформ (веб + мобильные приложения), стандартной встроенной базы конструктора станет недостаточно. В таких случаях выстраивают архитектуру с отдельным бэкендом (например, на Xano или Supabase). Узнать подробнее о подходе с вынесенной базой логики вы можете из нашего материала обзор Directual с сильным бэкендом.

8. Шаг 6. Интеграции под российский проект

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

Платежные системы: СБП, карты РФ и самозанятые

Для приема платежей в РФ в схему данных обязательно закладываются сущности «Платёж» и «Чек». Онлайн-эквайринги (ЮKassa, T-Bank, CloudPayments) работают по схеме двустороннего вебхука. База данных должна быть готова принять статус платежа asynchronously (асинхронно). Также важно продумать статус чека (54-ФЗ), чтобы автоматически отправлять его клиенту после успешной транзакции.

Доступ к сервисам без VPN

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

Уведомления: Telegram-боты вместо дорогих SMS

SMS-авторизация и уведомления сегодня стоят дорого. Оптимальная архитектура MVP в РФ предполагает каскадное отправление сообщений: сначала бесплатный PUSH в приложение или сообщение в Telegram-бота, и только при отсутствии доставки — SMS-сообщение.

ИИ-функции в приложении

Если ваш сервис использует генеративный ИИ (например, для автосоздания описания услуг или умного поиска), заложите в базу данных сущность «AI_Log». В ней фиксируются: отправленный промпт, полученный ответ, потраченные токены и ID пользователя. Это позволит вам контролировать расходы на API ИИ-провайдеров. О том, как внедрить нейросети в архитектуру проекта, читайте в руководстве как ИИ усиливает функциональность no-code приложений.

9. Подбираем стек под уже готовую схему (а не наоборот)

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

Детальный разбор критериев подбора инструментов доступен в нашей отдельной статье как выбрать no-code-платформу под проект. Если же вы заранее определились, что ваш выбор — команда специалистов, на Маркетплейсе Zerocoder всегда можно найти квалифицированных специалистов по Bubble.

10. Документ архитектуры за один вечер: шаблон и ИИ-промпты

Документ архитектуры (Solution Architecture Document) — это простой текстовый файл на 1–3 страницы, который содержит исчерпывающее описание будущего приложения. Наличие такого файла экономит до 50% времени при сборке самостоятельно или при передаче ТЗ подрядчику.

7 блоков шаблона архитектурного документа

1. Описание продукта: цель, аудитория, ключевая формула сервиса.
2. Ролевая модель: список ролей и матрица прав доступа (CRUD).
3. Схема данных: список таблиц, полей, типов данных и связей.
4. Карта экранов: перечень страниц с их назначением и основными элементами.
5. Границы логики: сценарии автоматизации, триггеры, действия.
6. Интеграции: платежи, уведомления, сторонние API.
7. Технические ограничения: требования к гео-локации, скорости и 152-ФЗ.

Три ИИ-промпта для проектирования архитектуры

Вы можете существенно ускорить подготовку документа, используя промпты для нейросетей в нейропространстве Zerocoder.

Промпт 1. Выделение сущностей и связей из описания:

Я создаю no-code приложение со следующим функционалом: [вставьте краткое описание идеи].
Действуй как шеф-архитектор no-code приложений. Выдели из описания все необходимые сущности (таблицы) базы данных. Для каждой сущности укажи:
1. Название таблицы (на английском).
2. Список полей с указанием типов данных (Text, Number, Date, Boolean, Option Set, Link).
3. Связи между таблицами (1:1, 1:M, M:M).
Ответ оформи в виде четких структурных таблиц.

Промпт 2. Поиск скрытых дыр в схеме данных:

Вот моя схема данных: [вставьте список таблиц и полей].
Действуй как Senior QA инженер no-code проектов. Найди слабые места в этой схеме:
1. Каких полей не хватает для нормальной работы?
2. Где возникнут проблемы при удалении или изменении данных?
3. Какие статусы забыты для основных процессов?
Дай конкретные рекомендации по исправлению.

Промпт 3. Генерация матрицы прав доступа:

В моем приложении есть следующие роли: [список ролей] и таблицы: [список таблиц].
Составь матрицу прав доступа в формате таблицы CRUD (Create, Read, Update, Delete) для каждой роли к каждой сущности. Укажи граничные условия (например, "пользователь может читать только свои записи").

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

11. Девять ошибок, которые ломают архитектуру

Практический опыт сдачи десятков MVP позволяет выделить девять повторяющихся ошибок проектирования, совершаемых новичками:

• Одна таблица на всё: попытка запихнуть данные клиента, его заказов и мастера в одну огромную таблицу приводит к полному хаосу при фильтрации.
• ФИО одним полем: сохранение «Иванов Иван Иванович» в одной строке делает невозможной нормальную персонализированную рассылку («Здравствуйте, Иван!»). Разделяйте Имя и Фамилию.
• Удаление вместо архивации: физическое удаление строк разрушает привязанные исторические данные. Используйте флаг is_deleted.
• Статусы текстом: опечатка в слове «Завершено» ломает фильтры бэкенда. Используйте только жестко заданные справочники (Option Sets).
• Роли «придумаем потом»: отсутствие заложенных прав базы данных на старте грозит полной пересборкой всех Privacy Rules перед запуском.
• Вся логика в интерфейсе: вычисления, выполняемые на стороне браузера пользователя, легко взламываются и замедляют работу слабых устройств.
• Нет сущности «Платёж»: привязка факта оплаты напрямую к заказу без отдельной таблицы платежей не позволит корректно обработать возвраты и частичные чеки.
• Связи через поиск по имени: создание связей по текстовому совпадению имен или названий вместо использования уникальных ID (Unique ID). При смене имени связь разрывается.
• Проектирование под инструмент: попытка подстроить логику бизнеса под ограничения одного конкретного конструктора вместо поиска нужной архитектуры.

12. Нагрузка, лимиты и стоимость роста

Заранее спроектированное no-code приложение избавляет от неприятных сюрпризов при получении счета за платную подписку платформы. Любой рост бизнеса сопровождается увеличением объема данных и количества операций.

Что считать заранее

До запуска проекта рассчитайте предполагаемую нагрузку по четырем метрикам:

1. Общее количество записей в базе данных через 6 месяцев.
2. Количество активных пользователей одновременно (Concurrent Users).
3. Объем загружаемых файлов (изображения, документы).
4. Количество вызовов внешних сценариев автоматизации в месяц.

Где начинаются доплаты

Большинство платформ тарифицируют проекты по трем ресурсам: вычислительные единицы (Workload Units в Bubble, Workflows в FlutterFlow), объем хранилища базы данных и количество записей. Внешние коннекторы (например, Make или Zapier) берут оплату за каждую выполненную операцию. Неоптимизированный бесконечный цикл в Make может израсходовать месячный лимит операций за несколько минут.

Сколько стоит обвязка инструментами

Реалистичная оценка ежемесячного бюджета на инфраструктуру MVP в 2026 году выглядит следующим образом (ориентировочные значения):

• Конструктор фронтенда / БД (Bubble / FlutterFlow / Glide): от $29 до $134/мес.
• Внешний бэкенд (при необходимости, Xano / Supabase): $0 – $59/мес.
• Сервис автоматизаций (Make): $0 – $29/мес.
• Российский SMS-шлюз и эквайринг: по факту транзакций (комиссия 1.5–3.5%).

Итого средняя стоимость технического стека для работающего MVP составляет от 5 000 до 18 000 рублей в месяц. Подробные параметры затрат вы можете сопоставить, изучив тарифы Zerocoder.

13. Что дальше: от схемы к работающему MVP

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

Правильный порядок сборки

1. Создание базы данных: заведение всех сущностей, полей и типов данных.
2. Настройка ролей и прав: конфигурирование Privacy Rules до создания UI.
3. Построение макетов и списков: сборка базовых экранов и верстка динамических списков.
4. Формы и обработка ввода: настройка создания и редактирования записей.
5. Внешние автоматизации: подключение сценариев уведомлений и бизнес-логики.
6. Платежи и финальный тест: интеграция эквайринга и сквозное тестирование.

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

Реалистичный план сборки MVP на 2 недели

• Дни 1–2: Составление ТЗ, схемы данных и матрицы прав.
• Дни 3–5: Разворачивание структуры баз данных и настройка прав безопасности.
• Дни 6–9: Верстка экранов и привязка данных к элементам интерфейса.
• Дни 10–12: Подключение внешних автоматизаций, Telegram-ботов и эквайринга.
• Дни 13–14: Тестирование граничных случаев, исправление багов и запуск.

Сравнение путей реализации проекта

На этапе перехода к сборке у вас есть три основных пути развития:

• Освоить сборку самостоятельно: пройти курс по сборке сайта и приложения с нейросетью, чтобы полностью контролировать технический стек и экономить бюджет.
• Делегировать профессионалу: если у вас нет времени на самостоятельную сборку, вы можете найти no-code разработчика под сборку на специализированной площадке.
• Освоить профессию: если вы планируете создавать проекты на заказ, изучите актуальные вакансии no-code разработчика и требования рынка.

14. Часто задаваемые вопросы (FAQ)

Заключение: чек-лист готовности к сборке

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

• Суть продукта сформулирована в одном предложении.
• Выделено от 5 до 9 ключевых сущностей и прописаны их поля.
• Указаны типы связей между таблицами (1:M, M:M через связующие таблицы).
• Составлена матрица ролей и прав доступа на уровне базы данных.
• Спроектирована карта экранов с учетом пустых состояний и ошибок.
• Определены границы: что делается внутри платформы, а что вынесено в внешние автоматизации.

Если все 6 пунктов выполнены — вы готовы к безопасной и быстрой сборке MVP. Ознакомиться со всеми инструментами и нейросетями для проектирования вы можете, посетив наш каталог ИИ-инструментов.