Yellow: Standard Build Checklist#

A Standard Build is not a throwaway — it will be used by your team for real work. The brief ensures everyone agrees on what "done" means before you invest significant time.

If your laptop dies, can you get your work back? Save to a cloud tool (Replit, GitHub, Google Drive) — not just your desktop.

Problems appear with real data, not test data. A name like "O'Brien" or a 200-character address will break things that "John Smith" never will.

1. Try entering names with apostrophes, accents, and hyphens (O'Brien, Müller, Smith-Jones) 2. Try entering empty fields — does the tool handle them? 3. Try very long text (200+ characters) 4. Try special characters and emoji 5. If your tool handles numbers, try zero, negative numbers, and very large numbers

Open your project brief. Walk through each item under "What does done look like?" Does the tool do all of them?

Anyone who sees your code can use your accounts and access your data.

1. Search your code for: sk-, api_key, secret, password, token, DATABASE_URL 2. Search for any long random string that looks like a key 3. If you find any, move them to environment variables 4. Not sure how? See When to Escalate

You need a kill switch. Know how to take the tool offline before you need to.

You already know how your tool works. A fresh pair of eyes will find problems you cannot see because you built it. This is the single most effective quality check you can do.

1. Pick someone who was not involved in building the tool 2. Give them the URL and a task: "Find [X] and do [Y]" 3. Do not help them unless they are completely stuck 4. Note where they hesitate, click the wrong thing, or get confused 5. Fix those issues before shipping

If someone needs to modify your tool later, they need to know what instructions you gave the AI. Without the original prompts, the next person has to guess how the tool was built.

1. Open the Build Log template 2. For each major feature, paste the prompt you used 3. Note which tool you used (Replit, Cursor, etc.) and what changes you made to the AI output 4. Save the file alongside your project

Every tool your team uses represents your brand. Generic AI-generated styling signals "we did not care enough to make this ours."

1. Open your tool next to Springpod's website 2. Compare: buttons, headers, link colors, background, fonts 3. If they do not match, update the colors and fonts to match the Branding Standard 4. Check that error messages and empty states use your brand voice, not generic defaults

A peer review catches issues you missed. It does not need to be a formal process — a colleague spending 15 minutes with your tool is enough.

1. Fill out the Review Request form 2. Send it to a peer reviewer (see Roles) 3. Give them access to the tool 4. Address their feedback before going live