You prompted Bolt until the preview worked, and now you want to ship it.
Unlock the rest of the checks
Two checks in each section are open, including why they matter, how to check them, and the prompt. Every other check keeps its title on the page. The reason, the steps and the prompt for those checks are omitted until you pay. One payment of £10 opens every stack. Access does not expire.
Or pay £15 once for the same access and the AI-Ready Pack. That price is the checklist price plus the pack price. The pack does not change your ranking.
Card details go to Stripe, not to this form. After payment, this browser gets a cookie. Restore access sends a one-hour link if you need another device. Error fixes stay free.
0 of 22 done
Ticks are saved in this browser only.
Security
Critical
Bolt writes files quickly, and keys sometimes land in source. Anything in the repository or in a VITE_ variable is visible to people who load the site. Secrets belong in the host's environment settings.
You are working in this repository. Do not add features.
Goal: no secret key remains in source, and no secret is exposed through a client environment variable.
Steps:
1. Search for API keys, private keys, database URLs with passwords, and Stripe secrets.
2. Move each secret to an environment variable that is only read on the server. Remove VITE_ or similar public prefixes from those names.
3. If a key was committed, tell me to rotate it. Do not print the key value.
4. Add a short comment in the README listing the variable names, not the values.
5. Summarise the files you changed.
Critical
Bolt may add Supabase, Firebase, or a hosted SQL database and leave the default rules open so the preview works. Open rules mean the first person who finds the project URL can read the data.
You are working in this repository. Do not add features.
Goal: the database must refuse access unless the signed-in user owns the row.
Steps:
1. Find the database client and the rules or SQL policies.
2. If rules allow public read and write, replace them. For Supabase, enable row level security and add policies on auth.uid(). For Firebase, require request.auth and match the user id.
3. Do not leave a temporary allow-all rule in the files you commit.
4. Tell me how to test as a signed-out visitor.
5. Do not print connection strings.
High
The reason, the checks and the prompt for this item are paid.
A generated checkout often sends the price from the page. Anyone can edit that request and pay less, or nothing. The server should look up a Stripe price id that you created.
You are working in this repository. Do not add features.
Goal: Checkout Sessions are created on the server with a Stripe price id, not with an amount chosen in the browser.
Steps:
1. Find where the Checkout Session is created.
2. Move that call to server code if it runs in the browser.
3. Use a price id from the environment or from your own database. Ignore any amount field on the incoming request.
4. Keep the Stripe secret on the server only.
5. Do not print keys. Tell me the env var names to set in test mode.
Deploy
High
The preview is how Bolt shows work in progress. It can sleep, reset, or sit on a host you do not control. Shipping means a deployment you can roll back, with environment variables set for production.
You are working in this repository. Do not add features.
Goal: the app should build and run as a normal project on a host, without needing the Bolt preview process.
Steps:
1. Identify the framework and the start or build command.
2. Remove assumptions that only work inside the Bolt preview, such as hard-coded preview hosts.
3. Read configuration from environment variables and list the names in the README.
4. Add a short deploy note: build command, start command, and the output directory.
5. Do not create accounts or deploy it yourself.
SEO and AI visibility
The AI-Ready Pack is a paid download of llms.txt templates, robots rules, schema and a short guide. Publishing those files does not, by itself, change your ranking.
Medium
The first time someone pastes your link, the title is the advert. Generated apps often still say Bolt or the template name. Set the title, description and a share image before you post it.
You are working in this repository. Do not add features.
Goal: set a unique document title, meta description and Open Graph tags for each public page.
Steps:
1. Find the HTML head or the framework metadata export.
2. Replace placeholder titles. Write a factual description of what the page does.
3. Do not invent star ratings, user counts or press quotes.
4. Point og:image at a real image in the project, or skip the image rather than linking a file that 404s.
5. Show me the tags you added.
A SoftwareApplication block in JSON-LD gives search engines the product name, URL and description in a structured form. It does not replace a clear page. The type is published by schema.org.
You are working in this repository. Do not add features.
Goal: The public homepage includes valid SoftwareApplication JSON-LD.
Work in the Bolt project, in index.html or the public folder Vite serves.
Steps:
1. Add one application/ld+json script with @context https://schema.org and @type SoftwareApplication.
2. Set name, url and description from the real product. Do not add aggregateRating, review, or offers unless I have given you those facts.
3. Keep the JSON valid.
4. Do not invent traffic numbers, reviews, or testimonials.
5. Show me the files you changed.
Bolt will not know your company address or what you intend to do with the data. If you collect accounts or emails, you need a page that says so, with a way for someone to contact you.
You are working in this repository. Do not add features.
Goal: add /privacy and link it from the footer. The text must describe only the data this app collects.
Steps:
1. Read the forms and database writes and list the personal data.
2. Write a short page: what you collect, why, how to ask for deletion, and the placeholder [CONTACT EMAIL].
3. Do not invent a company name, address, or registration number.
4. Add the footer link on every public page.
5. Tell me the placeholders I have to replace.
Monitoring
Medium
The Bolt conversation is not a production log. After you deploy, failures happen when you are not in the chat. Turn on the host's logs and look at them after the first real users arrive.
You are working in this repository. Do not add features.
Goal: failures should be logged as structured JSON on the server, without secrets.
Steps:
1. Add an error handler for API routes and server actions that logs the path, status and a short message with console.error.
2. Never log cookies, Authorization headers, or request bodies that might contain passwords.
3. Return a generic message to the browser.
4. Tell me which dashboard I should open to read those logs after deploy.