Skip to main content

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.

Most issues in Fabricate are quick to resolve. This page covers the problems people run into most often and how to get unstuck.
For build and runtime errors specifically — and how the Fix with Fabricate flow works — see Common Errors.

​
Common problems

Fabricate builds in phases, and large features take time — a long step is usually normal progress, not a freeze.
  • Watch the activity in the chat. If steps are still appearing, it’s working.
  • Big first builds and wide-reaching changes naturally take longer than small tweaks.
  • If it’s genuinely unresponsive, refresh the page. Your project is saved, so you won’t lose work — then resend your last message if it didn’t complete.
The live preview renders your app as it builds, so it can briefly go blank while a change is applied.
  • Give it a moment to finish — the preview refreshes automatically when a change lands.
  • If it stays blank, the running app may have an error. Look for a Fix with Fabricate prompt and use it, or describe what you see in a follow-up message.
  • Try refreshing the page if the preview panel itself looks unresponsive.
If the preview doesn’t reflect what you asked for:
  • Confirm the message finished — a change is only live once the build step completes.
  • Hard-refresh the preview to clear a stale view.
  • Be more specific. “Make it bigger” is ambiguous; “Increase the heading font size on the home page to about 1.5x” is actionable.
  • If Fabricate changed the wrong thing, point at the exact element: “The button in the page header, not the one in the footer.”
Use version history to revert to the snapshot from before that message, then re-prompt with a tighter scope.To prevent it next time, name what should stay put: “Add a footer — don’t change the existing navbar or home page layout.”
Unexpected results usually trace back to an ambiguous prompt.
  • Reply with a correction describing the gap between what you got and what you wanted.
  • Break a big request into smaller, focused messages.
  • Attach a screenshot or mockup so Fabricate has a visual reference — see Working with Images.
  • Plan tricky features before building — see Prompting Best Practices.
Credits power each build message. To make them last:
  • Send focused, specific prompts — vague requests often need follow-up corrections that cost more.
  • Batch related tweaks into one well-described message instead of many tiny ones.
  • Revert with version history instead of prompting your way back out of an unwanted change.
  • See Plans & Credits for how credits work and how to get more.
The preview and deployed app run the same code, so differences usually mean a deploy happened before the latest change finished.
  • Make sure your most recent change completed, then deploy again.
  • Open the deployed app and click through the broken flow, then describe the exact behavior to Fabricate so it can fix and redeploy.
  • Ask Fabricate to investigate: “The projects page is slow to load — find out why and optimize it.”
  • For data-heavy pages, request database indexes — see Database.
  • Keep feature requests focused so the app stays lean and fast.

​
When you’re still stuck

1

Describe the problem precisely

Tell Fabricate what you did, what you expected, and what actually happened.
2

Add a screenshot

A picture of the issue from the live preview removes all ambiguity.
3

Revert and retry

If a change went wrong, roll back with version history and re-prompt with a clearer, narrower request.
Fabricate can read your app’s errors and current code state, so a clear follow-up message is often all it takes to fix an issue.