> ## Documentation Index
> Fetch the complete documentation index at: https://archie.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> The Archie frontend — a generated React app with visual editing, chat-based code edits, and a full IDE for direct code work.
The Archie frontend is the user-facing layer of every app you build. Archie generates a modern web application — typically React-based with a component library, routing, and state management — from your plan and specifications.
Getting there happens in stages: Archie lays out a UI architecture, you generate an interactive prototype from it, then Archie turns that prototype into the real, deployed app. See [Generating the frontend](/docs/features/frontend/generating) for how that works, and [Prototype](/docs/features/frontend/prototype/overview) for shaping how it looks and browsing every generated screen. Once the app exists, you customize it with three modalities that work together.
## Prototype vs. the real frontend
"Frontend" in Archie actually spans two distinct surfaces. They look similar — both render your screens — but they exist for different reasons, and confusing them leads to the wrong expectations about what's safe to click and what actually ships.
| | Prototype | Real frontend |
| - | - | - |
| **What it's for** | Refining design and flows before you commit to a build | The application you deploy and give to users |
| **Data** | Mock data, generated to look realistic | Real data, read and written through [Archie Core](/docs/features/backend/overview) |
| **Persistence** | Nothing is saved as application state — you're editing the design, not records | Fully persistent — creates, edits, and deletes flow through the database |
| **Backend connection** | None | Connected — auth, file storage, integrations, APIs |
| **Deployable** | No — it's a design and refinement tool | Yes |
| **What editing changes** | The screen's design spec — layout, copy, theme | Real source code |
| **IDE access** | No — there's no source code to open | Yes — direct code editing |
The prototype is a design tool, not a working app in miniature. Every screen renders from mock data, and there is no real functionality behind the buttons — its purpose is to let you validate layout, navigation, and how your theme reads on real content, while a screen still costs little to change. The real frontend is a different kind of thing entirely: it's the deployable application, wired to Archie Core for data, auth, and file storage, and integrated with whatever third-party services your plan calls for.
Both surfaces are edited the same way — point at an element and use the inspector, or describe the change in chat. [Prototype editing](/docs/features/frontend/prototype/screens/editing) acts on that screen's design spec and re-renders it; the [visual editor](/docs/features/frontend/visual-editor) and [chat](/docs/features/frontend/talking-to-archie) on the real frontend act on the actual source code. The IDE is the one tool exclusive to the real frontend, since the prototype has no underlying code to open.
The real frontend is generated **from the prototype**, not straight from the plan. That's the reason to spend real effort refining the prototype: every layout problem, awkward flow, or off-brand screen you catch and fix there is one the generated frontend will already get right — instead of something you have to track down and fix again in production code after the build.
## Three editing modalities
Describe a change in plain language. The chat applies it across files.
Point and click for layout, copy, and styling.
Direct code editing in the browser, with syntax highlighting, IntelliSense, and search.
Each modality fits a different kind of work. The chat is the primary path for most edits. The visual editor is for layout and copy tweaks. The IDE is for logic-heavy changes and custom code.
## What's in this section
* **[Generating the frontend](/docs/features/frontend/generating)** — UI architecture, prototype, and the real app
* **[Prototype](/docs/features/frontend/prototype/overview)** — theme, branding, and every generated screen
* **[Visual editor](/docs/features/frontend/visual-editor)** — point-and-click element editing
* **[Draw mode](/docs/features/frontend/draw-mode)** — annotate the preview and send your marks to chat
* **[Talking to Archie](/docs/features/frontend/talking-to-archie)** — using the chat for code edits
* **[Theming](/docs/features/frontend/theming)** — branding, colors, fonts, dark mode
* **[Routing](/docs/features/frontend/routing)** — pages, dynamic routes, navigation
* **[Connecting to the backend](/docs/features/frontend/connecting-to-the-backend)** — API client, auth tokens, real-time
* **[Deployment](/docs/features/frontend/deployment)** — publishing to Archie's hosting or self-deploy
## What the frontend includes
A generated Archie frontend ships with:
* A page router with route definitions for every feature in your plan
* A component library based on shadcn/ui with your branding applied
* Authentication wired to your chosen [auth provider](/docs/features/backend/app-services/authentication-providers/overview)
* A typed API client for your project's GraphQL and REST endpoints
* Real-time subscriptions for live data
* Form handling with validation matching your spec rules
* Internationalization, with at least your primary locale populated
The frontend talks to [Archie Core](/docs/features/backend/overview) for everything backend — data, auth, file storage, integrations.
## Stack
The default stack is Next.js with TypeScript, Tailwind, and shadcn/ui. Stacks Archie supports out of the box include Next.js, Vite + React, and SvelteKit. The tech stack is chosen and managed by Archie automatically — it is not shown or editable in the plan. If you need a specific stack, mention it in your prompt before generating. The frontend connects to Archie Core regardless of the chosen stack.
## Customizing further
For changes the chat and visual editor cannot express — custom hooks, complex state management, third-party libraries — open the IDE and edit the code directly. Hand edits are preserved across rebuilds; see [Specifications and code generation](/docs/features/specifications/specifications-and-code-generation) for the regeneration semantics.