Я хотел сделать три сайта.В итоге решил изменить сам подход к их созданию.
I wanted to build three websites.I ended up changing how they are made.
Как три запроса на сайты привели к SABSUS Site: свободный дизайн, AI, реальные данные бизнеса, управляемая публикация и честная проверка результата.
How three website requests led to SABSUS Site: distinct design, AI, live business data, controlled publishing, and honest verification.
Разный дизайнDistinct design
Живые данныеLive data
Версии и previewVersions and preview
Клиенты и заказыCustomers and ordersПочти одновременно ко мне пришли три запроса на создание сайтов. Три бизнеса, три разных представления о дизайне и три совершенно разных ожидания от результата. Казалось бы, обычная ситуация: обсудить требования, подготовить структуру, сделать страницы и подключить необходимые функции. Но именно эти запросы заставили меня остановиться и задать вопрос, который в итоге оказался гораздо важнее самих сайтов: почему мы каждый раз заново собираем интерфейс бизнеса, если сам бизнес уже работает внутри готовой цифровой системы?
Я развиваю SABSUS — платформу, в которой связаны клиенты, заказы, CRM, товары, услуги, сотрудники, склад, платежи, доставка и другие операционные процессы. У компании уже есть данные и инструменты для работы. Но когда появляется задача сделать сайт, возникает почти параллельный проект: отдельно продумать каталог, отдельно подключить формы, отдельно разобраться с оплатой, отдельно сделать запись на услуги. Даже когда значительная часть необходимой логики уже существует, сайт часто строится так, будто её нет.
При этом сами клиенты совершенно справедливо не хотят одинаковые сайты. Стандартный интерфейс платформы может быть удобным и функциональным, но он не должен определять внешний вид каждого бизнеса. Ресторану важны атмосфера и фотографии блюд, сервисной компании — доверие к специалистам, магазину — удобный поиск и карточки товаров. Даже две компании из одной отрасли могут иметь совершенно разное позиционирование. Я не хотел объяснять людям, почему им нужно подстраивать собственный бренд под наш стандартный дизайн. Мне хотелось сохранить общую бизнес-систему, но дать каждому свободу выглядеть по-своему.
Первой мыслью было сделать собственный конструктор сайтов. Добавить блоки, секции, настройки шрифтов, цветов и отступов, позволить собирать страницы внутри SABSUS. Технически это выглядело понятным направлением. Но чем дальше я его обдумывал, тем чаще возвращался к одному сомнению: зачем сейчас создавать ещё один интерфейс для ручной сборки страниц, если искусственный интеллект уже умеет писать код этих страниц напрямую? Возможно, я собирался решать задачу способом, который перестал быть для неё самым естественным.
Эта тема для меня не новая. В моём Instagram около 30 тысяч подписчиков, и заметную роль в росте блога сыграло видео, набравшее примерно 1,3 миллиона просмотров. В нём я показывал, как с помощью ChatGPT создать сайт за пять минут. Людей привлекла не возможность получить HTML-файл. Их привлекло ощущение самостоятельности: то, что раньше казалось доступным только разработчику, внезапно можно было сделать обычным сообщением. Для владельца небольшого бизнеса это сильное переживание — понять, что идея может получить видимую форму почти сразу.
Но постепенно я начал иначе смотреть на обещание «сайт за пять минут». За пять минут действительно можно получить впечатляющий интерфейс. Однако между красивой страницей и работающим инструментом бизнеса остаётся большая дистанция. Нужно опубликовать проект, подключить домен, разместить изображения, настроить доступ к данным, связать форму с CRM, организовать оплату и убедиться, что секретные ключи не оказались в браузере. Потом потребуется изменить сайт, не потеряв предыдущую версию, и проверить, не сломалась ли после изменения запись или корзина. Именно здесь человек снова вынужден искать разработчика.
Я понял, что меня больше интересует не генерация страницы, а этот переход — от готового кода к работающему сайту. Если AI уже умеет создавать интерфейс, то следующая ценность заключается в инфраструктуре, которая позволяет этот интерфейс безопасно запустить и связать с бизнесом. Не выдать человеку папку файлов и пожелать удачи, а провести его дальше: до публикации, реального каталога, заявки, бронирования и корректно организованной оплаты.
Из этой мысли и появился SABSUS Site. Вместо собственного визуального конструктора я решил создать отдельный MCP-сервер для работы с сайтами. MCP здесь можно представить как согласованный способ предоставить AI конкретные инструменты: прочитать исходники, загрузить изображение, создать версию, проверить её, открыть предпросмотр или опубликовать. Модель не получает бесконтрольный доступ ко всей инфраструктуре. Она вызывает определённые действия, а сервер проверяет права, параметры и допустимость операции.
Идея развивалась в диалоге с AI. Я проговаривал, какой опыт хочу дать владельцу бизнеса, превращал решения в задания для Codex, смотрел на результат и пересматривал архитектуру. Иногда технически привлекательная идея оказывалась лишней для самого продукта. Иногда за небольшой, на первый взгляд, функцией обнаруживался важный инфраструктурный вопрос. Этот процесс был не похож на ситуацию, когда написал один огромный промпт и получил идеальную систему. Скорее это была последовательность решений, в которой AI ускорял реализацию, а мне приходилось постоянно удерживать смысл: что именно мы строим и чего строить не надо.
Первую рабочую версию нового слоя я собрал примерно за один день. Но здесь важно не превращать эту фразу в рекламный трюк. За сутки не возникла вся бизнес-платформа, и за сутки не закончились все проверки. Каталог, заказы, CRM, склад, платежи и другие модули SABSUS уже существовали. Быстро появился именно способ дать AI управляемый доступ к созданию сайтов поверх этой основы. Дальше последовали отдельные этапы разработки, испытания, исправления и реальные проверки опубликованных версий. Быстрый прототип показал, что идея работает; последующая инженерная работа должна была сделать её пригодной для использования.
Одним из первых принципиальных решений стал отказ от хранения дизайна как дерева блоков собственного конструктора. Источником сайта остался сам сайт: HTML, CSS, JavaScript и шаблоны. Служебный манифест сообщает системе, где находятся страницы и какие ресурсы используются, но не диктует, как должен выглядеть первый экран или из каких секций обязательно состоит главная. Это даёт разработчику и AI свободу работать с обычным кодом, а не изучать ещё один закрытый язык визуальных компонентов.
Особенно важной оказалась возможность изменять уже созданный проект. Я не хотел получить генератор, который хорошо делает первую версию, но при каждой следующей просьбе начинает всё заново. Если владелец говорит: «Сделай фотографии крупнее, перенеси форму выше и измени мобильное меню», система должна работать с текущими исходниками. Небольшая правка не должна уничтожать остальные страницы или потерять загруженные файлы. Поэтому изменения становятся новыми версиями, а проверка ревизий и контрольных сумм защищает от ситуации, когда одна сессия AI незаметно перезаписывает работу другой.
Следующим естественным шагом стали предпросмотр, проверка перед публикацией и откат. Для меня здесь важна не только удобная кнопка «вернуть назад», но и разделение между внешним видом сайта и бизнесом. Можно вернуть предыдущую версию страницы, не возвращая старые цены в каталоге и не отменяя заказы, которые поступили за это время. Предпросмотр, в свою очередь, не должен случайно стать настоящим магазином: проверка дизайна не является разрешением списывать деньги, создавать рабочие заявки или занимать время сотрудников. Такие границы делают разговорное управление сайтом значительно практичнее, чем просто доступ AI к кнопке публикации.
Параллельно пришлось определить, что вообще должно находиться внутри Site MCP. У SABSUS уже есть большой MCP для управления бизнесом, и было бы легко начать переносить его функции в новую систему. Но это разрушило бы первоначальную идею. Site MCP нужен, чтобы создавать, изменять, подключать и проверять сайты. Управление рекламными кабинетами, анализ расходов, себестоимости и прибыли относится к основной платформе. Если оба интерфейса используют Google, им нужен общий серверный сервис интеграции, а не две независимые реализации авторизации. Ни один MCP не должен становиться отдельным владельцем данных компании только потому, что через него впервые подключили внешний сервис.
В результате разные люди могут заниматься разными частями работы. Один разработчик создаёт сайт, другой настраивает измерение событий, маркетолог работает с рекламой, руководитель смотрит результаты. Они используют одну разрешённую инфраструктуру компании, но не обязательно имеют одинаковые права. Подключённый Google-аккаунт можно переиспользовать там, где это разрешено. Если для новой возможности нужны дополнительные полномочия, пользователь подтверждает их у Google, а ответ приходит на сервер SABSUS. Токены не должны проходить через переписку с AI или попадать в исходники сайта.
На вопросе секретов я остановился особенно жёстко. Мне предлагалась логичная на первый взгляд возможность: дать AI инструмент, которому пользователь передаст API-ключ, а система безопасно сохранит его на сервере. Но для меня это уже неправильная последовательность. Если человек сначала отправил ключ в разговор, модель его уже увидела. Поэтому безопасный путь должен начинаться раньше: OAuth либо отдельный защищённый интерфейс ввода, который не передаёт секрет AI. Модель получает идентификатор интеграции и статус подключения, а не само значение ключа. Это не обещание абсолютной неуязвимости, а конкретное архитектурное правило, которое уменьшает ненужное распространение секретов.
Когда такая основа появляется, иначе начинает выглядеть даже привычный каталог товаров. Сайту не нужно хранить отдельную копию меню ресторана или ассортимента магазина. Он получает разрешённые данные из SABSUS. Новый товар может получить собственную страницу без новой публикации дизайна, а изменение описания или цены не требует пересобирать весь проект. При этом динамические данные не заставляют все страницы выглядеть одинаково: у категории может быть собственный шаблон, а у отдельного товара — уникальная презентация. Можно оставить одну бизнес-логику и дать ей разные визуальные формы.
В какой-то момент я отдельно настоял на полноценном поиске. Красивое поле поиска ничего не стоит, если оно ищет только среди первых тридцати карточек, загруженных в браузер. Для большого каталога это незаметная, но серьёзная ошибка: покупатель может решить, что товара нет, хотя интерфейс просто ещё не получил его из базы. Поэтому поиск должен работать по всему разрешённому каталогу на сервере, учитывать название, оригинальное название, переводы, категорию и бренд, поддерживать фильтры и выдавать результаты порциями. Для владельца магазина это не техническая деталь, а разница между найденным и потерянным спросом.
На ресторане хорошо видно, зачем вообще соединять сайт с существующей операционной системой. Выбранное заведение определяет, доступна ли доставка, можно ли оформить самовывоз и какие правила применяются к заказу. Блюдо может зависеть от состава и складской логики, а не от отдельного флажка «в наличии» на сайте. Постоянный клиент видит свои адреса, историю и разрешённые возможности программы лояльности. Если работает доставка, интерфейс может показать статус и положение курьера в контексте конкретного заказа. Не потому, что разработчик заново создал логистическую платформу, а потому, что эта часть бизнеса уже существует.
Для услуг тот же принцип работает через сотрудников и расписание. На сайте появляются реальные профили специалистов: фотографии, описание, опыт, работы и услуги. Клиент выбирает человека и получает доступные интервалы из той системы, которой пользуется сам бизнес. Для продаж с предварительным обсуждением важнее другой сценарий: форма сразу создаёт лид в существующей CRM с нужными полями и направлением обработки. Мне хотелось убрать именно повторное изобретение этих связей. Разработчик должен думать о том, как удобно показать запись или заявку, а не каждый раз создавать ещё один календарь и ещё одну базу обращений.
С платежами граница между интерфейсом и серверной логикой становится особенно важной. На сайте можно свободно оформить экран выбора оплаты, но нельзя позволять браузеру назначать итоговую сумму или выбирать чужую интеграцию. В SABSUS уже существуют методы оплаты и их связи с платёжными сервисами. Сайт передаёт выбор покупателя, сервер проверяет его, рассчитывает заказ и направляет операцию по подходящему маршруту. Повторный запрос не должен создавать второй платёж, а переход на страницу благодарности не должен считаться доказательством получения денег. Это как раз та работа, которую не видно на красивом скриншоте, но без которой нельзя серьёзно говорить о бизнес-сайте.
Так же я подошёл к публикации и доменам. Пользователь может начать с доступного технического адреса Firebase вида имя.web.app или подключить собственный домен либо поддомен. Во втором случае система получает реальные требования хостинга и показывает готовые DNS-записи, а затем проверяет владение, сертификат и маршрутизацию. Здесь я не стремился любой ценой автоматизировать каждый кабинет регистратора. Там, где пользователь может самостоятельно добавить несколько понятных записей, достаточно дать ему точную инструкцию и проверить результат. Для меня хороший продукт — не тот, в котором больше всего автоматизаций, а тот, где автоматизирована действительно сложная и повторяющаяся работа.
Во время разработки я всё чаще возвращался к этому критерию. Нам не нужен отдельный инструмент MCP для каждого возможного клика на странице, каждого баннера или каждого визуального элемента. Если разработчик может решить задачу в обычном коде сайта, не затрагивая секреты и инфраструктуру, ему надо оставить такую возможность. Но если действие требует серверных прав, безопасной публикации, подтверждения платежа, обработки загрузки или общей бизнес-логики, тогда это ответственность платформы. Такое разделение помогает не превратить небольшой специализированный сервер в ещё одну огромную систему, которую невозможно закончить.
Даже работу с изображениями я не хотел строить по принципу «создадим побольше вариантов на всякий случай». Если фотография используется только в маленькой карточке, зачем хранить для неё набор огромных копий? Разработчик или AI может сообщить предполагаемый диапазон отображения, а сервер — создать только полезные размеры и форматы. Браузер выберет подходящий вариант для экрана, а система учтёт файлы в квотах и очистке. В этом решении для меня сошлись производительность и экономика: нужно не просто ускорить загрузку, но и не накапливать бессмысленные данные.
По той же причине я отдельно определил правила хранения. Оперативные данные остаются там, где уже работает нативная логика SABSUS, а история аудитов, аналитические результаты и редко читаемые сведения отправляются в Supabase/Postgres. Исходники, сборки и медиа хранятся в R2. Я не хотел создавать десятки таблиц под каждую новую интеграцию или копировать в собственную базу весь поток кликов, который уже собирает Google Analytics. Архитектура должна помогать анализировать бизнес, а не производить всё больше данных только потому, что технически их можно сохранить.
Отдельным открытием стала разница между хорошим техническим тестом и реальным результатом. Когда сайт получает высокий балл SEO, очень хочется сказать: «С индексацией всё отлично». Но это разные утверждения. Страница может быть доступной, иметь правильные метаданные и находиться в sitemap, а Google ещё не включил её в индекс. Поэтому в системе появились отдельные проверки маршрутов, карты сайта и Search Console. Теперь можно различать то, что платформа опубликовала, то, что проверил наш аудит, и то, что на самом деле подтвердил поисковик.
С производительностью ситуация похожая. PageSpeed помогает увидеть лабораторные показатели и технические проблемы, а CrUX — доступные агрегированные данные реальных пользователей. В отдельных проверках опубликованные страницы получали 100 баллов производительности и на мобильном, и на компьютере. Но я не хочу превращать такой результат в обещание, что любой сгенерированный сайт всегда будет загружаться идеально. Важно другое: показатели можно сохранить, связать с публикацией и сравнить после изменений. Если новая версия стала тяжелее, разработчик должен это увидеть, а не обнаружить спустя месяц по жалобам.
Google Analytics и Tag Manager дополнили эту картину измерением поведения. Подключить тег — ещё не значит доказать, что события приходят. Поэтому мы проверяли не только наличие конфигурации, но и реальные действия в браузере, загрузку после согласия и появление событий в Google. При этом я не хочу смешивать ответственность Site MCP с полной бизнес-аналитикой. Его задача — правильно подключить измерение и дать разработчику рабочую инфраструктуру. Дальше основной SABSUS сможет сопоставлять доступные сведения о посещениях и рекламе с заказами и затратами, не выдавая аналитические оценки за подтверждённые финансовые факты.
Чем дальше шла работа, тем важнее становилась честность самих отчётов. «Функция реализована», «проверена автоматическим тестом», «выполнена в браузере» и «прошла через настоящий платёж» — четыре разных уровня подтверждения. Если аудит не смог проверить сценарий без тестового покупателя, он должен так и написать. Если мы дошли до платёжного шага, но не создавали платёж, это не полная денежная приёмка. Мне оказалось важнее сохранить такие различия, чем любой ценой получить зелёный статус. Именно поэтому разработка продолжалась после первого работающего прототипа: нужно было проверить не только идею, но и её границы.
В живых сценариях мы уже проходили создание и изменение сайта через MCP, публикацию и откат, регистрацию покупателя, вход, работу с авторизованным QR, выбор услуги, сотрудника и свободного времени. Проверяли реальный путь поддомена через DNS, сертификат и маршрутизацию. Для отдельных денежных сценариев остаются собственные требования к безопасной тестовой среде и подтверждению результата. Я считаю нормальным говорить об этом прямо. Инфраструктура для бизнеса не становится надёжнее от того, что в описании исчезают неудобные ограничения.
Параллельно я подал SABSUS Site на рассмотрение в каталог OpenAI. Для меня это попытка сделать созданный интерфейс доступным там, где люди уже работают с AI, а не ещё одна причина заставлять их изучать отдельный кабинет. Но отправка заявки, её рассмотрение и официальное одобрение — разные события. Так же как наличие большого числа тестов и готовность каждого возможного клиентского сценария — не одно и то же. Я хочу, чтобы продукт рос на проверяемых возможностях, а не на слишком широких формулировках.
Когда смотришь на всю эту работу со стороны, может показаться, что я просто собрал много функций вокруг генератора сайтов. Для меня смысл противоположный: я пытался сократить количество вещей, которые приходится заново создавать для каждого проекта. Не ещё одна CRM рядом с CRM, не ещё один склад рядом со складом, не отдельная авторизация Google для каждого AI-интерфейса. Один бизнес, общие правила, разрешённые интеграции и разные способы показать всё это клиенту.
Я не хочу называть себя человеком, который первым придумал отделить интерфейс от backend или использовать AI в веб-разработке. Мне важнее проверить конкретное сочетание: свободно изменяемый код, управление через MCP, готовая операционная система бизнеса и полный путь от исходников до опубликованного результата. Возможно, я переоцениваю масштаб этой идеи. Но я вижу, какую проблему она решает лично для меня и для клиентов: уникальный сайт перестаёт требовать повторной сборки всего, что у бизнеса уже есть.
Если такой подход станет привычным, изменится и сама роль разработчика. Он не исчезнет, но больше времени сможет уделять структуре, удобству, качеству данных, интеграциям и безопасности, а не повторному подключению одинаковой формы к одинаковой CRM. Владелец бизнеса, в свою очередь, сможет самостоятельно менять больше повседневных вещей, не превращая каждую новую страницу в отдельный проект. Это не отменяет сложность разработки; это позволяет один раз правильно разместить её внутри платформы, вместо того чтобы перекладывать на каждого следующего клиента.
Когда моё видео о сайте за пять минут набрало 1,3 миллиона просмотров, я думал прежде всего о скорости. Сейчас меня больше интересует продолжение этой истории. Что получает человек после этих пяти минут: впечатляющую демонстрацию или инструмент, который можно опубликовать, связать с компанией, безопасно изменять и использовать в реальной работе? SABSUS Site — мой ответ на этот вопрос. Я начал с трёх разных сайтов, а пришёл к мысли, что сайт вообще не обязан быть отдельной системой. Он может оставаться уникальным лицом бизнеса, не становясь второй копией его данных и процессов. И именно в этом, а не просто в скорости написания HTML, я вижу следующий важный шаг AI в веб-разработке.
Almost at the same time, I received three requests to create websites. Three businesses, three different ideas about design, and three very different expectations. It seemed routine: discuss requirements, plan the structure, build pages, and connect the necessary features. Yet these requests made me stop and ask a question more important than the sites themselves: why do we rebuild a business interface every time if the business already runs inside a digital system?
I am building SABSUS, a platform that connects customers, orders, CRM, products, services, staff, inventory, payments, delivery, and other operations. A company already has the data and tools it needs to work. But creating a website often becomes a parallel project: plan a separate catalog, connect forms, figure out payments, and build service bookings. Even when much of that logic already exists, the website is often built as though it does not.
At the same time, clients are entirely right to want different websites. A platform's standard interface can be useful, but it should not dictate how every business looks. A restaurant needs atmosphere and food photography; a service company needs to build trust in its specialists; a store needs search and product pages. Even two companies in the same industry can position themselves differently. I did not want to tell people to fit their brands into our standard design. I wanted to keep one business system while giving everyone the freedom to look like themselves.
My first thought was to build a website builder of our own: blocks, sections, font settings, colors, spacing, and page assembly inside SABSUS. Technically, the direction made sense. But the more I considered it, the more I wondered why we would create another interface for assembling pages by hand when AI can already write the code for those pages. Perhaps I was about to solve the problem in a way that was no longer the most natural one.
This subject was not new to me. My Instagram has around 30,000 followers, and a video that reached roughly 1.3 million views played a noticeable part in its growth. In that video I showed how to make a website with ChatGPT in about five minutes. What drew people in was not an HTML file. It was a sense of agency: something that once seemed possible only for a developer could suddenly begin with an ordinary message. For a small business owner, seeing an idea take shape almost immediately is powerful.
Over time, though, I began to see the promise of a “website in five minutes” differently. Five minutes can produce an impressive interface, but there is a long distance between a beautiful page and a working business tool. You still need to publish it, connect a domain, host images, configure data access, connect a form to CRM, organize payments, and ensure secret keys do not end up in the browser. Later, you need to change the site without losing its previous version and check that bookings or the cart still work. That is where people find themselves looking for a developer again.
I realized that what interested me most was not page generation but the transition from finished code to a working website. If AI can already create the interface, the next value lies in the infrastructure that launches it safely and connects it to the business. Instead of handing someone a folder of files and wishing them luck, it should take them through publication, a real catalog, leads, bookings, and properly handled payments.
That thought became SABSUS Site. Instead of building a visual editor, I decided to create a separate MCP server for websites. Think of MCP here as a defined way to give AI specific tools: read source files, upload an image, create a version, check it, open a preview, or publish. The model does not get unrestricted access to all infrastructure. It requests specific actions, while the server checks permissions, parameters, and whether each operation is allowed.
The idea developed in conversation with AI. I described the experience I wanted for a business owner, turned decisions into tasks for Codex, reviewed the result, and revised the architecture. Sometimes a technically appealing idea turned out to be unnecessary for the product. Sometimes a small feature exposed an important infrastructure question. This was not a case of writing one enormous prompt and receiving a perfect system. It was a sequence of decisions in which AI accelerated implementation while I kept returning to the purpose: what exactly are we building, and what should we leave out?
I put together the first working version of this new layer in about a day. But that should not become an advertising trick. The whole business platform did not appear in a day, and the checks did not end in a day. The catalog, orders, CRM, inventory, payments, and other SABSUS modules already existed. What appeared quickly was a way to give AI controlled access to website creation on top of that foundation. Separate development, testing, fixes, and checks of published versions followed. The fast prototype showed that the idea could work; subsequent engineering had to make it usable.
One early decision was to avoid storing design as a tree of blocks in our own builder. The source of the website remained the website itself: HTML, CSS, JavaScript, and templates. A service manifest tells the system where pages and resources live, but does not dictate the hero layout or prescribe the sections of a homepage. That lets a developer and AI work with ordinary code rather than learning another closed visual language.
It was especially important to be able to change an existing project. I did not want a generator that makes a good first version but starts over with every new request. If an owner says, “Make photos larger, move the form higher, and change the mobile menu,” the system should work with the current source. A small edit should not destroy other pages or lose uploaded files. Changes therefore become new versions, while revision and checksum checks guard against one AI session silently overwriting another's work.
Preview, checks before publication, and rollback were the next natural steps. What matters to me is not just a convenient “go back” button, but a separation between a site's appearance and the business behind it. You should be able to restore an earlier page version without restoring old catalog prices or canceling orders placed since then. Preview should not accidentally turn into a real store either: checking a design is not permission to charge money, create live leads, or reserve an employee's time. These boundaries make conversational website management much more practical than merely giving AI a publish button.
In parallel, I had to decide what belongs in Site MCP. SABSUS already has a broader MCP for running a business, and it would have been easy to move its functions into the new server. That would undermine the original idea. Site MCP should create, change, connect, and check websites. Managing ad accounts or analyzing costs, unit economics, and profit belongs to the main platform. If both interfaces use Google, they need a shared server-side integration service, not two unrelated authorization implementations. Neither MCP should become the owner of company data simply because an external service was first connected through it.
Different people can then handle different parts of the work. One developer makes the site, another configures event measurement, a marketer runs ads, and a manager reviews results. They use the company's shared, authorized infrastructure without necessarily having the same permissions. A connected Google account can be reused where permitted. If a new capability needs additional access, the user approves it with Google and the response goes to the SABSUS server. Tokens should not pass through an AI chat or appear in site source code.
I drew an especially firm line around secrets. One proposal sounded sensible at first: give AI a tool to receive an API key from the user and store it safely on the server. To me, that gets the order wrong. Once a person sends a key in the conversation, the model has already seen it. A safer path starts earlier, with OAuth or a separate protected input screen that does not pass the secret to AI. The model gets an integration identifier and connection status, not the key itself. This is no promise of absolute security; it is a concrete architectural rule that reduces needless exposure.
With that foundation, even a familiar product catalog starts to look different. The site does not need its own copy of a restaurant menu or store inventory. It receives authorized data from SABSUS. A new product can get its own page without republishing the design, while changing its description or price does not require rebuilding the entire project. Dynamic data does not make all pages look alike: a category can have a custom template and an individual product a distinctive presentation. One business logic can support many visual forms.
At one point I insisted on real search. A beautiful search field is worth little if it searches only the first thirty cards loaded into a browser. With a large catalog, that creates a quiet but serious error: a buyer may think a product is unavailable when the interface simply has not fetched it. Search therefore needs to cover the whole authorized catalog on the server, account for names, original names, translations, category, and brand, support filters, and return paginated results. To a store owner, this is the difference between demand found and demand lost.
A restaurant makes the reason for connecting a site to an existing operating system clear. The chosen location determines whether delivery and pickup are available and which rules apply to an order. A dish may depend on ingredients and inventory logic rather than a separate “in stock” switch on the site. A returning customer can see saved addresses, history, and the permitted parts of a loyalty program. If delivery is running, the interface can show the courier's status and location in the context of a specific order. That works because this part of the business already exists, not because a developer rebuilt a logistics platform.
For services, the same principle works through staff and schedules. The site can show real specialist profiles with photos, descriptions, experience, work, and services. A customer selects a person and sees available times from the system the business itself uses. Where sales begin with a conversation, another path matters more: a form creates a lead directly in the existing CRM with the right fields and routing. I wanted to remove the repeated invention of these connections. A developer should focus on how to present a booking or inquiry, not build another calendar and another lead database for every site.
With payments, the line between interface and server logic is especially important. A site can freely design a payment selection screen, but a browser must not decide the final amount or select another company's integration. SABSUS already has payment methods and their links to payment services. The site sends the buyer's choice; the server validates it, calculates the order, and routes the operation appropriately. Repeating a request must not create a second payment, and landing on a thank-you page must not count as proof that money arrived. None of this appears in a beautiful screenshot, but without it a business website cannot be taken seriously.
I approached publishing and domains the same way. A user can start with an available Firebase technical address such as name.web.app, or connect a custom domain or subdomain. In the latter case, the system gets the hosting requirements, shows the necessary DNS records, then checks ownership, certificates, and routing. I was not trying to automate every registrar dashboard at any cost. Where a user can add a few clear records, exact instructions and verification are enough. To me, a good product does not automate the most things; it automates the truly complex and repetitive work.
During development I kept coming back to that test. We do not need a separate MCP tool for every possible page click, banner, or visual element. If a developer can solve it in ordinary site code without touching secrets or infrastructure, they should be free to do so. But if an action needs server privileges, safe publication, payment confirmation, upload processing, or shared business logic, it belongs to the platform. This division helps keep a specialized server from growing into another enormous system that never gets finished.
I did not want image processing to follow a “make as many variants as possible” rule either. If a photo appears only in a small card, why keep a set of giant copies? A developer or AI can specify the expected display range, and the server can create only useful sizes and formats. The browser chooses the right variant for its screen, while the system accounts for files in quotas and cleanup. For me, performance and economics meet here: faster loading matters, but so does avoiding pointless data.
For the same reason, I defined storage rules. Operational data stays where SABSUS's native logic already runs. Audit history, analytics results, and rarely read information go to Supabase/Postgres. Source files, builds, and media live in R2. I did not want dozens of new tables for each integration or a copy of every click already collected by Google Analytics. Architecture should help us understand the business, not generate more data simply because we can store it.
Another discovery was the difference between a good technical test and a real outcome. When a site gets a high SEO score, it is tempting to say, “Indexing is great.” Those are different claims. A page can be reachable, have correct metadata, and appear in a sitemap while Google has not indexed it. That is why the system has separate checks for routes, sitemaps, and Search Console. We can distinguish what the platform published, what our audit checked, and what the search engine actually confirmed.
Performance has a similar distinction. PageSpeed helps reveal laboratory metrics and technical issues; CrUX offers available aggregate data from real users. In some checks, published pages received a 100 performance score on both mobile and desktop. I do not want to turn that into a promise that every generated site will always load perfectly. The important thing is that metrics can be saved, linked to a release, and compared after changes. A developer should see when a new version becomes heavier instead of learning about it a month later from complaints.
Google Analytics and Tag Manager added behavioral measurement to this picture. Installing a tag is not proof that events arrive. We checked not only configuration but actual browser actions, loading after consent, and events appearing in Google. At the same time, I do not want to assign all business analytics to Site MCP. Its job is to connect measurement properly and provide working infrastructure to a developer. The main SABSUS system can later compare available visit and advertising data with orders and costs, without passing analytical estimates off as confirmed financial facts.
As the work progressed, honesty in reporting became more important. “Implemented,” “covered by an automated test,” “completed in a browser,” and “passed through a real payment” are four different levels of evidence. If an audit could not run a scenario without a test buyer, it should say so. If we reached a payment step but made no payment, that is not end-to-end payment acceptance. Preserving these distinctions mattered more to me than a green status at any cost. Development continued after the first working prototype because we had to test its boundaries as well as its idea.
In live scenarios we have already gone through creating and changing a site via MCP, publishing and rollback, buyer registration and login, an authorized QR, and selection of a service, specialist, and available time. We checked a real subdomain path through DNS, certificate, and routing. Separate monetary scenarios still need their own safe test environment and verified outcome. I think it is normal to say that directly. Business infrastructure does not become more reliable when inconvenient limits disappear from its description.
In parallel, I submitted SABSUS Site for consideration in the OpenAI catalog. For me, this is an attempt to make the interface available where people already work with AI, rather than making them learn another dashboard. But submission, review, and official approval are different events. Likewise, many tests do not mean every possible customer scenario is ready. I want the product to grow through verifiable capabilities rather than claims that reach too far.
From the outside, all this may look like a collection of features around a site generator. To me, the point is to reduce how many things must be built again for every project. No second CRM beside the CRM, no second inventory system beside inventory, no separate Google authorization for each AI interface. One business, shared rules, authorized integrations, and different ways to present them to a customer.
I do not claim to be the first person to separate an interface from its backend or to use AI in web development. I care more about testing a particular combination: freely editable code, management through MCP, an existing business operating system, and the full path from source to published result. I may be overestimating the size of the idea. But I can see the problem it solves for me and for customers: a unique website no longer has to rebuild everything the business already has.
If this approach becomes normal, the developer's role will change too. Developers will not disappear, but they can spend more time on structure, usability, data quality, integrations, and security rather than repeatedly connecting the same form to the same CRM. Business owners can change more everyday things themselves instead of making each new page a separate project. This does not remove development complexity; it places that complexity properly inside the platform once, rather than handing it to every new customer.
When my video about building a website in five minutes reached 1.3 million views, I was thinking mostly about speed. Now I am more interested in what follows. After those five minutes, does a person have an impressive demo, or a tool they can publish, connect to a company, change safely, and use in real work? SABSUS Site is my answer. I started with three different websites and ended up believing that a website does not have to be a separate system at all. It can remain the unique face of a business without becoming a second copy of its data and processes. That, rather than just faster HTML, is the next important step I see for AI in web development.