Skip to main content
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 Fabricate finds and fixes them — see Common Errors.

​
Common problems

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 the page itself seems unresponsive, refresh it. Builds run on Fabricate’s servers, so refreshing doesn’t stop a build or lose your work. If a build was interrupted, the chat offers Resume build — use it rather than resending your message, which would start a new run.
The live preview updates when the agent deploys a change. On a new app’s first build, the app appears when the build finishes.
  • Give it a moment to finish — the preview refreshes automatically when a change is deployed.
  • If it stays blank after the build finishes, the running app may have an error. 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 go back to the version 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.
Every message uses credits. 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.
  • Go back to an earlier version instead of prompting your way back out of an unwanted change.
  • See Plans & Credits for how credits work and how to get more.
Your published app only changes when you publish, and it has its own data and secrets: preview data isn’t copied over, and environment secrets reach only the published app.
  • Make sure your most recent change completed, then publish again.
  • Check that any secrets your app needs are set in your project’s Environment settings, then publish again.
  • Remember that a newly published app starts with an empty database.
  • Open the deployed app and click through the broken flow, then describe the exact behavior to Fabricate so it can fix it before you publish again.
  • 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, go back to an earlier version and re-prompt with a clearer, narrower request.
Fabricate can read your app’s code and check the preview for errors, so a clear follow-up message is often all it takes to fix an issue.