Foyern: Building an AI-Native CMS for Website Generation and Continuous Management

Introduction

Website builders have traditionally followed two different approaches.

Platforms such as Webflow, Framer, and Wix provide powerful visual editors where designers or non-developers can construct websites using components, layouts, and drag-and-drop interfaces.

Newer AI development platforms such as Lovable and Replit take a different approach. A user can describe what they want in natural language, and AI can generate a working application or website.

Both approaches solve an important part of the problem.

But there is another problem that is much harder:

What happens after the website has been generated?

A business website is not a one-time generation task.

Businesses continuously need to:

• Update content
• Add services
• Change pricing
• Add team members
• Publish blogs
• Create new pages
• Change sections
• Modify buttons
• Add integrations
• Update SEO
• Connect analytics
• Change branding
• Connect domains
• Make design changes

For a developer, these changes can be straightforward.

For a non-technical business owner, however, they often become development requests.

This is the problem Foyern is designed to solve.

Foyern is an AI-native CMS and website builder where AI is responsible for generating and transforming the website, while the CMS provides a structured interface for humans to continuously manage it.

The goal is not simply:

"AI generates a website."

The goal is:

"AI generates a structured website that remains completely editable and manageable after generation."

1. The Core Engineering Problem

The fundamental problem behind Foyern is not generating HTML.

Generating a webpage is relatively easy with modern LLMs.

The difficult part is generating a website that has:

1. A predictable structure
2. A valid sitemap
3. Structured content
4. Reusable components
5. Editable fields
6. Design metadata
7. Relationships between pages and components
8. SEO metadata
9. CMS-compatible data
10. AI-modifiable structures
11. Persistent state
12. Versionable content

An AI-generated website can look excellent while still being technically difficult to maintain.

For example, an AI model could generate:

<div>
  <section>
    ...
  </section>
</div>

But Foyern needs something closer to:

Website
 ├── Pages
 │    ├── Home
 │    ├── About
 │    ├── Services
 │    └── Contact
 │
 ├── Components
 │    ├── Hero
 │    ├── ServiceGrid
 │    ├── TeamSection
 │    └── CTA
 │
 ├── Content
 │    ├── Text
 │    ├── Images
 │    ├── Buttons
 │    └── Links
 │
 ├── SEO
 │    ├── Title
 │    ├── Description
 │    └── Metadata
 │
 └── Theme
      ├── Colors
      ├── Typography
      └── Spacing

This distinction is extremely important.

Foyern is therefore fundamentally a structured website generation system, not simply an AI HTML generator.

2. Two Ways to Build a Website

Foyern is designed around two primary workflows.

Workflow A — Generate a New Website

A user can start from nothing.

For example:

"Create a website for a gym in Kerala."

Instead of immediately generating the entire website, Foyern first gathers the information required to construct a reliable website specification.

The system can ask for:

• Business name
• Branding
• Logo
• Color preferences
• Content preferences

The important architectural decision is that generation is not performed in one giant AI request.

The system first creates a structured plan.

3. Sitemap-First Generation

One of the important UX and architectural decisions in Foyern is the sitemap-first workflow.

Instead of:

Prompt
   ↓
AI
   ↓
Complete Website

Foyern follows:

User Prompt
     ↓
Requirement Understanding
     ↓
Website Specification
     ↓
Sitemap Generation
     ↓
Page Structure
     ↓
Section Structure
     ↓
Content Structure
     ↓
Design Specification
     ↓
Website Generation
     ↓
CMS

For example:

Home
 ├── Hero
 ├── About
 ├── Services
 ├── Why Choose Us
 ├── Testimonials
 └── Contact CTA

About
 ├── Company Introduction
 ├── Mission
 ├── Vision
 └── Team

Services
 ├── Service Introduction
 ├── Service Cards
 └── CTA

Contact
 ├── Contact Information
 ├── Map
 └── Contact Form

Blog
 ├── Blog Listing
 └── Blog Detail

The user can review this structure before the expensive generation stage.

This creates an important boundary between:

AI planning and AI execution.

4. Why Structured AI Output Matters

One of the hardest engineering problems in Foyern is making AI output predictable.

Large language models are probabilistic.

A CMS is not.

A CMS requires predictable structures.

For example, the application cannot reliably operate if the AI sometimes returns:

{
  "title": "Services",
  "items": [...]
}

and sometimes:

{
  "heading": "Our Services",
  "serviceList": [...]
}

The AI layer therefore needs a strict contract.

Conceptually:

User Request
     ↓
LLM
     ↓
Structured Schema
     ↓
Validation
     ↓
Normalization
     ↓
CMS Data Model

The system needs to validate:

• Required fields
• Data types
• Component types
• Page structure
• Content relationships
• Theme values
• SEO metadata
• IDs
• References

The AI output becomes an input to the application—not the application itself.

This separation is critical.

5. AI Website Generation Pipeline

The generation pipeline can be viewed as multiple stages.

User Prompt
                     │
                     ▼
             Requirement Parser
                     │
                     ▼
              Website Planner
                     │
                     ▼
                Sitemap
                     │
                     ▼
             Page Architect
                     │
                     ▼
            Section Generator
                     │
                     ▼
             Content Generator
                     │
                     ▼
              Design Engine
                     │
                     ▼
             Schema Validator
                     │
                     ▼
              CMS Persistence
                     │
                     ▼
              Website Renderer

Each stage has a different responsibility.

This prevents a single LLM request from becoming responsible for the entire application.

6. AI Design Generation

Generating technically valid content is only one part of the problem.

The generated website also needs to look good.

This introduces another major engineering challenge.

The AI needs to understand concepts such as:

• Visual hierarchy
• Typography
• Spacing
• Section composition
• Responsive layouts
• CTA placement
• Content density
• Component relationships
• Color systems
• Image placement
• Mobile layouts

A naive implementation might ask:

"Create a modern gym website."

The result may technically work, but visual quality can vary significantly.

Foyern therefore requires a controlled design-generation system.

Conceptually:

Business Context
      +
Brand Identity
      +
Sitemap
      +
Design Rules
      +
Component Library
      +
LLM
      ↓
Design Specification

The objective is not to allow the model to freely invent every CSS decision.

Instead, AI should operate within a controlled design system.

7. Design System as an AI Constraint

A reusable component system becomes extremely important.

For example:

Hero
ServiceGrid
FeatureSection
TestimonialSection
TeamSection
PricingSection
FAQ
ContactSection
CTA
Footer

Each component can have a defined schema.

For example:

{
  "type": "service-grid",
  "title": "Our Services",
  "description": "...",
  "items": [
    {
      "title": "Personal Training",
      "description": "...",
      "icon": "..."
    }
  ]
}

The AI generates the data and configuration.

The rendering engine owns the actual implementation.

This provides a much safer architecture than allowing the LLM to generate arbitrary frontend code for every change.

8. Reference-Based Website Redesign

The second major Foyern workflow is redesign.

A user may already have a website they like.

Instead of manually explaining its layout, the user can provide a website URL and describe what they want.

For example:

"Use this website as inspiration, but create a modern website for my business using my branding."

The pipeline becomes:

Reference URL
      ↓
Website Analysis
      ↓
Structure Extraction
      ↓
Page/Sitemap Detection
      ↓
Layout Understanding
      ↓
Design Pattern Extraction
      ↓
User Branding
      ↓
AI Redesign
      ↓
New Structured Website

The important distinction is that Foyern should not simply copy the reference website.

The reference acts as a design and structural input.

The generated website is reconstructed using Foyern's own component and design system.

9. Website Understanding Is a Different AI Problem

Reference redesign introduces another technically interesting challenge.

The system needs to understand a website before it can redesign it.

The input may contain:

HTML
CSS
Images
Navigation
Typography
Sections
Links
Metadata
Content
Layout

The system must transform this into a higher-level representation.

For example:

Website
 ├── Navigation
 ├── Hero
 │    ├── Heading
 │    ├── Description
 │    └── CTA
 │
 ├── Features
 │    ├── Feature 1
 │    ├── Feature 2
 │    └── Feature 3
 │
 ├── Testimonials
 └── Footer

This is effectively a website understanding problem before it becomes a generation problem.

10. The CMS Is the Most Important Part

AI generation gets attention.

But the CMS is what makes the generated website useful long-term.

After generation, a user should not need AI for every basic operation.

For example:

Pages
 ├── Home
 ├── About
 ├── Services
 ├── Contact
 └── Blog

The user selects:

Services

Then selects:

Service Card

Then changes:

Title
Description
Image
Button

No developer is required.

No prompt is required.

No code is required.

This is the core CMS experience.

11. Visual Content Editing

Foyern separates normal CMS operations from AI operations.

Traditional CMS operation

Click Content
      ↓
Edit
      ↓
Save

AI operation

Select Section
      ↓
Describe Change
      ↓
AI interprets request
      ↓
Structured modification
      ↓
Preview
      ↓
Apply

For example:

"Add a WhatsApp booking button to this section."

The AI does not need to regenerate the entire website.

Instead:

Existing Section
       ↓
AI interprets request
       ↓
Section Modification
       ↓
Schema Validation
       ↓
Updated Section

This is much safer and more efficient.

12. AI as a CMS Mutation Layer

This is one of the interesting architectural ideas behind Foyern.

AI is not only a content generator.

It becomes a mutation layer over structured CMS data.

For example:

User:
"Add a team section below the services section."

The AI converts this into an operation such as:

{
  "operation": "insert_section",
  "page": "home",
  "position": 4,
  "component": "team-section"
}

Another request:

"Change the hero button to WhatsApp booking."

Could become:

{
  "operation": "update_component",
  "componentId": "hero-001",
  "field": "cta",
  "value": {
    "type": "whatsapp",
    "label": "Book Now"
  }
}

The backend then validates and executes the operation.

This is fundamentally different from:

Prompt → Generate entire website again

Instead:

Prompt
  ↓
Intent
  ↓
Structured Operation
  ↓
Validation
  ↓
CMS Mutation
  ↓
Renderer

13. Page Creation

Creating a new page follows the same architecture.

Example:

"Create a pricing page."

The system can generate:

Pricing Page
 ├── Hero
 ├── Pricing Cards
 ├── Feature Comparison
 ├── FAQ
 └── CTA

The page is stored as structured CMS data.

This means the page can later be modified using either:

• Visual editing
• AI editing
• Direct content editing

14. Domain Architecture

A website builder also has an infrastructure problem.

Each generated website needs to be accessible independently.

Conceptually:

customer1.foyern.com
customer2.foyern.com
customer3.foyern.com

And eventually:

www.customer-domain.com

The request routing layer needs to determine:

Incoming Request
       ↓
Hostname
       ↓
Tenant Resolution
       ↓
Website ID
       ↓
CMS Configuration
       ↓
Page
       ↓
Renderer

This makes Foyern a multi-tenant platform.

The hostname itself becomes part of tenant resolution.

15. Multi-Tenant Architecture

At a high level:

Foyern Platform
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
     Tenant A          Tenant B          Tenant C
        │                 │                 │
     Website A         Website B         Website C
        │                 │                 │
      Pages             Pages             Pages
        │                 │                 │
     Content           Content           Content

Every tenant needs isolation across:

• Users
• Websites
• Pages
• Content
• Media
• Domains
• Analytics configuration
• SEO configuration
• AI operations

This makes tenant identification and authorization critical backend concerns.

16. Technology Architecture

The current Foyern architecture uses a modern JavaScript/TypeScript stack.

Frontend

React
Next.js
TypeScript

The frontend is responsible for:

• CMS dashboard
• Page editor
• Visual editing
• Website preview
• AI interaction
• Page management
• SEO management
• Settings
• Domain configuration

Backend

Node.js
Express.js
TypeScript

The backend manages:

• Authentication
• Authorization
• Websites
• Pages
• Components
• Content
• AI orchestration
• Domain mapping
• CMS operations
• Integrations
• Persistence

Database

MongoDB

MongoDB is useful for the flexible and hierarchical nature of website structures.

A website can contain different page types and component structures without requiring every page to have an identical relational schema.

Cache / Fast Data Layer

Redis

Redis can be used for:

• Caching
• Sessions
• Temporary generation state
• Rate limiting
• AI workflow state
• Frequently accessed website configuration
• Short-lived data

AI

Google Vertex AI
Gemini

The AI layer handles tasks such as:

• Requirement understanding
• Sitemap generation
• Content generation
• Design reasoning
• Website analysis
• Reference redesign
• CMS modifications
• Structured output generation

Infrastructure

AWS
Google Cloud
Vercel

Different infrastructure layers can be responsible for different workloads, including application hosting, AI services, databases, storage, and delivery.

17. High-Level Architecture

The system can be visualized as:

┌───────────────────┐
                         │      User         │
                         └─────────┬─────────┘
                                   │
                         Prompt / Visual Editor
                                   │
                                   ▼
                    ┌─────────────────────────┐
                    │      Next.js / React    │
                    │      Foyern Frontend    │
                    └────────────┬────────────┘
                                 │
                                 ▼
                    ┌─────────────────────────┐
                    │      Node.js API        │
                    │      Express.js          │
                    └────────────┬────────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
              ▼                  ▼                  ▼
        ┌───────────┐      ┌───────────┐      ┌────────────┐
        │  MongoDB  │      │   Redis   │      │ AI Layer   │
        │           │      │           │      │ Vertex AI  │
        └───────────┘      └───────────┘      │ Gemini     │
                                               └─────┬──────┘
                                                     │
                                                     ▼
                                            Structured AI Output
                                                     │
                                                     ▼
                                            CMS Validation Layer
                                                     │
                                                     ▼
                                               CMS Storage
                                                     │
                                                     ▼
                                               Website Renderer
                                                     │
                                                     ▼
                                              Public Website

18. AI Orchestration

A major engineering challenge is deciding when and how AI should be called.

A single prompt may require multiple AI operations.

For example:

User Prompt
    ↓
Requirement Analysis
    ↓
Brand Extraction
    ↓
Sitemap Generation
    ↓
Page Planning
    ↓
Section Planning
    ↓
Content Generation
    ↓
Design Generation
    ↓
Validation
    ↓
Persistence

Each stage can have its own prompt, schema, validation rules, and retry strategy.

This makes the AI layer closer to a workflow engine than a simple chatbot.

19. AI Reliability

LLM output cannot simply be trusted.

The system needs multiple layers of validation.

LLM
 ↓
Schema Validation
 ↓
Business Rules
 ↓
Component Validation
 ↓
Content Validation
 ↓
Security Validation
 ↓
Persistence

For example, if AI produces:

{
  "type": "unknown-component"
}

the backend should reject it.

Similarly, AI should not be allowed to arbitrarily modify unrelated pages or tenant data.

The AI layer must operate within controlled boundaries.

20. Prompt Engineering Is Not Enough

One of the biggest lessons from building Foyern is that AI quality cannot be solved only by writing better prompts.

High-quality generation requires a combination of:

Prompt Design
+
Structured Schemas
+
Component Constraints
+
Design Rules
+
Context Management
+
Validation
+
Evaluation
+
Iteration

The model needs the right context.

For example:

Business Information
+
Brand Guidelines
+
Existing Sitemap
+
Existing Components
+
Current Page
+
User Request

The AI can then generate a modification based on the actual website state.

21. Context-Aware AI Editing

Suppose a user says:

"Make this section more premium."

A generic LLM does not know what "this section" means.

Foyern needs to provide contextual information such as:

Website ID
Page ID
Section ID
Component Type
Current Content
Current Design
Brand Theme
Nearby Sections

Then the AI can reason about the actual component.

Conceptually:

User Prompt
     +
Current CMS State
     +
Component Schema
     +
Brand System
     ↓
AI
     ↓
Structured Mutation

This allows the AI to modify the existing website instead of generating unrelated output.

22. Rendering Architecture

The frontend renderer should not depend directly on raw AI output.

Instead:

MongoDB
   ↓
CMS Document
   ↓
Normalization
   ↓
Component Resolver
   ↓
React Components
   ↓
Next.js Rendering

For example:

"type": "hero"

maps to:

HeroComponent

while:

"type": "service-grid"

maps to:

ServiceGridComponent

This creates a controlled rendering environment.

23. Why This Architecture Matters

This architecture provides a major advantage.

AI can evolve independently from the rendering engine.

The model can become better at:

• Content
• Layout selection
• Component selection
• Design reasoning

without requiring the entire frontend architecture to change.

Likewise, frontend components can improve without retraining the AI system.

This creates a clean separation:

AI Intelligence
       │
       ▼
Structured Website Model
       │
       ▼
Rendering Engine

24. SEO and External Integrations

A complete CMS cannot stop at page editing.

Foyern also needs to manage technical website configuration such as:

• Page titles
• Meta descriptions
• Open Graph metadata
• Canonical URLs
• Sitemap
• Robots configuration
• Structured data
• Google Analytics
• Google Search Console
• Microsoft Clarity
• Custom scripts
• Tracking codes

These should be exposed through the CMS instead of requiring developers to modify source code.

25. Custom Code Without Losing Control

Advanced users may still need custom integrations.

Therefore, a website builder needs a controlled extension mechanism.

For example:

Head Scripts
Body Scripts
Analytics
Tracking
Custom CSS
Integration Configuration

The challenge is allowing customization without allowing arbitrary code to compromise the platform or other tenants.

This introduces another important engineering area:

tenant isolation and code execution security.

26. Blog and Content Management

A website is also a content platform.

Foyern therefore treats blog content as structured CMS data.

Conceptually:

Blog
 ├── Posts
 │    ├── Title
 │    ├── Slug
 │    ├── Content
 │    ├── Author
 │    ├── Cover Image
 │    ├── SEO
 │    └── Publication Status
 │
 └── Legals

Users can create and manage articles without modifying application code.

27. User Access and Permissions

Foyern supports two user roles for managing websites: Owner and User.

This makes access control an important backend responsibility.

Conceptually:

Organization
     │
     ├── Owner
     └── User

The Owner has complete control over the account and website, including:

• Managing the account
• Managing user access
• Adding or removing users
• Managing roles and permissions
• Managing website settings
• Managing pages
• Managing content
• Managing blogs
• Managing AI operations
• Managing domains
• Managing analytics
• Managing integrations

The User has limited access focused only on website content. Users can:

• Edit page content
• Add and edit blog posts
• Manage existing content
• Update text, images, buttons, and other editable fields

Users cannot manage account settings, user access, domains, analytics, integrations, or other administrative features.

This role-based structure allows Foyern to support teams while ensuring that only owners can manage the account, users, and overall website configuration.

28. The Difficult Part: AI Evaluation

One of the largest parts of the project is not writing the AI integration.

It is evaluating whether the generated result is actually good.

A generation pipeline needs to be tested against many scenarios:

Gym Website
Restaurant Website
Law Firm Website
Agency Website
Education Website
Healthcare Website
Portfolio Website
Service Business Website
E-commerce Landing Page

The evaluation cannot only ask:

"Did the AI return valid JSON?"

It also needs to evaluate:

• Is the sitemap sensible?
• Is the page structure appropriate?
• Is the content coherent?
• Are sections duplicated?
• Is the design visually balanced?
• Are CTAs appropriate?
• Is the content too long?
• Is mobile structure reasonable?
• Does the generated website match the brand?
• Can the resulting structure be edited?

This turns AI development into an evaluation engineering problem.

29. Generation Quality vs CMS Quality

Foyern has two different quality dimensions.

Generation Quality

Does the AI create a good website?

Management Quality

Can a human easily manage that website afterward?

A system can be excellent at the first and terrible at the second.

Foyern's architecture attempts to solve both.

Foyern
                    │
          ┌─────────┴─────────┐
          │                   │
     AI Generation       CMS Management
          │                   │
      Create            Edit
      Redesign          Add
      Generate          Delete
      Transform         Publish
          │                   │
          └─────────┬─────────┘
                    │
             Structured Website

30. Why Foyern Is Technically Interesting

The interesting engineering problem is the combination of several systems.

Foyern is simultaneously:

AI Application
       +
CMS
       +
Website Builder
       +
Design System
       +
Multi-Tenant SaaS
       +
Website Renderer
       +
Domain Platform
       +
Content Management System

Each of these is a significant engineering problem on its own.

Combining them creates a much more complex system.

31. The Central Architectural Principle

The most important principle behind Foyern is:

AI should generate and modify structured website state, not simply generate source code.

This principle affects almost every architectural decision.

Instead of:

Prompt
 ↓
HTML
 ↓
Deploy

Foyern follows:

Prompt
 ↓
Intent
 ↓
Structured Specification
 ↓
Sitemap
 ↓
Page Model
 ↓
Component Model
 ↓
Content Model
 ↓
Design Model
 ↓
Validation
 ↓
CMS
 ↓
Renderer
 ↓
Website

And for modifications:

User Request
 ↓
Context
 ↓
Intent Detection
 ↓
Structured Mutation
 ↓
Validation
 ↓
CMS Update
 ↓
Renderer

This makes AI a controlled part of the application architecture.

32. What Makes the Project Complex

From the outside, Foyern can look simple:

Prompt → Website

Internally, however, the system looks more like:

┌───────────────┐
                    │ User Request  │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │ AI Orchestrator│
                    └───────┬───────┘
                            │
              ┌─────────────┼──────────────┐
              ▼             ▼              ▼
          Sitemap        Content        Design
              │             │              │
              └─────────────┼──────────────┘
                            ▼
                     Schema Validation
                            │
                            ▼
                       CMS Model
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          MongoDB         Redis        Media/Assets
             │
             ▼
        Website Renderer
             │
             ▼
       Domain Resolution
             │
             ▼
       Production Website

And the system must support the reverse direction:

Existing Website
       ↓
Website Understanding
       ↓
Structure Extraction
       ↓
AI Redesign
       ↓
Foyern CMS Model
       ↓
New Website

That is the real technical scope of the platform.

33. Engineering Challenges

The major technical challenges in Foyern include:

1. Reliable AI generation

Producing consistently high-quality website structures rather than unpredictable output.

2. Structured AI responses

Converting probabilistic LLM output into deterministic application data.

3. Design quality

Generating visually strong layouts while maintaining consistency.

4. Website understanding

Understanding an existing website well enough to reconstruct its structural patterns.

5. AI mutations

Allowing natural-language requests to safely modify existing CMS state.

6. Context management

Giving AI enough website context without sending unnecessary data into every request.

7. Multi-tenancy

Keeping websites, users, content, domains, and configuration isolated.

8. Rendering

Converting a flexible CMS schema into performant production websites.

9. Domain routing

Mapping custom domains and subdomains to the correct tenant and website.

10. AI evaluation

Measuring whether generated websites are actually useful instead of only syntactically valid.

11. Performance

Handling generation workloads while keeping normal CMS operations fast.

12. Security

Controlling AI operations, custom scripts, permissions, tenant isolation, and external integrations.

34. Foyern as an AI-Native CMS

Traditional CMS architecture is generally:

Database
   ↓
CMS
   ↓
Human
   ↓
Content

AI-native CMS architecture becomes:

┌───────────────┐
                 │     Human     │
                 └───────┬───────┘
                         │
              ┌──────────┴──────────┐
              │                     │
        Visual Editor          Natural Language
              │                     │
              └──────────┬──────────┘
                         ▼
                   CMS State
                         │
                         ▼
                    Website

AI becomes another interface to the CMS.

That is the deeper idea behind Foyern.

The user does not need to understand the underlying implementation.

They can interact with the website through either:

Direct manipulation

or

Natural language.

35. Final Perspective

Building an AI website generator is relatively straightforward compared with building an AI-native CMS.

The difficult question is not:

"Can AI generate a website?"

Modern AI can already do that.

The difficult question is:

"Can AI generate a website that remains structured, editable, extensible, maintainable, and production-ready for the lifetime of the website?"

That requires solving problems across:

• LLM orchestration
• Structured generation
• Schema design
• AI evaluation
• Design systems
• CMS architecture
• Multi-tenancy
• Website rendering
• Domain routing
• Content management
• SEO
• Authentication
• Authorization
• Caching
• Infrastructure
• Security

Foyern is built around that problem.

The ultimate architecture is therefore not:

AI → Website

It is:

┌──────────────────┐
                 │    Natural       │
                 │    Language      │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │   AI Reasoning   │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │ Structured Web   │
                 │     Model        │
                 └────────┬─────────┘
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
          Content       Design       Pages
             │            │            │
             └────────────┼────────────┘
                          ▼
                 ┌──────────────────┐
                 │       CMS        │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │ Website Renderer │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │    Production    │
                 │     Website      │
                 └──────────────────┘

Foyern is an attempt to bridge the gap between AI website generation and the long-term maintainability of a real CMS.

The website is generated by AI.

The structure is controlled by the platform.

The content remains editable.

The design remains changeable.

And AI becomes an additional interface for continuously evolving the website.