Orange: Reviewed Build Checklist#

A Reviewed Build affects real people outside your team. The brief ensures everyone agrees on scope, audience, and success criteria before you invest significant effort.

Save to a version-controlled repository (GitHub, GitLab) — not just a cloud folder. You need the ability to roll back changes.

Problems appear with real data. Test with names containing apostrophes, accents, and hyphens. Test with empty fields, very long text, and special characters.

1. Test with names: O'Brien, Müller, Smith-Jones, 日本語の名前 2. Test with empty forms, maximum-length inputs, and special characters 3. Test with numbers: zero, negative, very large, decimal 4. Test on different browsers (Chrome, Safari, Firefox) 5. Test on mobile devices

Walk through every "done" criterion in your project brief. Every single one must work.

With external users, exposed secrets are a direct path to data breaches.

1. Search your code for: sk-, api_key, secret, password, token, DATABASE_URL 2. Check your repository history — secrets removed from code may still be in git history 3. If you find any, move them to environment variables and rotate the exposed secrets (get new ones)

For a Reviewed Build, the kill switch should be fast (under 5 minutes) and documented. You may need to use it urgently.

A fresh pair of eyes catches problems you cannot see because you built it.

If someone needs to modify this tool, they need the original prompts.

External users see this as a Springpod product. It must match your brand.

Peer review catches obvious issues before the more thorough technical review.

When you handle personal data, you are responsible for protecting it. "I did not know" is not an acceptable excuse if data is exposed.

1. List every piece of personal data your tool collects 2. For each item: is it strictly necessary? If not, remove it 3. Check that your connection uses HTTPS (lock icon in browser) 4. Check that your database encrypts data at rest (most modern services do this by default — confirm it) 5. List every external service your tool sends data to. Check each against your Approved Tools 6. See the Security Standard for the full data handling requirements

This is one of the most common security failures in web applications. The tool "works" — it just shows the wrong person's data.

1. Create two test accounts 2. Log in as Account A and note the URL when viewing personal data 3. Log in as Account B and paste Account A's URL 4. If you can see Account A's data while logged in as Account B, stop and fix this immediately

Orange builds handle personal data or serve external users. A peer review catches usability issues. A technical review catches security and data handling issues that non-technical reviewers will miss.

1. Complete all items above first 2. Fill out the Review Request form 3. Include your Build Log and any Prompt Specs 4. List every external service the tool connects to 5. Note any checklist items you could not complete and explain why 6. Submit to your technical reviewer

Technical error messages tell attackers how your tool is built. They also confuse and alarm non-technical users.

1. Try actions that might fail: disconnect from the internet, submit invalid data, access a page that does not exist 2. Check what the user sees for each 3. If they see raw errors, stack traces, or database names, replace them with user-friendly messages 4. Test that error messages suggest what to do next ("try again" or "contact support")