Build a Real Tool With AI Coding — Complete Project Day | Mastering Coding with AI Day 4 of 5

Everything in Days 1–3 was preparation for today. The mental model, the prompting stack, the debugging loop — all of it is infrastructure for this build session. Our own password strength checker is a good reference for what we’re building — today you create your own version with your own design and features. And when you’re done, Day 5 covers how to check it for security issues before you share it with anyone.

The Six-Stage Build Process

I’ve built enough tools with AI assistants to have a consistent process that works reliably. Six stages. Done in order. Each stage has a clear output that feeds the next one.

The six stages: Specify → Decompose → Scaffold → Test → Deploy → Document.

Most beginners skip stages 1 and 2 entirely and jump straight to prompting. That’s why they get messy, hard-to-debug code. The first two stages take ten to fifteen minutes and make every subsequent stage faster and more reliable.

Let me walk through all six with the project for today — a Password Security Awareness Tool — which will have three features: a strength checker, a common password detector, and a tips section. Exactly the kind of tool you’d send around to a team or post on a site.

Stages 1 and 2 — Spec and Decompose

Stage 1 — Write the specification. Full IPO model. All five prompt components. Before you open an AI window. This is the architect’s blueprint.

Stage 2 — Decompose into pieces. Even for a single-file tool, thinking about the pieces prevents confusion during building. My decomposition for this tool:

Piece 1: HTML structure — the layout, the headings, the input box, the output areas, the tips section
Piece 2: CSS — dark background, colour coding for the score labels, responsive layout
Piece 3: Strength checking JavaScript — the four-criteria check, the real-time update logic
Piece 4: Common password checking JavaScript — the list of 50 passwords, the lookup logic
Piece 5: Tips content — the five static tips

For a single HTML file, all five pieces go in the same file. But knowing they’re five pieces means if Piece 3 breaks, I know exactly what to ask AI to fix — I don’t have to debug the whole file. I can say “the strength checking isn’t updating in real time” and AI can target that specific piece.

Stage 3 — Scaffold the Complete Tool

Scaffolding is the first code generation pass. I use the full specification from Stage 1 as my initial prompt. I don’t generate pieces separately and try to combine them — that almost always creates integration issues. I generate the whole thing at once, getting AI to write all five pieces together so they work as a cohesive unit.

The Day 2 five-component prompt structure from the specification above is your scaffold prompt. Paste it into your AI and get the complete file back.

After you receive the code, before you run it, do the quick structural audit from Day 3:

→ Ask: “List every function in this code and describe what each one does.”
→ Ask: “Does this code make any network requests or access any external services?”
→ Ask: “How does this code handle empty input in the password field?”
→ If anything looks wrong: fix with an iterative prompt before running.

This pre-run audit takes three to five minutes and catches mistakes before you spend time testing broken code. I rarely skip it.

Stage 4 — Test and Iterate

With the scaffolded code in hand, run the behavioural testing checklist from Day 3. For the password tool specifically, my test cases:

Strength checker tests:
→ Empty field: should show nothing, not crash
→ “abc”: Weak (fails all four criteria)
→ “Password1”: Fair (has uppercase and number, but no special char and only 9 chars)
→ “MyStr0ng!PassPhrase”: Strong (meets all four)
→ Very long password (100 chars): should handle gracefully
→ Password with only special characters “!@#$%^&*”: which criteria does it trigger?

Common password tests:
→ “password”: should be flagged
→ “123456”: should be flagged
→ “qwerty”: should be flagged
→ “g$7Kp!mN3xQ2”: unlikely to be on the list, should clear
→ Empty field when clicking check: should not crash

Security test:
→ Type `<script>alert('xss')</script>` in the password field. Does a popup appear? If yes — critical fix needed before deploying.

For each test that fails, use the debug loop from Day 3: describe what you expected, what you got, and ask for the fix. The iterative formula: “The [passing feature] works correctly. The [failing test] should [expected behaviour] but instead [actual behaviour]. Fix it and give me the complete updated file.”

Stage 5 — Deploy: Three Options

A tool that only works on your computer isn’t really deployed — it’s just a local file. Deployment means giving it a URL that anyone can visit. Here are the three options I use most, ranked by ease:

Option 1 — Replit (easiest, recommended for this course).
Go to replit.com → Create Repl → choose HTML/CSS/JS → paste your code into the index.html file → click Run. Replit generates a public URL instantly. Free tier includes permanent hosting for static sites. This is the option I recommend for Day 4. The URL looks like: yourproject.yourname.repl.co — shareable, permanent, no credit card required.

Option 2 — GitHub Pages (slightly more setup, completely free, professional).
Create a free GitHub account → New repository → Upload your HTML file as index.html → Enable GitHub Pages in Settings → Get your URL. Free permanent hosting. URL looks like: yourname.github.io/yourproject. More professional for a portfolio, requires a GitHub account and a few extra clicks but no credit card and no ads.

Option 3 — Netlify Drop (no account required, instant).
Go to netlify.com/drop → drag and drop your HTML file → get a URL immediately. Free. No account required. URL is randomly generated (like amazing-curie-1234a.netlify.app). URL expires after a few hours unless you create a free account to make it permanent.

For today: use Replit. It’s the fastest path to a live URL and the easiest to revisit and update later if you want to keep improving the tool.

Stage 6 — Share and Document

Sharing is part of the build process, not an afterthought. Real tools get tested by real users who behave unexpectedly, use it on devices you didn’t test on, and find things that work differently than you intended. The feedback from a single real user is worth more than ten rounds of solo testing.

When you share, ask specific questions rather than “does it work?” Specific questions produce useful answers:

→ “Did the strength indicator update as you typed, or did you have to do something to trigger it?”
→ “Was it clear what you needed to do? Or was anything confusing about what the tool does?”
→ “Did it work on your phone or only on desktop?”

Document your tool with a brief description — what it does, what it doesn’t do, and any known limitations. Even a three-sentence README saves confusion when someone shares it further than you intended. Ask AI to write it: “Write a three-sentence description of this tool for someone who hasn’t seen it. Include what it does, what it doesn’t do (no network connection, browser-only), and who it’s designed for.”

Other Project Ideas — Same Process, Different Tools

Today’s tool is a password checker. The process works for anything. Here are six projects that follow identical stages and are achievable in one day using the skills from Days 1-3:

Security awareness quiz. Ten multiple-choice questions about password hygiene and phishing. Score at the end. All built-in to a single HTML file. Great for team training.

URL safety scanner (basic). Input: a URL. Process: check for known phishing patterns — too many hyphens, mismatched domain, IP address format, suspicious TLD. Output: colour-coded risk rating with explanation. Makes a great companion to our phishing URL scanner.

Data breach awareness tool. A static page that explains what data breaches are, shows famous examples, and gives personalised steps based on “which of these services do you use?” — all client-side, no API calls required.

Personal productivity tracker. Input: task name + estimated time. Process: store tasks in browser memory (not sent anywhere), show list with total time. Output: running list with a daily total. Simple, useful, zero data exposure.

Random password generator. Input: length + complexity options (uppercase, numbers, symbols). Process: generate cryptographically random password using browser’s built-in random function. Output: generated password + copy button + strength rating. Never stored, never sent.

CSV data viewer. Input: paste CSV data. Process: parse the data, display in a sortable table. Output: formatted table with column sorting. Completely client-side — the data never leaves the browser. Useful for anyone handling data without wanting to upload it to a third-party site.