Build your app
How builds are checked
What Buildliy does after the AI writes your code — compiling it, opening your pages, fixing what it finds — and what you see when something still needs you.
The AI doesn't just write code and stop. Builds are checked before they're handed to you: your app is compiled, its pages are opened to make sure they actually load, and problems are repaired automatically inside the same build. You don't need to ask for any of this, and you don't need to understand the code.
This page explains what is checked, what you see in the chat, and what to do when something is still broken.
What happens after the AI writes code
Every change is compiled
Each time the AI saves a file, your app is compiled in its preview. If the code doesn't compile, the AI sees the exact error straight away and fixes it before moving on. If the new code needs a package your app doesn't have yet, it's installed automatically.
Your app is opened in a real browser
Before the AI says it's done, Buildliy opens your home page and up to three pages that were created or changed, in a real browser. (If a build is already running long, this step can be skipped; the page check after saving still runs.) It looks for errors on the page, blank pages, images that don't load, links to pages that don't exist, and pages that are too wide on a phone. It also checks the code for errors and looks for leftover placeholder content, such as "lorem ipsum" text, "Coming soon" stubs, or buttons that don't do anything.
The design gets a second look
On your first build, and when you ask for a redesign or a polish, the AI also looks at screenshots of your app on a desktop and a phone and fixes clear design problems, like text you can't read or a broken layout.
Problems are fixed before you see them
Anything that needs fixing goes back to the AI, which repairs it and then finishes. This happens up to twice on a first build and once on later changes.
Your pages are loaded again after saving
Once the build is saved, Buildliy loads your home page, the pages that changed, and a couple of others. If a page crashes when it loads, the AI gets the exact error, makes a focused repair, and the page is loaded again. It gets a few tries, all within the same build.
Checks and repairs are part of the build. There's no new chat message and nothing to approve, but the AI work they take uses credits like the rest of the build. See Credits and usage.
If a file keeps failing to compile
Sometimes a change is hard to get right. If the same file still fails to compile after three attempts in a row, Buildliy stops trying and puts back your last working version. The chat says so, for example:
I tried 3 ways to fix that file but couldn't quite get it right. I'm restoring your last working version now — give me a moment, then try a slightly different prompt.
Nothing you built before is lost. Try again with a more specific request, or ask for the change in smaller steps. If there's no earlier version to go back to (for example, on your very first build), the build finishes as it is and the preview offers a Fix it button instead.
What automatic checks can't cover
The checks open pages the way a visitor would arrive at them. A few kinds of pages can't be opened this way, so check them yourself in the preview:
- Pages that show one specific item, like a single order or a single profile.
- Things that happen without a page, like an email being sent.
- Whether the app does what you meant. The checks catch things that are broken, not things that work differently from what you had in mind.
What you see in the chat
While the checks run, the status line under the build says Checking your app. You may see lines such as "Opening your app in a real browser to double-check it before I hand it over." and Fixing a small issue while the AI repairs something. When the browser check passes, the chat says "Checked it in a real browser — everything loads cleanly."
After a bigger build, the AI's reply may also say which pages it opened, for example "I opened the home and booking pages to check — both load." If a page crashed and the AI fixed it, the reply says that too.
The checklist
During a build, the chat can show a checklist of the parts being built. A part only gets a tick when a check has loaded the page it lives on and found no problem. "Built" alone is the AI's own word, so it never shows a tick. If a part has a problem, the checklist's summary line shows Needs a look and that part's name.
Checked before handing over
After a build, Buildliy keeps a short record of what its checks found, called Checked before handing over. How it appears depends on the result:
| Result | What you see |
|---|---|
| Everything passed | Nothing extra. The build simply finishes. |
| Notes that need nothing from you, such as "Design review: 2 things could look better" or "Couldn't open 1 page to check it" | A Checked before handing over row in the More actions (⋯) menu of the newest build's reply, showing something like "3 passed · 1 note". Choose it to open the full list. |
| Something you should act on, such as "A page still shows an error" or "Some placeholder text may still be there" | The Checked before handing over card appears under the reply automatically, with the lines that need a look. |
The list only ever describes checks that really ran. If a check was skipped, it isn't mentioned.
The reply's More actions (⋯) menu can also show What you asked for, which lists each part of your request as done, partly done or not done. See Chat with Buildliy.
When something is still broken
If a page still doesn't load after the automatic repairs, Buildliy tells you instead of calling the build a success. The AI's reply says that one page hit an error, that your code is saved, and that the preview shows what rendered. Reply "fix it" and the AI takes another pass, or tell it what to change.
In the preview you'll see This preview hit an error with a Fix it button. Clicking Fix it starts a repair build: the AI gets the error and makes the smallest change that gets the page loading again. It's a normal build, so it uses credits. While it runs, the preview shows Updating your preview… and refreshes on its own when it's ready.
You can also describe the problem yourself. That often works better when you know what you were doing when it broke:
The /bookings page shows an error after I added the calendar. Please find what's causing it and fix it with the smallest change. Don't change the design.
If you'd rather go back, you can restore an earlier version at any time. Restoring is free, apart from the small amount of credit your live preview uses while it's running. See Version history, and Fix problems for more symptoms and what to do.
After you publish: live-site health checks
Checks don't stop when you go live. Once your app is published, Buildliy checks your live site every hour. It loads your home page and up to two other pages from your app (it skips pages like sign-in, account and admin pages, which visitors can't open without logging in).
A single failed check never sets off an alert, because sites can have a brief hiccup. If two checks in a row fail:
- You get an email titled Your live site has a problem.
- Your project's chat shows a Your live site has a problem card, with what's wrong in plain English (for example, "The booking page stopped loading.") and when it was first noticed.
The card has three buttons:
| Button | What it does |
|---|---|
| See details | Shows the address, the page that failed, the pages checked, and when the last check ran. |
| Fix it | Starts a build that tells the AI what broke on your live site and asks it to fix it with the smallest change. It uses credits like any build. When it's done, publish again so visitors get the fix. |
| Hide | Hides the card. |
When your site works again, the chat shows Your live site is back up, and if you were emailed about the problem, you get a "back up" email too.
You can see the latest result at any time under Workspace → Launch, as a line such as Live site: working · checked 12 minutes ago.
If your site was paused (for example, because your account ran out of credits), the card says so and doesn't offer Fix it, because a new build can't switch a paused site back on. See Hosting.
Related
Still stuck? Read the FAQ or contact us.
