Fabricate keeps your conversation as context across messages, and the agent can read your code whenever it needs to. Follow-up prompts can be short, because the agent already knows what you’ve built so far.
The Iteration Loop
1
Look at the live preview
Click through the app. Find the single most important thing to change next.
2
Send one focused follow-up
Describe that one change clearly. Let it build and update the preview.
3
Check the result
Did it do what you expected? If yes, move to the next change. If not, refine.
4
Repeat
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 — be specific, change one thing — but with one addition: say what to keep, so the agent knows the boundary of the change.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:Ask Before You Build
When a change is large or you’re unsure how to approach it, ask Fabricate about it first, and say you don’t want any changes yet. The agent can read your code and help you plan. Questions use credits, like any message. A reliable pattern:1
Ask first
“I want to add team workspaces where users invite others and assign roles. Don’t build anything yet — how should this be structured?”
2
Agree on an approach
Discuss the data model and the screens until the plan is clear.
3
Build it step by step
Build the agreed plan one feature at a time, using your follow-up prompts.
Queue Messages While Fabricate Builds
While the agent is building, you don’t have to wait idle to line up your next instruction. Send a follow-up message and it waits in line — the chat marks it Queued. Runs after this build. — then runs after the current build finishes. Queued messages run in the order you sent them. Queuing 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.
Revert with Version History
Iteration is safe to experiment with because Fabricate keeps version history. Each build saves a version of your app’s code, so if a change takes your app in the wrong direction, you can go back to an earlier version and continue from there. Going back restores your code, not the data stored in your app. 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.
1
Find an earlier version
Select Go back to this point under an earlier message, or open the history button in the chat header to see recent versions.
2
Pick the version to restore
Choose a version from before the change you want to undo.
3
Restore and keep going
Confirm with Restore and redeploy, then send a new prompt to continue from the known-good state.
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?
Prompting Best Practices
The framework for writing prompts and follow-ups that work.
Asking Questions
Plan changes by asking before you build them.
Prompt Examples
Strong starter prompts grouped by app type.
Building in the Chat
How Fabricate turns each follow-up into code.