A build failure means Caffeine was unable to generate working code for your app. Unlike a deployment failure — where the code was built but could not be published — a build failure stops earlier: the app was never successfully generated in the first place.
Build failures split into two types depending on which part of your app Caffeine was unable to generate: the backend or the frontend.
Backend build failures
The backend is the most common source of build failures. Caffeine writes your backend in Motoko, a language designed specifically for apps running on the Internet Computer. When the AI generates Motoko code that does not compile, Caffeine automatically attempts to fix the errors and retry — but if it cannot resolve the problem after two attempts, it stops and reports a build failure.
Common reasons this happens:
- The change you requested was more complex than the builder could complete in the available attempts
- You tried to change how data is structured — adding or modifying fields in a record type — which requires careful, incremental changes
- Your project has grown large enough that regenerating the entire backend in one build regularly hits limits
The most reliable path forward is to revert to the last version where your backend was working, then try again with a simpler or more focused prompt. Do not try to prompt your way through a broken backend — once the Motoko code is in a state that does not compile, each further attempt starts from that broken state and the AI is fighting uphill.
Use the Revert to version N button in your chat history to return to a clean baseline. Then:
- Break the change you wanted into smaller steps. If you tried to add several features at once, do them one at a time.
- Verify each build actually works before moving to the next change. If you build five versions before discovering version two broke something, you have lost credits for versions three, four, and five.
- For data structure changes specifically, introduce them incrementally: add a placeholder field, confirm it builds, then modify it — rather than restructuring multiple fields in one prompt.
Frontend build failures
Frontend failures are less common and more often temporary. The frontend is built in React and TypeScript, and occasionally the build service encounters an error.
The advice is the same: go back first, then forward. Revert to the last working version and re-prompt rather than trying to fix forward from a broken state.
The AI couldn't attempt the build
Sometimes Caffeine returns a message saying it was unable to implement your request. This is not a compile failure — the AI decided it could not safely attempt a build rather than risk producing broken code. It usually means the request was too broad or ambiguous, or the project has reached a level of complexity that makes the specific change difficult to execute reliably.
What to try:
- Rephrase the request more specifically. Instead of "improve the dashboard", try "add a total count of active users to the top of the dashboard".
- Break the request into smaller pieces and do them in separate messages.
- If you are working on a large, mature project and hitting this repeatedly, try sending "are we stuck?" — this can prompt the AI to reassess and attempt a simpler path forward.
The most important habit: build incrementally
Most painful build failures — and most credit losses — happen when errors go unnoticed across many versions. A common pattern is: something breaks at version 10, the user keeps building, and only discovers the issue at version 20. Reverting now means losing everything from versions 11 through 20.
Test your draft after every build. Before sending your next message, open the draft and check that the thing you just built actually works. This takes less than a minute and catches errors at the version where they were introduced — not ten builds later.
Keep each prompt focused on one thing. The more a single prompt changes, the more things that can break and the harder it is to identify the cause. Small prompts mean small failures and easy recovery.
Treat a revert as a normal tool, not a last resort. Reverting to a working version and re-prompting from there is almost always faster than trying to fix broken code through the AI chat.
Frequently asked questions
Why does Caffeine only try to fix the backend error twice?
If the AI generates Motoko code that does not compile and cannot fix it in two attempts, continuing to retry is unlikely to produce a different result. Stopping early preserves your credits and surfaces the problem so you can take a different approach — usually reverting to a working version and reprompting.
Do failed builds cost credits?
No. Credits are only charged when a build completes successfully — meaning the AI generated code and it compiled without errors. If the build fails at any point before that, including a Motoko compile error, no credit is charged. What does cost credits is triggering deployment — 4 credits are charged when you publish a draft to the live version, regardless of whether the deployment succeeds.
I reverted but the same error keeps happening. What now?
Try reverting further back — to a version before the problematic change was introduced. If the error appears even on a very early version, or on a brand new prompt, contact support with your project name and the error message.
My project is too complex to build reliably. What are my options?
As projects grow in size and complexity, the AI has more code to consider with each change and builds can become less reliable. This is a known constraint of AI-powered builders — not specific to Caffeine — and the threshold improves over time as models evolve. For projects that have reached this point, the recommended path is to export to GitHub and continue development using external tools or a developer. GitHub import is coming soon, so you will be able to bring the project back into Caffeine after making changes externally. For more detail, see What Caffeine Can and Cannot Build.