Разработать и запустить сайт
Цель
Разработать и запустить haih.site как основной публичный сайт новой концепции HAIH.
Сайт должен не просто описывать технологии или существующий движок, а наглядно объяснять конечному пользователю новый подход к разработке с AI и давать работающие showcase прямо на сайте, пока отдельная библиотека кейсов на GitHub ещё не оформлена.
Что мы хотим донести
Основная идея:
Не начинай проект с большого движка. Начни с минимальной архитектуры, которая решает текущую задачу, и добавляй следующий слой только тогда, когда он действительно понадобился.
HAIH должен помогать человеку и coding agent дешёво эволюционировать проект: от нескольких статических файлов до сложного типизированного приложения.
Главная ценность — не количество возможностей «из коробки», а стоимость добавления следующей необходимой возможности.
Если задаче достаточно HTML/CSS/JS — не нужны React, база, GraphQL и application server.
Если появилась необходимость хранить данные — добавляется persistence.
Если данные нужно предоставить программным клиентам — появляется API.
Если API нужен frontend — добавляется типизированная клиентская интеграция.
Если нужны пользователи — добавляется auth.
Если нужен полноценный commerce-продукт — архитектура дорастает до него, но проект не должен платить эту цену раньше времени.
Позиционирование
HAIH сейчас следует показывать не как ещё один большой full-stack framework и не как каталог обязательных модулей.
Более точная модель:
минимальная основа + совместимые архитектурные принципы + best practices + законченные вертикальные кейсы для AI-assisted development.
В перспективе это может быть скорее архитектурный протокол, чем единый runtime: разные проекты используют разные части стека, но остаются предсказуемыми и понятными coding agents.
Ключевой принцип:
Use the cheapest architecture that completely solves the requirement.
Каждая новая зависимость должна быть оправдана пользовательской функцией.
Для кого сайт
В первую очередь:
- разработчики, активно использующие Claude Code, Codex, Cursor и другие coding agents;
- solo-разработчики и небольшие команды, которым важно быстро запускать и изменять продукты;
- разработчики, уставшие от избыточной сложности современных full-stack boilerplate;
- люди, которые хотят self-hosted/open-source основу и возможность менять архитектуру под себя;
- авторы собственных решений и кейсов, которыми впоследствии можно делиться с сообществом.
Сайт должен быть понятен человеку, который впервые слышит про HAIH и не знает историю существующего haih-net/agent.
Основное маркетинговое обещание
Не обещать «мы уже реализовали всё».
Показывать:
Start with almost nothing. Add architecture only when your requirements demand it.
И второе обещание:
Дайте coding agent понятные контракты, проверенные примеры и минимальный контекст — и он сможет развивать проект вместе с требованиями.
Пользователь должен после знакомства с сайтом понять:
- ему не предлагают принять огромный стек заранее;
- простой проект действительно может оставаться простым;
- когда требования растут, существуют проверенные пути усложнения;
- решения проектируются так, чтобы их было удобно понимать, изменять и проверять AI-агенту;
- showcase — не игрушечные screenshots, а рабочие образцы архитектурных переходов;
- конечную реализацию пользователь и AI адаптируют под конкретную задачу, а не обязаны устанавливать универсальный модуль.
Почему это важно для AI
Сайт должен отдельно объяснить Agent Experience (AX).
Для coding agent важны:
- минимальный необходимый context;
- предсказуемая структура проекта;
- локальность изменений;
- явные зависимости;
- отсутствие ручного дублирования контрактов;
- типизированные точки соединения компонентов;
- понятные compiler/runtime errors;
- воспроизводимый способ проверки результата;
- готовые кейсы, из которых можно перенести архитектурный принцип в новую задачу.
Сквозная типизация в сложных приложениях должна показываться как feedback loop для AI, например:
Prisma schema
↓
Prisma types
↓
Pothos
↓
GraphQL schema
↓
GraphQL Codegen
↓
Typed frontend
↓
tsc / tests
Но нельзя создавать впечатление, что весь этот стек обязателен каждому проекту.
Showcase как центральная часть сайта
Пока отдельная база showcase/cases на GitHub не оформлена, реализовать принципиальные showcase непосредственно на haih.site.
Showcase должны демонстрировать не список технологий, а разные разумные архитектурные состояния и переходы между ними.
Каждый showcase должен отвечать на вопросы:
- какая была задача;
- почему текущей архитектуры достаточно или уже недостаточно;
- какое новое требование появилось;
- что именно добавили;
- почему не добавили больше;
- как выглядит структура проекта;
- какие зависимости появились;
- как проверить результат;
- что из этого кейса может перенести AI в другой проект.
Showcase 1. Статический сайт
Задача: корпоративный сайт / landing / документационная страница без динамических данных.
Минимальная архитектура:
HTML / CSS / JS / assets
+ Docker Compose
+ Traefik
Никакой БД, GraphQL, auth, React и application server.
Главный тезис: если достаточно статики — движок не нужен.
Показать, насколько дёшево AI может менять такой проект.
Showcase 2. Обособленный API
Задача: сервис, который предоставляет программный API и вообще не нуждается в собственном frontend.
Показать API-first проект как самостоятельное конечное состояние, а не как недоделанный web-сайт.
Варианты развития:
API only
или при необходимости persistence:
PostgreSQL
+ Prisma
+ API
Показать, что UI не является обязательным слоем системы.
Showcase 3. Статический сайт + небольшая динамическая функция
Задача: например, форма обратной связи.
Не превращать ради неё весь сайт в full-stack application.
Показать минимальный переход:
static site
+ small endpoint/service
Если сообщения можно сразу отправлять во внешний сервис — БД не добавлять.
Это важный кейс против overengineering.
Showcase 4. Сайт с persistence
Задача: данные уже необходимо сохранять: заявки, каталог, записи или другой доменный объект.
Добавить:
PostgreSQL
+ Prisma
Показать Prisma как источник типизированной модели данных и объяснить, почему persistence появился именно на этом этапе.
API и сложный frontend добавлять только если задача действительно этого требует.
Showcase 5. Типизированный API поверх данных
Задача: сохранёнными данными должны пользоваться несколько клиентов или frontend должен работать с полноценным API.
Добавить, например:
PostgreSQL
+ Prisma
+ Pothos
+ GraphQL
Показать связь типов Prisma и GraphQL и минимизацию ручного glue-кода.
Showcase 6. Полноценное типизированное web-приложение
Задача: появляется интерактивный frontend, работающий с собственным API.
Архитектура развивается до:
PostgreSQL
+ Prisma
+ Pothos / GraphQL
+ GraphQL Codegen
+ client
+ UI
Показать сквозной контракт database → server → API → frontend и автоматическую проверку изменений компилятором.
Frontend framework не позиционировать как обязательный. Выбор React/другого решения должен быть следствием задачи.
Showcase 7. Пользовательское приложение с авторизацией
Задача: появляются персональные данные, аккаунты или закрытые операции.
Только теперь добавить auth/session/permissions.
Показать, что авторизация — не обязательная инфраструктура каждого сайта, а ответ на конкретное требование.
Продемонстрировать прохождение identity/permissions через API и UI без разрушения предыдущей архитектуры.
Showcase 8. Полноценный интернет-магазин
Задача: реальный сложный продукт.
Должны появиться необходимые доменные части, например:
- каталог товаров;
- категории;
- карточка товара;
- поиск/фильтрация, если оправданы требованиями;
- корзина;
- пользователь/покупатель;
- оформление заказа;
- заказы и их состояния;
- административное управление товарами и заказами;
- изображения/файлы;
- интеграция оплаты как отдельный архитектурный шаг;
- необходимые фоновые процессы/уведомления.
Этот showcase должен показать, что минималистичный подход не ограничивается лендингами: из той же системы принципов можно эволюционно получить полноценное production-oriented приложение.
При этом важно визуально/архитектурно показать происхождение сложности: каждый новый слой существует потому, что его потребовало конкретное бизнес-требование.
Показывать не только состояния, но и переходы
Showcase желательно связать в визуальный граф, а не линейную лестницу.
Пример:
┌→ small endpoint
static website ───┤
└→ persistence → API → typed web app → auth → commerce
API service ─────────→ persistence
└────────────→ agent/client integrations
Главная мысль: нет обязательного конечного стека.
Пользователь может остановиться в любой точке, если она полностью решает задачу.
Что должен делать каждый showcase на самом сайте
Не ограничиваться текстовым описанием.
По возможности каждый showcase должен быть работающим примером:
- открыть результат;
- посмотреть архитектуру/структуру;
- увидеть используемые компоненты;
- увидеть diff или последовательность изменений относительно предыдущего состояния;
- прочитать краткое объяснение архитектурного решения;
- увидеть способ проверки;
- получить инструкцию/prompt/context, с которыми coding agent может воспроизвести или адаптировать решение.
В дальнейшем эти материалы можно вынести/синхронизировать с отдельными GitHub cases.
Предлагаемая структура главной страницы
Hero
Очень коротко объяснить отличие HAIH.
Не «ещё один AI framework», а идея минимальной эволюционной архитектуры для разработки вместе с coding agents.
Основной CTA должен вести к работающим showcase.
Проблема
Современные boilerplate/framework часто заставляют проект платить за сложность заранее.
AI дополнительно платит за неё контекстом и количеством связей, которые должен понять.
Принцип
Start minimal. Add only what the next requirement needs.
Показать визуальную эволюцию от static до сложного приложения.
Live showcase
Центральный раздел сайта с описанными выше кейсами.
AI / AX
Объяснить, почему архитектура специально оптимизируется под coding agents: context, locality, types, compiler feedback, tests, cases.
Best practices / Cases
Объяснить модель базы знаний: не навязывать одну конечную реализацию, а собирать проверенные архитектурные решения и законченные вертикальные изменения.
Open source / Participate
Объяснить будущий community loop:
requirement
→ minimal solution
→ verified case
→ AI reuse
→ new projects
→ new cases
Приглашать пробовать подход, адаптировать кейсы и публиковать собственные решения.
Чего сейчас не обещать
- не позиционировать HAIH как готовую универсальную SaaS-платформу;
- не делать акцент на продаже/монетизации;
- не обещать огромный marketplace готовых модулей, которого пока нет;
- не создавать впечатление, что Prisma/Pothos/Apollo/React обязательны;
- не переносить на новый продукт весь feature list старого
haih-net/agent; - не говорить, что существует единственно правильная архитектура;
- не перегружать главную техническими деталями раньше, чем пользователь понял ценность.
Критерий результата сайта
Новый посетитель без знания истории HAIH должен после просмотра сайта понять:
«Я могу начать с минимального проекта. Когда появится новое требование, AI сможет взять проверенный кейс, добавить только необходимую архитектуру и проверить результат. Мне не нужно заранее принимать огромный framework и тащить в проект функциональность, которой у меня нет».
После понимания этой идеи пользователь должен иметь возможность сразу открыть живой showcase, увидеть её на реальном проекте и получить достаточно информации, чтобы попробовать аналогичный подход самостоятельно.
Цель распространения
На текущем этапе оптимизировать сайт под понимание идеи, эксперименты и участие, а не под продажи.
Желаемый цикл:
посетитель
→ понимает принцип
→ смотрит живой case
→ пробует подход
→ адаптирует решение с AI
→ делится собственным case/best practice
→ следующий пользователь получает ещё один проверенный путь
Сайт должен стать первой публичной демонстрацией этой модели и временно выполнять роль витрины/базы ключевых showcase до появления полноценного открытого каталога кейсов.