Skip to main content

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.

You don’t need to write a perfect prompt. Archie is built so most of the refinement happens on the blueprint, not on the prompt — your prompt is a starting point, and the blueprint is where you shape what gets built. This page covers how to think about the description you give Archie and where iteration actually pays off.

​
Be specific about the problem

Tell Archie what the product does and who it’s for. The two together give Archie enough to choose a sensible set of modules, a user model, and a starting tech stack. “An app for managing freelance invoices” is enough. So is “an internal tool for logistics dispatchers to track driver shifts.” If you don’t know yet what your product is exactly, that’s okay — Archie can generate a blueprint from a rough idea and you sharpen it from there.

​
Give context about your users

Mention the people who’ll use the product. A scheduling app for hairstylists has different user types than a scheduling app for surgeons; a B2B marketplace looks different from a consumer one. The more Archie knows about who the app serves, the more accurate its first pass at user types, permissions, and feature areas. You don’t need to enumerate every persona. One or two is enough — Archie will draft the rest in the blueprint.

​
Iterate on the blueprint, not the prompt

Once Archie generates the blueprint, that’s where to spend your time. Add or remove modules, rename user types, swap an integration, change a service. The blueprint is the source of truth for the build, and edits there shape what the code looks like before any code is generated. Re-prompting from scratch is rarely the right move. If your blueprint drifts from what you wanted, edit it in place — that’s faster and keeps the work you’ve already done. See Editing modules, Editing user types, and Iterating for how to make blueprint changes.

​
Ask Archie clarifying questions

If you’re unsure whether something is feasible — “can I add a webhook here”, “should auth happen at the org level or the user level” — ask Archie inside the blueprint chat. Archie answers in plain language and offers to make the change for you. This is faster than guessing and rebuilding.

​
After the build

Once the app is generated, you switch from shaping the blueprint to editing the running app:
  • Chat — describe a change (“make the sidebar collapsible”) and Archie applies it across the right files. This is the primary editing modality.
  • Visual editor — point and click for layout, copy, and styling. See Visual editor.
  • IDE — direct code editing for logic-heavy changes.
Go back to the blueprint when a change is structural — a new user type, a new module, swapping a payment provider. Smaller changes belong in chat or the visual editor.

​
FAQ

No. Archie’s flow is designed so you don’t have to. Describe your product and your users in plain language and let the blueprint do the heavy lifting. Tricks like “you are a senior architect” don’t help here.
Edit the blueprint first. Adding, removing, or renaming a module is faster than starting over and you keep the work that’s already correct. Re-prompt only when the blueprint is fundamentally off from what you intended.
A few sentences is usually enough. Name the product, the users, and a couple of core actions. Archie drafts the feature areas and you refine them in the blueprint — adding modules by clicking is faster than listing them in a prompt.
Not unless you have a hard requirement. Archie recommends a stack tailored to your app, and you can override it inside the blueprint. Naming a stack up front mostly just constrains Archie’s recommendations.
Yes. The prompt bar accepts screenshots, mockups, and design references. Archie uses them to inform visual direction and overall design.