Orange: Reviewed Build Guide#

You are building something that handles personal data or serves external users — a parent communication portal, a client-facing tool, or an internal system with sensitive information. This guide adds data protection, accessibility, and technical review on top of the Standard Build process.

Time estimate: Most Reviewed Builds take 3-7 days of building time. The framework part takes about 1-2 hours.

What you will need: Access to a Low-Code or Pro AI tool, Springpod's Branding Standard, a colleague for testing, and a technical reviewer (see Roles).

---

Steps 1-3: Standard Build Foundations#

Follow the Yellow (Standard Build) Guide for Steps 1-3. The process is the same:

1. Define what you are building — fill out the Project Brief
2. Pick your tool — for Orange builds, Low-Code or Pro Tools are recommended. No-Code tools usually lack the security controls you need.
3. Build it — use the Prompt Library as a starting point. Keep a Build Log.

One important difference: For Orange builds, your Project Brief should explicitly state what personal data you are collecting and why.

---

Step 4: Handle data correctly#

This is where Orange builds differ most from Yellow. You are handling personal data, and that comes with responsibilities.

4a: Minimize data collection#

For every piece of data your tool collects, ask: "Is this strictly necessary for the tool to work?"

If the answer is no, do not collect it. Data you do not have cannot be stolen.

Example:

4b: Encrypt data#

• In transit: Your tool must use HTTPS. Check for the lock icon in your browser's address bar.
• At rest: Your database must encrypt stored data. Most modern services (Supabase, Firebase, AWS RDS) do this by default. Confirm it is enabled.

4c: Check access controls#

Every user should only see their own 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. This is a critical security failure.

4d: List your third-party services#

Create a written list of every external service your tool sends data to.

Check each service against your Approved Tools list. If any service is not approved, stop and get approval before continuing.

See the Security Standard for the full data handling requirements.

---

Step 5: Make it accessible#

Your tool will be used by people with different abilities. Basic accessibility is required for all Orange builds.

What to check#

1. Keyboard navigation — Can you use the tool with only a keyboard (no mouse)? Tab through every interactive element. Can you reach every button and link?
2. Text contrast — Is all text readable? Use the free WAVE accessibility checker to test.
3. Alt text — Do all images have descriptive text for screen readers?
4. Mobile — Does the tool work on phones and tablets? Try completing the main task on a mobile device.

Quick automated check#

1. Open your tool in Chrome
2. Right-click → Inspect → Lighthouse tab
3. Check "Accessibility" and run the audit
4. Fix any errors flagged as "critical" or "serious"

This takes 10 minutes and catches the most common accessibility issues.

---

Step 6: Handle errors gracefully#

Users should never see raw error messages, stack traces, or database names.

What users should see:

• "Something went wrong. Please try again in a few minutes."
• "We could not find that page. Here is a link back to the main page."
• "Your session has expired. Please log in again."

What users should never see:

• "Error 500: Internal Server Error"
• "TypeError: Cannot read properties of undefined"
• "Connection refused: postgres://db-name:5432..."

How to check#

1. Try actions that might fail: disconnect from the internet, submit invalid data, access a URL that does not exist
2. For each, note what the user sees
3. Replace any technical error with a user-friendly message that suggests what to do next

---

Step 7: Match your brand#

Same as the Yellow guide, but more important for Orange builds because external users will see this tool.

Check against the Branding Standard:

---

Step 8: Test thoroughly#

Beyond the Yellow testing steps:

1. Realistic data — Test with real names, real edge cases, and real data volumes
2. Fresh eyes — Someone who was not involved in building has used it
3. Access control test — Verified that users cannot see each other's data
4. Error handling test — Triggered every possible error and checked the user experience
5. Accessibility test — Ran WAVE or Lighthouse and fixed critical issues
6. Performance — Tool loads in under 5 seconds on a normal connection

---

Step 9: Request technical review#

Orange builds require a technical review — someone with security or technical knowledge, not just a peer.

1. Complete all items above first
2. Fill out the Review Request form
3. Include:
   • Your Build Log
   • Any Prompt Specs for production prompts
   • Your third-party services list
   • Any checklist items you could not complete (and why)
4. Submit to your technical reviewer (see Roles)
5. Do not go live until the technical reviewer has approved it

If they request changes, make them and re-submit. This is normal — most first reviews come back with feedback.

---

Step 10: Ship it#

After technical review approval:

1. Deploy to production — use your approved hosting service
2. Document the kill switch — write down exactly how to take the tool offline, and share it with at least one other person
3. Announce the launch and provide user documentation or instructions
4. Monitor closely for the first week — check for errors, access issues, and user feedback

---

Done#

You just completed a Reviewed Build. The checklist version is the Orange Checklist.

If your tool evolves to handle protected data (student records, health information) or serves minors, re-run the Project Intake. You may need the Red (Protected Build) path.