I built a system that reads my AI newsletters every morning and turns them into a searchable catalog of AI tools, plus a chat website where I can ask questions about the catalog in plain English. The system has two parts: a workflow that collects the information and a website that answers questions about it. I subscribe to several AI newsletters, and each issue mentions five or ten interesting tools. I would read about one and think, “I should remember that.” Months later, I would vaguely remember it but have no quick way to find it. I wanted a repository of these AI tools that I could search easily. The collector is a scheduled Claude Code Routine that runs once a day. It searches Gmail for newsletters from the last 24 hours and reads each email in full. It extracts every AI tool’s name, description, category, official link if present, and source newsletter. It skips non-AI items and pure ads but keeps sponsors that are genuine tools. Before adding anything, it checks for duplicates. New tools are added under the appropriate category in alphabetical order. If an existing tool has fresh details, its description and “last updated” date are refreshed. Tools mentioned by three or more sources receive a “Highly Mentioned” tag, which is a useful signal for what is catching on. The workflow also creates categories when new tools do not fit into an existing one. The workflow commits and pushes the catalog to a private GitHub repository, then posts a summary to Slack. The catalog is a single Markdown file—plain text, human-readable, and versioned in Git, with no database. The chat website displays the tool count, category count, and last-updated date, along with clickable example questions. If I ask, “Is there anything for voice AI?” it returns a written answer listing every match with descriptions and working links. The site is a React single-page app on Netlify with two small backend functions: one returns the statistics, and the other handles chat. When I ask a question, the backend fetches the Markdown file from the private repository, sends it to Claude along with my question, and returns the answer. To recreate it, you’ll need a GitHub account, Netlify (the free tier is fine), an Anthropic API key, and Claude Code. The routine prompt is the most important part. It names the exact newsletters, lists the fields to extract, and explicitly says: never invent a URL, never delete an entry, and only add or update. Vague instructions produce files that degrade over time. I learned a few things the hard way. Newsletters deleted before the workflow runs may cause it to report “nothing new,” so the logic should also check Trash or Deleted items. Tokens expire, and mine quietly expired, which caused the search site to stop working. Choose a long expiration period and record the date. Also, explicitly say “never invent a URL,” or the workflow may produce plausible links that go nowhere. It now runs every morning without me. When I need something, I ask a question and get an answer in seconds instead of trying to remember which newsletter, and which month, mentioned the tool I’m thinking of. Step-by-step: 1. I created a private GitHub repository with a starter Markdown file containing “Last updated” and “Total tools” fields, category headings, and consistent fields for each tool. 2. I wrote a Claude Code Routine prompt that names the newsletters, specifies the fields to extract, and instructs the workflow never to invent a URL, never to delete an entry, and only to add or update tools. 3. I scheduled the routine to run daily with Gmail access. 4. Each day, the routine searches Gmail for newsletters from the previous 24 hours, reads them, extracts AI tools, skips non-AI items and pure ads, preserves genuine tool sponsors, and checks Trash or Deleted items when necessary. 5. The routine checks for duplicates, adds new tools alphabetically under the right category, updates existing tools with fresh details, creates categories when needed, and applies the “Highly Mentioned” tag to tools found in at least three sources. 6. The routine commits and pushes the Markdown catalog to the private GitHub repository and posts a summary to Slack. 7. I built the frontend with Vite and React, including a statistics header, a scrollable message list, an input box, and example questions. 8. I added two backend functions: one for statistics and one for chat, with the GitHub fetch handled by a shared helper with a short cache. 9. I created a fine-grained, read-only GitHub token limited to the single repository. 10. I deployed the site to Netlify with the required keys stored as environment variables rather than in the code. 11. When I ask a question, the backend fetches the Markdown catalog, sends it to Claude with my question, and returns the matching tools, descriptions, and links.

My doctor asked me to track my blood pressure for a month because it was on the high side before prescribing any medication. I initially recorded each reading manually in an Excel sheet, but after a few days, I wanted a simpler way to enter and manage the data. I uploaded the sheet to Claude Code and asked it to build a blood pressure tracking app. After the app was built, I hosted it on Netlify, used Supabase as the backend to save data for both my wife and me, and added it to my iPhone Home Screen. Step-by-step: 1. I started tracking my blood pressure in an Excel sheet as my doctor requested. 2. After several days of entering the readings manually, I uploaded the sheet to Claude Code. 3. I asked Claude Code to build an app for tracking blood pressure. 4. I hosted the app on Netlify. 5. I used Supabase as the backend to save blood pressure data for both my wife and me. 6. I saved the app to my iPhone Home Screen for easier access.

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.

I'm not a professional developer, but I built Sujido, a live word puzzle, with multiple AI agents. For months, they gave me bloat, lost context, and slop, and neither I nor the models could untangle what had been decided or why. I eventually settled on two agents: one Claude instance that plans and reviews, and another that builds. I imposed rules on both, one failure at a time. None of these rules would surprise a professional engineering team, but nobody handed them to me. That's the key lesson I learned: agents won't bring the discipline for you. You have to impose it. When I showed the first game revision to strangers, their verdict was that the first half was "boring" and the second half was novel. It was hard news to hear about my baby, but I took the feedback to heart and cut the game in half. That required surgery on code tangled across both halves, followed by a rebuild under the rules below. Before the rebuild, a separate AI audit graded the codebase B−. Afterward, it graded it A−. The deployed site shrank by 97.5%, and every serious finding was fixed and locked in by an automated test. The models didn't change drastically, but my operating rules did. Step-by-step: 1. I wrote a constitution before the first prompt. The repo holds what every agent must read before working: `CLAUDE.md` files for the project as a whole and for each major part of the code, a collaboration protocol for how the agents and I work together, a spec for the core data format, and a decision log. The data format is changed there first and then in code. Nothing is remembered unless it is written down. That's my life as well. :) 2. I split the work by role, not by task. One Claude instance is the strategist: it writes briefs, reviews reports, and never commits code. Claude Code in VS Code is the builder: it executes the brief, writes the tests, reports back, and never releases. Neither agent can approve its own work. 3. I made every job start from a written brief, and I never edit briefs. Each brief is committed to the repo with an exact scope, such as "do X only, do not begin Y." If plans change, a dated amendment states what it supersedes. The builder may skip a risky item with a written reason; skipping is better than forcing it. 4. I used mock-ups with real data instead of descriptions. Anything I will look at gets a mock-up, and I approve it before any code is written. I learned this when a status report described only in words arrived on my phone formatted as a wall of text. The approved mock became the spec, and the tests pin the output to it. 5. I proved that every test could fail. No test is trusted until it has been run against deliberately broken code and caught the bug. A test suite that has never failed hasn't proven anything. 6. I verified reports against the real repo. Agent reports drift. One summary said players rated a puzzle "just right" when the log said "too easy." An audit said there were about 25 unused functions; a recount found 29. The strategist spot-checks load-bearing claims against the actual files and data before anything ships. 7. I built gates the agents can't talk their way past. All work lands on a branch that auto-deploys to a test site. GitHub Actions lints and runs the Python and headless-browser tests on every push. A git hook refuses direct pushes to production. Releases are fast-forward merges that only I perform, after CI is green and I've tested the build personally. The live site shows the release's commit ID, and I check it before calling it shipped. Nothing merges automatically. An agent's "looks good" is just another report, and reports drift. 8. I gave the system a memory. Every session ends by updating the decision log and a "resume here" document, so the next session—a fresh model with no recollection—picks up exactly where the last one stopped. Without this, every session starts by relitigating old decisions. 9. I let the data and end users overrule me. A scheduled GitHub Action turns player telemetry into a daily report. It showed that the difficulty dials I assumed mattered did not predict what players found hard; what mattered was how misleading the starting arrangement was. When testers were confused by the tutorial, I rebuilt it even though I had already approved it. Player feedback about their own experience outranks my earlier rulings. AI agents are velocity multipliers, but they multiply bad structure as quickly as good code. The rules came from me, not the models: the AI writes the code, while the rules, gates, and written record keep the process honest. See the result at Sujido.com. Finding the anagram is the easy part; sliding it into place is the hard part. One board took me 902 moves. My S.O. solved it in 242, and I haven't heard the end of it. Try to break it!

San Diego County is enormous, and its startup scene is growing rapidly. I wanted a better way to see where companies are located, especially because many of them host networking events and there was no central map or repository. I told Claude what I wanted: an alphabetical directory with an industry selector and a way for people to add their own companies. I also asked it to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. Claude helped me design the map, create the Google Form for submissions, set up the Google Sheets workflow for hosting and approving companies, and use Netlify to host the main file. It also guided me through linking the map to a page on my own website: https://sdaimap.michelabood.com/. Claude warned me about the legal issues involved in scraping a list wholesale from other sites, so the map is designed to be populated by people submitting their own companies. I just published it, and 10 companies have already been listed, with more on the way. I have also received great comments on LinkedIn. Now I can see at a glance how far I need to go to find a specific company. I also had Claude create a step-by-step guide, which I am happy to share if people want it. Step-by-step: 1. I described the map I wanted to Claude, including an alphabetical directory, an industry selector, and a way for people to add their own companies. 2. I asked Claude to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. 3. I used Claude to design the map and create the Google Form for company submissions. 4. I used Google Sheets to host and approve the submitted companies. 5. I followed Claude's guidance to host the main file on Netlify. 6. I linked the map to a page on my own website: https://sdaimap.michelabood.com/. 7. I avoided scraping a wholesale list from other sites because of the legal issues Claude identified. 8. I published the map and began collecting company listings from people directly.