> ## Documentation Index > Fetch the complete documentation index at: https://fabricate.build/docs/llms.txt > Use this file to discover all available pages before exploring further. # Iterating on Your App > How to refine your app after the first build — follow-up prompts, fixing one thing at a time, planning in Discuss Mode, version history, and the Prompt Queue. Your first build is a starting point, not a finish line. The real work — and the fun — happens as you iterate: send a follow-up, watch the live preview update, refine again. This page covers how to do that well. Fabricate keeps your conversation and codebase as context across every message. Follow-up prompts can be short, because the agent already knows what you've built so far. ## The Iteration Loop Click through the app. Find the single most important thing to change next. Describe that one change clearly. Let it build and update the preview. Did it do what you expected? If yes, move to the next change. If not, refine. Each small, verified step compounds into a polished app. ## Write Good Follow-Up Prompts Follow-ups are where most of your prompting happens. The same rules apply as in [Prompting Best Practices](/prompting/best-practices) — be specific, change one thing — but with one addition: **say what to keep**, so the agent knows the boundary of the change. ```text Instead of this theme={null} Make the homepage better. ``` ```text Try this theme={null} On the homepage, move the "Sign up" button into the hero section next to the headline, and make it the primary blue. Leave the rest of the homepage as it is. ``` Good follow-ups for common situations: ```text theme={null} Add a "Mark as favorite" button to each item card. Favorited items get a filled star icon. ``` ```text theme={null} The contact form submits but doesn't tell the user anything. Show a success message after submitting and clear the fields. ``` ```text theme={null} Change the dashboard layout to two columns on desktop and one column on mobile. Keep the same cards. ``` ## Fix One Thing at a Time When something is broken or off, resist listing every problem in one message. Fixing issues one at a time makes it clear which fix worked and keeps changes isolated. Describe the problem concretely — what you did, what happened, what you expected: ```text Instead of this theme={null} The app is buggy, lots of stuff doesn't work. ``` ```text Try this theme={null} On the projects page, clicking a project card does nothing. Clicking a card should open that project's detail page. ``` If the agent generates code that doesn't work, just describe what you see in a follow-up. Fabricate can read the current code and the error, so it can usually correct itself in the next message. ## Discuss Before You Build When a change is large or you're unsure how to approach it, switch to [Discuss Mode](/build/discuss-mode) first. Discuss Mode is free — the agent can read your codebase and help you plan, but it won't modify code. It's the right place to think. A reliable pattern: "I want to add team workspaces where users invite others and assign roles. How should this be structured?" Discuss the data model and the screens until the plan is clear. Build the agreed plan one feature at a time, using your follow-up prompts. Planning first means your build messages are sharper — and sharper messages produce better results. ## Use the Prompt Queue While the agent is building, you don't have to wait idle to line up your next instruction. The **Prompt Queue** lets you add follow-up messages that run in order, one after the other, as the agent finishes each task. The Prompt Queue is useful when: * You already know your next two or three changes and want to set them up in a row. * You thought of a refinement while watching a build and want to capture it before you forget. * You're working through a clear checklist of small, independent tweaks. Queue changes that are independent. If a later prompt depends on how an earlier one turns out, wait and review the result first — you may want to adjust your next message based on what you see in the preview. ## Revert with Version History Iteration is safe to experiment with because Fabricate keeps **version history**. Each build creates a snapshot, so if a change takes your app in the wrong direction, you can revert to an earlier snapshot and continue from there. Use version history when: * A change had unintended side effects and you'd rather start the step over. * You preferred how the app worked a few messages ago. * You want to try a bold change knowing you can roll it back. Find the version history panel for your project. Browse back to a snapshot from before the change you want to undo. Restore that snapshot, then send a new prompt to continue from the known-good state. Stuck in a loop where each fix creates a new problem? Revert to the last snapshot that worked, then re-approach the change with a clearer, more specific prompt — often after planning it in Discuss Mode. ## Knowing When to Stop Iterate toward a clear goal, not forever. When the live preview does what you set out to build, you're ready to publish. Polish is good; endless tweaking is not — ship it, get real feedback, and let that guide your next round of prompts. ## What's Next? The framework for writing prompts and follow-ups that work. Plan changes for free before you build them. Strong starter prompts grouped by app type. How Build Mode turns each follow-up into code.