Skip to main content
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 for how that works, and Prototype 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. 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 acts on that screen’s design spec and re-renders it; the visual editor and chat 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

Talk to Archie

Describe a change in plain language. The chat applies it across files.

Visual editor

Point and click for layout, copy, and styling.

IDE

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

​
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
  • 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 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 for the regeneration semantics.