Guided Build: Test, Fix, Polish

The Difference Between "It Works" and "It's Good"

After Sessions 1 and 2, you have a functional project. Congrats — that's a real accomplishment. But "it works on my computer when I use it carefully" is not the same as "it's good enough to share."

This session is about closing that gap. You'll systematically break your own project (on purpose), fix what you find, and polish the design until it looks intentional, not accidental.

This is your last building session before deployment. After this, your project should be ready for real users.

Phase 1: Break It On Purpose

The best way to find bugs is to use your project like someone who has never seen it before. Try everything that could go wrong.

Test 1: Empty Inputs

• Click "Add" without typing anything. Does it add a blank item? It shouldn't.
• Submit a form with missing fields. Does it give a helpful error or just break?
• Enter only spaces. Does your project treat that as valid input?

If any of these cause problems, use this prompt:

Test 2: Extreme Inputs

Test what happens when users enter weird stuff. Real users will, eventually.

• Enter a very long name (50+ characters — try mashing a sentence in there). Does the layout break?
• Enter special characters: quotes ("), apostrophes ('), emojis, ampersands (&), and angle brackets (< and >). Do any of these crash the page or display incorrectly?
• For number fields: enter negative numbers, zero, a really big number, or letters where a number should go. Does the project handle them gracefully?

If text overflows or the layout breaks:

Test 3: Mobile

The easiest way to test mobile: click Replit's Share or Webview button to get the live URL, and open it on your actual phone. Then check:

• Does everything fit without horizontal scrolling?
• Can you tap all the buttons with your finger easily, or do they feel too small / too close together?
• Does text wrap properly, or get cut off?
• If you have a sidebar or full navigation menu, does it collapse to fit, or does it overflow?

If your project doesn't work on mobile:

Test 4: Navigation and Flow

• Click every link and button. Does each one do what you expect?
• Can you get "lost" anywhere with no way to go back?
• If you have multiple pages, do all navigation links work?
• Does the back button in your browser work as expected?

Phase 2: Fix What You Found

You've got a list of bugs. Now fix them — but follow these rules:

1. Fix one bug at a time. Don't try to fix everything at once. Make one change, test it, confirm it works, then move to the next bug. Changing five things at once makes it impossible to know what fixed what (or what broke something else).

2. Start with the worst bug. Which bug makes your project unusable or confusing? Fix that first. A visual glitch can wait; a button that doesn't work can't.

3. Save after each fix. Keep a working backup. If a fix breaks something worse, you can go back to the last working version instead of starting over.

4. Use AI for the hard ones. If a bug takes more than 10 minutes of staring at code, describe it to AI using the bug report pattern from Lesson 5.2: what you expected, what actually happens, what you've tried, and the relevant code.

Phase 3: Polish

Your project works and the bugs are fixed. Now make it look like you meant it. Polish is the difference between a school assignment and something you'd actually show people.

Visual Consistency

• Is the same font used everywhere? (Pick one font for headings, one for body text, max.)
• Are colors consistent? Every button should be the same color. Every heading should be the same size.
• Is spacing even? Elements shouldn't be crammed together in one place and spread out in another.

Content Polish

• Are there any placeholder texts left? ("Lorem ipsum," "test," "asdfg," sample data you forgot to replace.)
• Do headings and labels clearly describe what they're for?
• Is there a clear title or header that tells visitors what this project is?

Professional Touches

• Add a favicon (the little icon in the browser tab). Ask AI: "Generate a simple favicon for a [project type] using an emoji or simple shape."
• Make sure the page title (what shows in the browser tab) is your project's real name, not "index.html."
• Add a small footer with your name or project name.

Use this all-in-one polish prompt:

KEY CONCEPTS

KEY CONCEPTS — LESSON 5.5

1. Test systematically: empty inputs, extreme inputs, mobile, and navigation. Don't just test the "happy path."

2. Fix one bug at a time, starting with the most severe. Save after each fix.

3. Use AI for bugs that stump you — but always describe the problem clearly first.

4. Polish means visual consistency (fonts, colors, spacing), cleaning up placeholder content, and adding professional touches.

5. "Good enough to share" = it works, it looks intentional, and a new user can figure it out without your help.