Workflow Hub

I teach AI in Business at Western Washington University, and I built a free, case-based AI textbook with Claude and GitHub Pages: https://prof-califf.github.io/ai-in-business/ The 11-chapter digital textbook includes seven real company cases—EveryCure, Netflix, Spotify, Uber, Waymo, Airbnb, and Epic—plus chapters on AI’s environmental cost, ethics, regulation, and the future of work. Seven chapters include hands-on Python labs, and Chapter 8 has an interactive calculator that models the energy and water footprint of a reader’s own AI usage. The textbook is free, has no publisher, and costs $0 to host. The problem was that AI textbooks are stale before they ship. An 18-month publishing cycle means students can pay $200 for a book that is already two model generations behind. Textbooks also tend to teach theory first and postpone business relevance until much later. My students do not need to derive backpropagation. They need to understand why Spotify built a recommender, how it works, what broke, and what it cost—then build one themselves. My stack is Claude, GitHub Pages, VS Code, Google Colab for the labs, and n8n for the Chapter 7 agentic lab. The project started when I was assembling a reading list and could not find anything usable—only outdated textbooks and paywalled cases. I already had years of lecture notes scattered across documents. Step-by-step: 1. I locked in a framework first. I use the AI Factory model—Data → Model → Prediction → Decision → Value → loop—and run every company through it. This is the step people skip: it builds transferable skills for students and gives Claude a stable structural contract across every chapter. 2. I set up the repository before writing. I created a new repo, added `index.html`, opened Settings → Pages, and confirmed that the site deployed. Five minutes up front was better than debugging after 40,000 words. 3. I built one chapter completely and used it as the template. Each chapter is a single, self-contained HTML file with no build step or dependencies. Then I prompted Claude: "Here's my finished Chapter 1 as the format reference. Here are my notes on Uber. Draft Chapter 4 in the same structure and voice." A finished exemplar worked better than an abstract description. 4. I started from my existing material instead of using a blank prompt. Claude structured and clarified my notes, but it did not decide what I think. I rewrote anything that did not sound like me. That distinction preserved the resource’s voice and avoided generated filler. 5. I made the labs builds rather than exercises. Students reconstruct each system in Google Colab using Claude as a coding partner, then publish their work to their own GitHub repositories. They finish with artifacts. 6. I shipped an incomplete version and update it like software. I published with fewer chapters, then edit and push updates when regulation changes so students automatically get the current version.

QuickBooks stores customer data across multiple windows, including notes, deposits, invoices, payments, aging, and email. To see everything, we previously had to keep several windows open while constantly searching, opening, and closing screens. Communicating with customers beyond QuickBooks’ standard letters was also difficult and time-consuming. I used Claude to write a program that brings this information together in one view. It creates an aging summary of all past-due accounts, with sortable columns for customer name, aging category, and total. I also added columns for the last payment and payment date. Clicking anywhere on a customer’s row opens a full drill-down of that customer’s data on one page. The accounting person can view invoices filtered by date or open invoices, see payments and the invoices they were applied to, review aging detail, run reports without leaving the screen, send emails, record collection notes, and print invoices. The software supports simultaneous access for multiple authorized users. The data stays up to date and can be refreshed at any time. This saves us hours of time compared with working through QBO. My next step is to have Claude automate reminder notices at 30 and 60 days, based on user-selected settings, as well as 90-day collection letters. These notices will be customizable while still allowing automation. Step-by-step: 1. I identified the customer information that was spread across QuickBooks windows, including notes, deposits, invoices, payments, aging, and email. 2. I used Claude to write a program that creates an aging summary of all past-due accounts. 3. I added sortable columns for customer name, aging category, total, last payment, and payment date. 4. I enabled users to click a customer row and open a full drill-down of that customer’s data on one page. 5. I included access to date-selectable invoices, open invoices, payments and their applied invoices, aging detail, reports, emails, collection notes, and invoice printing. 6. I set up the software so multiple authorized users can access the data simultaneously and refresh it whenever needed. 7. I plan to add customizable, automated reminder notices at 30 and 60 days and collection letters at 90 days.

AI agents such as Claude Code, Codex, and Gemini can install skills, plugins, and CLI tools in seconds. That is convenient, but each add-on runs with access to files, passwords, and accounts. A malicious add-on could steal API keys, read private data, or quietly take control of the agent. I use `agent-guard` to make “check first, install after” the default. Before installation, it examines AI agent skills, MCP servers, and CLI tools for malware, prompt injection, and credential theft using professional, open-source security scanners from NVIDIA, Cisco, Datadog, and the Open Source Security Foundation. The tool returns a clear verdict: safe to install or blocked, with the exact reason. It then installs only the verified version, preventing a different version from being swapped in between. A single check can also cover multiple AI agents, installing the approved add-on into every agent on the machine. Free and open source: https://github.com/elliottwaves-20/agent-guard Step-by-step: 1. I select the AI agent skill, MCP server, or CLI tool I want to install. 2. I run `agent-guard` to scan it for malware, prompt injection, and credential theft. 3. I review the verdict and the reason if the add-on is blocked. 4. I install the exact version that was checked rather than an unverified replacement. 5. If I use several AI agents, I install the approved add-on into all of them at once.

My company takes cybersecurity seriously, and part of our new-hire onboarding process is a tour of the IT department to meet the team. Our walls have several screens displaying metrics and information from our security tools, firewalls, and other systems. It looks like a scene from a movie. By far, the most popular display is our custom-made Cyber Threat Map, which shows real-time attempts to infiltrate our network, malicious emails, and other security threats we're blocking. The map drives home the reality of what we're facing 24/7 while protecting our employees, vendors, and customers. I built it using Claude Code. It polls a range of devices and systems through APIs, aggregates the data on one screen, and displays attack vectors, location information, and other details from the last 30 days. Step-by-step: 1. I identified the security tools, firewalls, devices, and systems that provide relevant threat data. 2. I used Claude Code to build a custom Cyber Threat Map. 3. I connected the map to the devices and systems through their APIs. 4. I aggregated the data on a single screen, including attack vectors, location information, and other details from the last 30 days. 5. I displayed the map during IT department tours so new hires could see the real-time threats our company is blocking.

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.

Claude created my portfolio website in an instant. I prompted it with my links (LinkedIn and social), described what I wanted, and it built the entire thing in one sitting — design, deployment, DNS config, SEO, and Google indexing included. I made a handful of edits across the session, and it handled every single one without friction. When things broke during deployment, it debugged in real time and fixed them via desktop extension browser control. Zero code written by me. Step-by-step: 1. I gave Claude my LinkedIn and social links along with a description of the portfolio site I wanted. 2. I asked it to build the site’s design and content in one working session. 3. I reviewed the result and made a small number of edits through conversation rather than editing code. 4. I had Claude handle deployment, DNS configuration, SEO, and Google indexing. 5. When deployment broke, I used browser control to let Claude inspect the live problem and debug it in real time.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

For a recent video, I needed to animate a visual representation of this ancient board game. Doing that manually in After Effects would've taken a few hours, so instead I described the rules of the game to Claude and asked it to generate an interactive SVG animation. After a few rounds of tweaking, I was able to screen-record the result, and it worked great for the video. Step-by-step: 1. I described the ancient board game’s rules and the visual sequence the audience needed to understand. 2. I asked Claude to generate an interactive SVG animation that demonstrated the game. 3. I reviewed the first version and gave feedback on the motion and clarity. 4. I repeated the prompt-and-tweak loop until the sequence worked for the video. 5. I screen-recorded the finished SVG animation and used the recording in the edit.

I used to create a skeptical VC investor persona through prompting whenever I ran ideas and actual business plans through AI. Recently, after working on a business plan for weeks, I used Claude Cowork with Opus 5/High to evaluate the same concept. Instead of prompting for critique and redesign each time, I built a Skill upfront. The concept is the same, but the Skill makes the execution much more effective. It reviews ideas or detailed business plans, researches first, and critiques only after that. It also analyzes and suggests wedges and new moats and, when instructed, generates detailed business plans. It works well as a one-shot analysis, but it is most effective when I push back and challenge it further. I’m sharing the Claude Skill for free under the MIT license: https://github.com/zszendro/vc-teardown Step-by-step: 1. I used to prompt AI to role-play a skeptical VC investor when reviewing ideas and business plans. 2. After working on a business plan for several weeks, I ran the same concept through Claude Cowork with Opus 5/High. 3. Instead of prompting separately for critique and redesign, I built a Skill upfront. 4. I designed the Skill to research first and critique only afterward. 5. I used it to review ideas or detailed business plans, analyze and suggest wedges and new moats, and generate detailed business plans when instructed. 6. I continued the analysis by pushing back and challenging the Skill beyond its initial one-shot response. 7. I shared the Claude Skill for free under the MIT license at https://github.com/zszendro/vc-teardown

I used Claude to help my brother-in-law build a Shopify website for his e-commerce store. By sharing screenshots, design references, and business requirements, I had Claude generate Liquid code, troubleshoot theme issues, modify page layouts, and explain exactly where changes needed to be made within Shopify. Instead of digging through forums and documentation for every issue, Claude acted like an on-demand Shopify developer, helping with everything. It sped up development, allowing the site to move from concept to launch much faster. Step-by-step: 1. I shared screenshots, design references, and the business requirements for the Shopify store with Claude. 2. I asked it to generate the Liquid code needed for the theme and explain where each change belonged in Shopify. 3. I used it to modify page layouts and translate visual feedback into specific code changes. 4. When theme issues appeared, I brought the errors and screenshots back to Claude for troubleshooting. 5. I repeated that loop until the store moved from concept to a working launch.

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!

Whenever a user wants to install a Skill, an MCP, or a CLI, the guard scans it for malware before installing it on all agent systems. Step-by-step: 1. Detect the user’s request to install a Skill, an MCP, or a CLI. 2. Scan the requested item for malware. 3. Install it on all agent systems.

I turned tedious Google Business Profile spammer tracking into a Claude Skill. It organizes the research and puts all findings into an XLS file that can be submitted through the Google Business Redressal form and the GBP forum for escalation by a Google Product Expert for Google review. Step-by-step: 1. I created a list of suspected spam profiles with each business name and Google Maps URL. 2. I asked Claude to examine each profile, determine its website, and identify any relationships between the domains. 3. I asked Claude to identify other businesses operating at the listed addresses. 4. I asked Claude to determine whether each profile is listed with the country’s primary Google data provider or providers. 5. I asked Claude to determine whether each profile is listed in a state or government registry. 6. I asked Claude to analyze commonalities across the profiles’ reviews, descriptions, and photos. 7. I asked Claude to identify patterns indicating whether the profiles are fake or real and whether they are related in some way. 8. I had Claude compile all findings into an XLS file for submission through the Google Business Redressal form and the GBP forum.

My girlfriend has a professional camera and lens for photographing birds. Because the camera captures an enormous number of images per second, sorting through them and keeping only the good ones after a day at the wetlands took a very long time. She showed me the two tools she was using to tag, crop, view, and zoom into photos, inspect focal points, and view the color histogram. I decided to vibe-code a C# tool using Cursor, Grok, and Claude Opus. The tool reads the EXIF and MakerNotes metadata in each picture and lets her scroll through all the photos in fullscreen with the mouse. It displays the histogram in the top-right corner and useful information—aperture, shutter speed, focal length in millimeters, and ISO—in the top-left, with color coding from red to green. It also shows the Nikon focus zone. Clicking the left mouse button zooms to 75%, allowing us to pan, while clicking the right mouse button zooms to 100%. Once we decide visually on the best crop and judge the photo’s potential, pressing a keyboard key instantly crops the image at the current view, saves a copy, tags the photo, and adds her copyright in the bottom-right corner. This makes the process much faster because she can view, tag, crop, and add copyright at the same time. It took about two hours of working with her to iterate on the tool and find the right balance of features and ease of use. Step-by-step: 1. I observed the two tools she was using to tag, crop, view, and inspect bird photographs. 2. I used Cursor, Grok, and Claude Opus to vibe-code a C# application for her workflow. 3. I made the tool read each photo’s EXIF and MakerNotes metadata. 4. I added fullscreen mouse scrolling, a histogram in the top-right, and camera information in the top-left, including aperture, shutter speed, focal length, and ISO. 5. I added red-to-green color coding and a display of the Nikon focus zone. 6. I set up left-click zoom to 75% with panning and right-click zoom to 100%. 7. I added a keyboard shortcut that crops the image at the current view, saves a copy, tags the photo, and adds her copyright in the bottom-right corner. 8. I iterated on the tool with her for about two hours until the features and ease of use were balanced for her needs.

I have Claude connected to all my communication platforms (Slack, Notion, calendars, Granola, etc) and pulls a morning brief for me each day. I've curated so it provides me an interactive page each day with call prep, priority tasks, recommendations of tools to use to solve XYZ, recap of activities overnight, etc. Step-by-step: 1. I connected Claude to the communication platforms I use, including Slack, Notion, calendars, and Granola. 2. I defined the sections I wanted every morning: call prep, priority tasks, overnight activity, and recommended tools. 3. I had Claude gather the relevant updates from each connected source. 4. I asked it to turn the result into an interactive page instead of a long unstructured message. 5. I refined the brief over time so it consistently surfaced the information I actually use.

A friend who had just started a pet-sitting and dog-walking business asked me to build a booking app. I used Google AI Studio to design the initial prototype. The process was straightforward, and I had a basic working system running within two hours. AI Studio created a Firebase database to store the details and was also effective at designing frontend changes. It published the app for me, and the resulting UI was intuitive. After demonstrating the app, I identified many additional features that needed to be added. This went beyond AI Studio’s capabilities, so I exported the code from AI Studio and started using Claude. I asked Claude to analyze the code and suggest the required changes. Claude identified critical security flaws in the database. I fixed them manually at first, but then realized that Claude could access the Firebase database and fix issues automatically. I continued prompting Claude with additional feature requests, and it built them. There were errors along the way, so I needed to be familiar with Google Chrome’s developer tools to copy the errors and ask Claude how to fix them. I used MailJS for email templates and Resend for email transport. I stored the app in GitHub and allowed Claude to access the repository so it could commit changes automatically. I ran the app locally with npm during development and then hosted it on Vercel. Eventually, I purchased an inexpensive domain name, and the app is currently hosted at Names. One major problem was that when Google AI Studio created the Firebase database, the permissions were locked, preventing me from making administrative changes. I solved this by recreating the database and asking Claude to write the SQL query to set it up. The permissions were still tricky, and I had to continue asking Claude to correct them. Google’s service permissions can be difficult to understand, and finding the correct settings was not always easy. Firebase was also complex to navigate, and getting the permissions configured correctly took time. Once I allowed Claude to connect to the app and its background services through the Google plugin, development became much faster. However, you need to trust the tool carefully and always work on a copy of the live app. Overall, I think app development with Google AI Studio and Claude is impressive. You can create professional apps quickly. I come from an IT support background, though, and I think people who are new to IT may find it difficult to troubleshoot errors without a basic understanding of networking and systems administration. I also built a litter-tracking app using ChatGPT, and it was equally effective. I eventually started using Codex and Claude Code, but I think standard Claude and ChatGPT are more intuitive for nontechnical users. Step-by-step: 1. I used Google AI Studio to create an initial booking-app prototype for a pet-sitting and dog-walking business. 2. I used the Firebase database created by AI Studio to store the app’s details and used AI Studio to design frontend changes. 3. I published the initial app with AI Studio and demonstrated it to identify additional features. 4. I exported the code from AI Studio and asked Claude to analyze it and suggest changes. 5. I addressed the critical database security flaws identified by Claude, first manually and later by allowing Claude to access the Firebase database. 6. I prompted Claude to build additional features and used Google Chrome’s developer tools to copy errors and ask Claude for fixes. 7. I recreated the Firebase database when AI Studio’s locked permissions prevented administrative changes, then asked Claude to write the SQL query to set it up. 8. I used MailJS for email templates and Resend for email transport. 9. I stored the app in GitHub and allowed Claude to commit changes automatically. 10. I ran the app locally with npm during development, hosted it on Vercel, and later purchased an inexpensive domain name that is currently hosted at Names. 11. I connected Claude to the app and background services through the Google plugin, while continuing to work on a copy of the live app.

I turned my company’s business continuity (BCEP) policy into an app that tracks storms, sends SMS updates, and automatically triggers policy actions. When a storm, tornado, or other emergency is reported within range of one of our office locations, the app sends SMS alerts to affected employees. It also triggers policy actions to prepare for office closures and safety check-ins, while maintaining an audit trail and compliance reporting. Step-by-step: 1. The app monitors reports of storms, tornadoes, and other emergencies within range of our office locations. 2. It identifies the affected employees and sends them SMS alerts. 3. It automatically triggers policy actions to prepare for office closures and safety check-ins. 4. It maintains an audit trail and generates reporting for compliance.

I run a small healthcare clinic and needed a monthly performance scoreboard that combined data from three separate sources: Google Analytics (GA4), my booking or appointment system, and a cashflow spreadsheet. Pulling everything manually each month took more than an hour and was prone to errors. I automated the pipeline using Claude-in-Chrome shortcuts and Claude’s analysis capabilities, reducing the process to around 10 minutes of hands-on time. Service businesses often have performance data scattered across a website analytics platform, a booking or practice management system, and a finance tool. Creating a coherent monthly view requires exporting data from each source, cross-referencing it, and manually calculating derived metrics such as rebook rate and conversion rate. This workflow automates data collection and analysis in one step. Step-by-step: 1. I set up two scheduled Claude-in-Chrome shortcuts to run automatically on the 1st of each month. One exports the GA4 Traffic Acquisition CSV, and the other exports the GA4 Pages and Screens CSV. Both save directly to a designated Google Drive folder. 2. On the 1st, I manually trigger a third Claude-in-Chrome shortcut. It logs into my booking system, navigates to the appointments export, and downloads the month’s appointment data. I keep this step manual because most booking systems log users out between sessions. 3. I open my cashflow spreadsheet and note the month’s revenue and profit figures. This takes about 30 seconds to do manually. 4. I open a Claude session and upload all four files together: the two GA4 exports, the appointment data, and the cashflow figures. 5. I prompt Claude to calculate the key metrics: total appointments, new patients, utilisation rate, rebook rate, average spend, online bookings, and website-to-booking conversion rate. The rebook rate is calculated from the appointment data as patients with a future booking divided by total patients seen. 6. Claude produces a formatted monthly scoreboard, flags anything that looks anomalous, and compares the results with the prior-month baseline when I include last month’s scoreboard in the upload. 7. Optionally, I ask Claude to produce individual practitioner breakdowns from the same appointment data, splitting the metrics by staff member for use in one-on-one reviews. The result is a complete, accurate monthly clinic scoreboard in around 10 minutes, with no manual calculations. The rebook rate computation alone, which previously required cross-referencing two separate reports, now takes seconds. The same workflow can adapt to any service business using a booking or practice management system that allows CSV exports. Tools used: Claude (Sonnet 5), Claude-in-Chrome extension, Google Analytics GA4, Google Drive, any booking or appointment system with CSV export capability, and Google Sheets or Excel for cashflow figures.

I open Pulse and click Pull AM Brief or Pull PM Brief, search for a topic, or paste in an article link. That triggers a call to Claude, which scans for the five most relevant marketing, AI, and CPG stories that day. I choose one story and expand it into a full seven-slide carousel. Claude writes all the copy according to our brand’s specific editorial rules. I can then generate AI imagery for each slide. The final slide gets a custom scene generated with our actual logo built into it, so it feels native to the story instead of looking like a generic closing card. Once the carousel is built, I run it through a scoring system that evaluates factors such as how surprising the opening is and how likely people are to share it. If a slide scores low, the system automatically rewrites it until it passes. Finally, it generates the caption, a call to action, and a LinkedIn post, and I download everything ready to publish. Step-by-step: 1. I open Pulse and select Pull AM Brief, Pull PM Brief, a topic search, or an article link. 2. Claude scans for the five most relevant marketing, AI, and CPG stories of the day. 3. I select one story and expand it into a seven-slide carousel. 4. Claude writes the carousel copy according to our brand’s editorial rules. 5. I generate AI imagery for each slide, including a custom final-slide scene with our actual logo built into it. 6. I run the carousel through the scoring system, which evaluates the opening’s surprise and the likelihood that people will share it. 7. The system rewrites any low-scoring slide until it passes. 8. I generate the caption, a call to action, and a LinkedIn post, then download everything ready to publish.

I used Claude to build an automated patient scheduler for my husband, who is the Director of Rehab at a skilled nursing facility. Each week, he takes a patient list in Excel and schedules each patient for the types of therapy they need—speech, physical therapy, or occupational therapy—based on therapist availability. The variables change from week to week, making the process time-consuming and error-prone. Automating it saves him at least an hour each week, usually on Sundays when he creates the schedule for the coming week. He uploads the patient spreadsheet and clicks “Generate schedule.” Under the hood, the app uses Google’s OR-Tools CP-SAT solver to optimize the schedule against hard constraints and weighted priorities. Hard constraints include never exceeding a therapist’s daily capacity or a patient’s maximum weekly visits. Weighted priorities include giving higher-acuity patients preference when capacity is tight, providing every patient with daily contact when possible, and balancing the workload across the week instead of simply sorting patients by who fits first. I wrote zero code. I gave Claude all the features in plain English, and it wrote the app in Python and created a test suite of approximately 35 tests. One test was added after we found and diagnosed a bug in production. I also had Claude walk me through creating a `.exe` file that I could send directly to my husband so it would open on his PC. Patient data never leaves his machine. New versions are easily compiled in GitHub, where patient data never touches the process, and enhancements only require sending a new file. Step-by-step: 1. I described the scheduling requirements and features to Claude in plain English. 2. Claude wrote the scheduling app in Python and created a test suite of approximately 35 tests. 3. I provided an Excel spreadsheet containing the weekly patient list. 4. My husband uploads the spreadsheet and clicks “Generate schedule.” 5. The app uses Google’s OR-Tools CP-SAT solver to schedule speech, physical therapy, and occupational therapy according to therapist availability and patient needs. 6. The solver enforces therapist daily-capacity limits and patient maximum-weekly-visit limits. 7. It also applies weighted priorities: higher-acuity patients receive preference when capacity is tight, every patient receives daily contact when possible, and the workload is balanced across the week. 8. After finding and diagnosing a production bug, we added a corresponding test to the suite. 9. I used Claude’s guidance to create a `.exe` file that opens on my husband’s PC, keeping patient data on his machine. 10. I compile new versions in GitHub without patient data entering that process, then send the updated file when enhancements are needed.