## haih.site

A service for end business owners. The client is not required to become a developer or learn AI tools: they simply hand over the task and receive a working result. AI is used internally within the process, combined with the oversight of an experienced specialist.

Client-focused service for the development, redesign, and ongoing maintenance of websites, utilizing AI as an internal production technology.

haih.site

## Goal

Develop and launch **haih.site** as the primary public website for the new HAIH concept.

The website should not simply describe technologies or the existing engine, but rather **visibly explain the new AI-assisted development approach to the end user** and provide working showcases directly on the site, while the separate GitHub case library is still being formed.

## What We Want to Convey

Core idea:

> **Do not start a project with a heavy engine. Start with a minimal architecture that solves the current task, and add the next layer only when it is truly needed.**

HAIH should help humans and coding agents evolve a project inexpensively: from a few static files to a complex typed application.

The main value is not the number of out-of-the-box features, but **the cost of adding the next required feature**.

If HTML/CSS/JS is enough for the task, you don't need React, a database, GraphQL, or an application server.

If there is a need to store data, persistence is added.

If data needs to be provided to programmatic clients, an API appears.

If the API needs a frontend, a typed client integration is added.

If users are needed, auth is added.

If a full commerce product is needed, the architecture grows into it, but the project shouldn't pay that price prematurely.

## Positioning

HAIH should not currently be presented as yet another large full-stack framework or as a catalog of mandatory modules.

A more accurate model:

**minimal foundation + compatible architectural principles + best practices + complete vertical cases for AI-assisted development.**

In the long term, this might be more of an **architectural protocol** rather than a single runtime: different projects use different parts of the stack, but remain predictable and understandable to coding agents.

Key principle:

> **Use the cheapest architecture that completely solves the requirement.**

Each new dependency must be justified by a user-facing feature.

## Who the Website is For

First and foremost:

- developers actively using Claude Code, Codex, Cursor, and other coding agents;
- solo developers and small teams who need to launch and modify products quickly;
- developers tired of the excessive complexity of modern full-stack boilerplates;
- people who want a self-hosted/open-source foundation and the ability to tailor the architecture to their needs;
- authors of their own solutions and cases who can later share them with the community.

The website must be clear to someone who is hearing about HAIH for the first time and knows nothing about the history of the existing `haih-net/agent`.

## Main Marketing Promise

Do not promise "we have already implemented everything."

Show:

> **Start with almost nothing. Add architecture only when your requirements demand it.**

And the second promise:

> **Give your coding agent clear contracts, verified examples, and minimal context — and it will be able to evolve the project along with your requirements.**

After exploring the website, the user should understand that:

1. they are not being asked to adopt a massive stack upfront;
2. a simple project can genuinely remain simple;
3. as requirements grow, proven paths for scaling up exist;
4. solutions are designed so that an AI agent can easily understand, modify, and verify them;
5. showcases are not toy screenshots, but working examples of architectural transitions;
6. the user and the AI adapt the final implementation to the specific task, rather than being forced to install a universal module.

## Why This Matters for AI

The website should explicitly explain **Agent Experience (AX)**.

For a coding agent, the following are crucial:

- the minimum necessary context;
- a predictable project structure;
- locality of changes;
- explicit dependencies;
- absence of manual contract duplication;
- typed component connection points;
- clear compiler/runtime errors;
- a reproducible way to verify results;
- ready-made cases from which an architectural principle can be transferred to a new task.

End-to-end typing in complex applications should be shown as a feedback loop for AI, for example:

```text
Prisma schema
    ↓
Prisma types
    ↓
Pothos
    ↓
GraphQL schema
    ↓
GraphQL Codegen
    ↓
Typed frontend
    ↓
tsc / tests
```

However, it must not create the impression that this entire stack is mandatory for every project.

## Showcases as the Central Part of the Website

Until a separate showcase/cases database on GitHub is established, **implement the foundational showcases directly on haih.site**.

Showcases should demonstrate not just a list of technologies, but various sensible architectural states and transitions between them.

Each showcase should answer the questions:

- what the task was;
- why the current architecture is sufficient or no longer sufficient;
- what new requirement emerged;
- what exactly was added;
- why nothing more was added;
- what the project structure looks like;
- what dependencies were introduced;
- how to verify the result;
- what parts of this case an AI can transfer to another project.

### Showcase 1. Static Website

**Task:** corporate website / landing page / documentation page without dynamic data.

Minimal architecture:

```text
HTML / CSS / JS / assets
+ Docker Compose
+ Traefik
```

No database, GraphQL, auth, React, or application server.

Main thesis: **if static is enough, an engine is not needed.**

Demonstrate how cheaply AI can modify such a project.

### Showcase 2. Standalone API

**Task:** a service that provides a programmatic API and does not need its own frontend at all.

Present the API-first project as an independent final state rather than an unfinished web application.

Evolution options:

```text
API only
```

or, if persistence is needed:

```text
PostgreSQL
+ Prisma
+ API
```

Show that UI is not a mandatory layer of the system.

### Showcase 3. Static Website + Small Dynamic Feature

**Task:** for example, a feedback form.

Do not turn the entire website into a full-stack application just for this.

Show the minimal transition:

```text
static site
+ small endpoint/service
```

If messages can be sent directly to an external service, do not add a database.

This is an important case against overengineering.

### Showcase 4. Website with Persistence

**Task:** data now needs to be saved: submissions, a catalog, records, or another domain object.

Add:

```text
PostgreSQL
+ Prisma
```

Show Prisma as the source of a typed data model and explain why persistence appeared precisely at this stage.

Add API and a complex frontend only if the task truly demands it.

### Showcase 5. Typed API on Top of Data

**Task:** saved data needs to be consumed by multiple clients, or the frontend must work with a full API.

Add, for example:

```text
PostgreSQL
+ Prisma
+ Pothos
+ GraphQL
```

Show the connection between Prisma and GraphQL types and the minimization of manual glue code.

### Showcase 6. Full-Featured Typed Web Application

**Task:** an interactive frontend appears, working with its own API.

Architecture evolves to:

```text
PostgreSQL
+ Prisma
+ Pothos / GraphQL
+ GraphQL Codegen
+ client
+ UI
```

Show the end-to-end contract **database → server → API → frontend** and automatic verification of changes by the compiler.

Do not position a frontend framework as mandatory. Choosing React or another solution should follow from the task requirements.

### Showcase 7. User Application with Authorization

**Task:** personal data, accounts, or restricted operations appear.

Only now add auth/session/permissions.

Show that authorization is not mandatory infrastructure for every website, but a response to a specific requirement.

Demonstrate passing identity/permissions through the API and UI without breaking the previous architecture.

### Showcase 8. Full-Featured E-Commerce Store

**Task:** a real, complex product.

The necessary domain parts should appear, such as:

- product catalog;
- categories;
- product card;
- search/filtering, if justified by requirements;
- shopping cart;
- user/buyer;
- checkout process;
- orders and their statuses;
- administrative product and order management;
- images/files;
- payment integration as a separate architectural step;
- necessary background processes/notifications.

This showcase should demonstrate that the minimalist approach is not limited to landing pages: **from the same system of principles, you can evolutionarily build a full-fledged production-oriented application.**

At the same time, it is important to visually/architecturally show the origin of complexity: every new layer exists because a specific business requirement demanded it.

## Showcasing Not Only States, but Transitions

It is desirable to link showcases into a visual graph rather than a linear ladder.

Example:

```text
                  ┌→ small endpoint
static website ───┤
                  └→ persistence → API → typed web app → auth → commerce

API service ─────────→ persistence
        └────────────→ agent/client integrations
```

Core thought: **there is no mandatory final stack**.

The user can stop at any point if it completely solves the task.

## What Each Showcase on the Site Should Do

Do not limit it to a text description.

Whenever possible, each showcase should be a working example:

- open the result;
- view the architecture/structure;
- see the components used;
- see the diff or sequence of changes relative to the previous state;
- read a brief explanation of the architectural decision;
- see the verification method;
- receive instructions/prompts/context with which a coding agent can reproduce or adapt the solution.

In the future, these materials can be moved to/synchronized with separate GitHub cases.

## Proposed Main Page Structure

### Hero

Explain HAIH's differentiator very briefly.

Not "yet another AI framework", but the idea of a minimal evolutionary architecture for development alongside coding agents.

The main CTA should lead to working showcases.

### Problem

Modern boilerplates/frameworks often force a project to pay for complexity upfront.

AI additionally pays for it with context and the number of connections it must understand.

### Principle

**Start minimal. Add only what the next requirement needs.**

Show visual evolution from static to complex application.

### Live Showcase

The central section of the site featuring the cases described above.

### AI / AX

Explain why the architecture is specifically optimized for coding agents: context, locality, types, compiler feedback, tests, cases.

### Best Practices / Cases

Explain the knowledge base model: do not impose a single final implementation, but gather verified architectural solutions and complete vertical changes.

### Open Source / Participate

Explain the future community loop:

```text
requirement
→ minimal solution
→ verified case
→ AI reuse
→ new projects
→ new cases
```

Invite users to try the approach, adapt cases, and publish their own solutions.

## What Not to Promise Right Now

- do not position HAIH as a ready-made universal SaaS platform;
- do not emphasize sales/monetization;
- do not promise a massive marketplace of pre-built modules that doesn't exist yet;
- do not create the impression that Prisma/Pothos/Apollo/React are mandatory;
- do not carry over the entire feature list of the old `haih-net/agent` into the new product;
- do not claim that a single correct architecture exists;
- do not overload the homepage with technical details before the user understands the value.

## Result Criteria for the Website

A new visitor with no prior knowledge of HAIH's history should understand after browsing the site:

> "I can start with a minimal project. When a new requirement appears, AI can take a verified case, add only the necessary architecture, and verify the result. I don't need to accept a massive framework in advance and drag functionality into my project that I don't have."

After grasping this idea, the user should be able to **immediately open a live showcase**, see it applied to a real project, and get enough information to try a similar approach on their own.

## Dissemination Goal

At the current stage, optimize the website for **understanding the concept, experimentation, and participation**, rather than sales.

Desired cycle:

```text
visitor
→ understands the principle
→ views a live case
→ tries the approach
→ adapts the solution with AI
→ shares their own case/best practice
→ the next user gets another verified path
```

The website should become the first public demonstration of this model and temporarily serve as a showcase/base for key cases until a fully fledged open case catalog is established.

Develop and launch haih.site as a product website for the new HAIH concept: a minimal architecture that grows with requirements, featuring live showcases ranging from a static site and standalone API to a full-featured e-commerce store.

Tasks

Develop and launch the website