Best practices

You don’t need to write a perfect prompt. Archie is built so most of the refinement happens on the plan, not on the prompt — your prompt is a starting point, and the plan 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 plan 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 plan.

​

Iterate on the plan, not the prompt

Once Archie generates the plan, that’s where to spend your time. Add or remove modules, rename user types, swap an integration, change a service. The plan 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 plan 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 plan 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 plan 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 plan 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 plan 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