Verified against Bolt.new · 2026-08-01
Prepare a Bolt.new prototype for GitHub export and developer handoff
A Bolt.new cleanup pass that hunts down hardcoded secrets, lists every piece of mock data standing in for a real integration, and writes the README a new developer actually needs before inheriting the repo.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Northgrove Coffee storefront is a working prototype I built in Bolt.new, and I'm about to export it to GitHub for a two-person contract dev team who will take this to production to take over. Prepare the codebase for that handoff — this pass is about making it legible and safe to inherit, not adding any new feature. WHAT THIS APP CURRENTLY IS A Bolt.new-built React + Tailwind storefront with a working cart and a mock Stripe checkout — no real backend, no tests, built over a single afternoon session AUDIT AND CLEAN UP Go through the codebase and find every place a real secret, API key, or credential is hardcoded directly in a file rather than read from an environment variable — list each one by file and line, move it into an environment variable, and generate a .env.example file listing every variable name the app needs with a placeholder value and a one-line comment on what it's for, but never the real value itself. Find every place mock or placeholder data stands in for something that needs a real integration before this app is production-ready — a fake "Payment succeeded" screen with no real Stripe call behind it, a hardcoded array standing in for a database — and list each one explicitly in a section titled "Not yet real," rather than leaving a two-person contract dev team who will take this to production to discover it by reading every file. Check package.json for dependencies that were added during exploration but are no longer imported anywhere in the actual codebase, and list them as candidates to remove — do not remove them yourself without confirmation, since a dependency you believe is unused might still be needed by a build step you didn't check. DOCUMENTATION TO WRITE A README.md covering: what this app does in two or three sentences, how to run it locally (the exact commands, in order), every environment variable it needs and where to get a real value for each one, and the "Not yet real" list from above so it's the first thing a new developer sees, not something buried in a code comment three files deep. No automated tests exist yet, and the coupon logic was never checked against a $0 subtotal edge case REPOSITORY HYGIENE Confirm a .gitignore exists and actually excludes node_modules, any .env file, and any build output directory — if it's missing or incomplete, write one. Confirm no real secret value is already sitting in the git history from an earlier commit in this Bolt.new session; if one is, say so explicitly rather than just fixing it going forward, since a secret that's already been committed needs to be rotated, not just removed from the current file. private repo, will be shared via GitHub with the contractors as outside collaborators OUTPUT 1. The moved-secrets list, with before/after for each. 2. The .env.example file. 3. The README.md. 4. The "Not yet real" list, standalone, so it can be pasted directly into a handoff message or ticket. 5. The unused-dependency candidates list, explicitly not yet removed.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Bolt.new sessions are exploratory by nature, and pasting a real API key or a Supabase service key inline into a file to get something working fast during a chat-driven build session is a common habit, precisely because the WebContainer environment makes it trivially easy to just paste a value and keep moving. That means a prototype's actual codebase is disproportionately likely to have a hardcoded secret sitting in a file that was never meant to survive past that one build session — an explicit line-by-line secret audit is a direct countermeasure to a real, tool-specific habit, not a generic security reminder tacked on for form's sake. Requiring the "not yet real" list to be generated from the code rather than from memory closes a specific handoff failure. Whoever built the prototype in a single afternoon chat session knows informally which parts are fake, but that knowledge lives in their head and in the chat history, not in the repository itself. A developer who inherits just the code, with no access to the original Bolt.new conversation, has no way to tell a real Stripe integration from a mock success screen without reading every line of the checkout flow — a generated, explicit list is what actually transfers that knowledge into the one place the next person will actually look: the repo itself. The instruction to flag an already-committed secret rather than silently fix it going forward matters because of how git history actually works. Removing a secret from the current version of a file does nothing to remove it from an earlier commit still sitting in the repository's full history, which remains fully readable by anyone with clone access regardless of what the latest commit looks like. A cleanup pass that only edits the current file state, without calling out this distinction explicitly, gives a false sense that the secret has been dealt with when it still needs to be rotated at the actual source — the API provider's dashboard — not just deleted from the current HEAD.
Verified against
Bolt.new Bolt.new web app (StackBlitz WebContainers, GitHub export) · 2026-08-01
Changelog
- 2026-08-01 — Initial publish, verified against a Bolt.new GitHub export with an explicit secret audit and a generated "not yet real" list.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
