Publish and grow
Launch checklist
The safety and quality checks Buildliy runs before your app goes live, which ones block publishing, and how to fix each one.
Before your app goes live, Buildliy checks it for problems that could hurt you or the people who use it, like private keys anyone could copy, or pages that show other people's data. It also points out smaller things worth polishing, like broken links or a missing page title.
Only serious problems stop you from publishing. Everything else is a suggestion, and you decide whether to fix it.
Where to find it
You see the same checks in two places:
- In the Publish dialog. Click Publish, and the Safety check before publishing card is at the top. It lists what needs attention, and most items have a Fix button. Click Show … passed checks to see what passed.
- On the Launch tab. Open the Workspace menu at the top right and choose Launch. You see every check, including the ones that passed, a short headline such as "Ready to publish — 2 things worth fixing", and a readiness score out of 100.
The checks run fresh each time you open them, and again when you click Publish, so the list you see is exactly what publishing enforces.
The readiness score is a guide, not a requirement. A low score never stops you from publishing. Only items marked Blocks publishing (or "Serious" in the Publish dialog) do.
What blocks publishing
These are critical problems. Publishing stays switched off until they're fixed.
| Check (as named on the Launch tab) | What it means |
|---|---|
| Last build failed | Your most recent build ended with an error, so there may be nothing working to publish. |
| Secrets in code | A private key, token or password is written into your app's code, where any visitor could copy it. This includes a server key placed in a NEXT_PUBLIC_ setting, which is sent to every browser. |
| App's private key in browser code | Your app's own Buildliy key (used for its built-in AI, payments, file storage and other services) can be read in the browser, so someone could use it on your credits. |
| Sign-in missing | Your plan says people sign in, but the app has no sign-in, so anything meant to be private is open to anyone with the link. |
| Some people's data isn't locked to them | In a new app, a table that holds each person's own data isn't locked by the database, so a page that forgets to check who's signed in could show everyone's data. |
| Your app shows data from your … | The app uses a connected account that holds your private records, such as accounting books, staff records, meeting transcripts or a custom connector you marked Only me — it's personal, and the app has no sign-in. |
| No homepage | The app has no main page for visitors to land on. |
The deep safety check (below) can also add serious items, such as Someone could change a price before paying, or a page or data link where anyone can see other people's details.
How people's data is protected on a new app
In a new app on Buildliy hosting, the database itself keeps each person's own data apart: the app connects with a restricted login, and the database only shows each person their own rows, even if a page forgets to check who's signed in. The checklist shows this as a passed check, Each person's data is locked by the database. If a table that holds people's own data isn't locked, Some people's data isn't locked to them blocks publishing until it's fixed.
In apps made earlier, each person's data is kept apart only by the app's code: each page checks who is signed in and only loads that person's rows. The checklist lists Each person's data is kept apart by your app's code as worth fixing, so you know it relies on every page doing that check. It doesn't block publishing. In both cases, the deep safety check also looks for pages and data links that hand people's details to the wrong person, and those can block publishing.
Some older apps, made on Buildliy's earlier database setup, get three data-access checks on their tables instead: Unprotected tables, Row-level security not tested and Data access check failed. These block publishing until the tables are protected and the check passes. Run the check from Manage → Database.
What's worth fixing
These never block publishing, but fixing them makes your app better and safer.
- API key needed: your app reads a key that has no saved value, so that feature won't work once published.
- Payments missing: your plan says you take payments, but no checkout was built.
- Payments are in test mode: checkout only accepts test cards until you connect Stripe. This is expected before you publish, because Stripe checks your live site before it turns on real payments.
- Add a … page: for apps that take payments, a reminder to add a privacy policy, terms and a refund policy. Buyers look for them, and Stripe checks for them before it turns on real payments.
- Broken internal links: links that lead to a page that doesn't exist.
- Images missing alt text: pictures with no description for screen readers and search engines.
- Form inputs missing labels: form fields that screen readers can't name.
- Missing page title + description, or Site title is still a placeholder: what search results and shared links will show.
- No error fallback: no friendly page if something breaks.
- Mobile viewport is a fixed width: phones would show a zoomed-out page.
- Each person's data is kept apart by your app's code: shown for apps made earlier. It works, but relies on every page checking who is signed in.
- Check what your app shows from your …: your app uses a service that holds your customers' details, like a CRM, a newsletter list, a support inbox or form responses, and it has no sign-in. Forms that only send data in are fine. Put any page that shows what's stored there behind sign-in.
- Check who can sign in — your app shows your …: your app shows private data from a connected account behind sign-in. Make sure only you, or people you choose, can sign up and sign in.
- Plan skipped or Plan not ready: the AI had less context about who the app is for.
The deep safety check
Alongside the checks above, Buildliy takes a closer look at how your app could be misused. While it runs, the card says "Checking your app, including a look from the outside like a stranger would…"
It looks for:
- People's data reaching the wrong people. Pages or data links that show names, email addresses, phone numbers or saved records to visitors who aren't signed in, or to every signed-in account instead of just the owner.
- Prices visitors can change. A checkout that takes the price from the visitor's browser instead of looking it up on the server.
- AI features anyone can overuse. An AI feature with no sign-in and no limit per visitor, which could run up your costs. This one is a suggestion, not a blocker.
- A look from the outside. When your preview is running, Buildliy opens your app's data links without signing in, the way a stranger would. If one hands out people's details, that's a serious problem. If nothing leaks, you see Checked from the outside in the passed list.
When a check is sure about a data problem, it's serious. When it's less certain, it's listed as worth fixing so you can take a look.
Fix problems with one click
In the Publish dialog, each item has a plain-English title and one line about why it matters. Click Details to see the technical part, such as file names.
- Fix sends that one item to the AI as a request. It's a normal build and uses credits like any other.
- Fix it and publish (or Fix both and publish, or Fix all 3 and publish) sends every serious item to the AI in one request. When the build finishes, Buildliy runs the safety check again and publishes if nothing serious is left. A note above the chat box says "I'll publish once the fixes are in and the safety check passes," with a Cancel button.
- If something still needs fixing after that build, you see "Still 1 thing to fix before publishing" and can fix it again. Nothing is published.
- When only suggestions are left, the card shows "These fixes are optional — you can publish now" and a Publish button.
The automatic publish after "Fix it and publish" is forgotten if you reload the page, so it never publishes later out of the blue. If that happens, just open Publish again when the build is done.
Some items link somewhere instead of offering a fix. For example, Payments are in test mode has a Connect Stripe link.
How to fix common items
Private keys in your code
Keys belong in Manage → Secrets, never in the code. Ask:
Move every API key out of the code. Read them from server-only settings instead, and tell me which ones I need to add in Manage → Secrets.
Then add each key in Manage → Secrets. See Secrets and API keys.
A key your app needs isn't saved
Add the missing key in Manage → Secrets, or connect the service on the Connectors page and check it's switched on for this app in Manage → Connectors. See Connectors.
Sign-in missing, or private data shown without sign-in
Add sign-in to my app. Put every page that shows my private data or people's saved information behind it, so only signed-in people can see their own data.
If the app doesn't need accounts any more, change that in your plan instead. See User sign-in.
People's data isn't protected
Use the item's Fix button. It asks the AI to require sign-in on that page or data link and to only return the signed-in person's own data.
A price could be changed
Use Fix, or ask: "Look up every price on the server from the product, and never trust a price sent from the browser." See Take payments.
Placeholder title or missing description
Ask the AI to give your app a real title and description. You can also set them on the Site Info tab of the Publish dialog: they're added to your live site when you publish, but this check reads your app's code, so it keeps showing until the AI adds them to the app itself. If your title is still a placeholder like "Buildliy app", publishing uses your project's name instead (unless the project still has its automatic name), but your own wording is better. See SEO and sharing.
Broken links, missing descriptions and labels
Fix the broken internal links, add descriptive alt text to every meaningful image, and give every form field a visible label.
Notes from the AI
Under the checks, the Launch tab may show Notes from the AI, marked Not verified. These are things the AI suggested looking at while it built your app. Buildliy hasn't checked them, and they can never stop you from publishing.
Once your app is live, the Launch tab also shows a line like "Live site: working · checked 5 minutes ago". See Hosting.
Related
Still stuck? Read the FAQ or contact us.
