Task: Develop and launch the website

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:

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:

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:

API only

or, if persistence is needed:

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:

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:

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:

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:

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:

                  ┌→ 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:

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:

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.