Workflow Hub

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.

Faceplant is a real full-stack app, not a mockup. It uses a FastAPI and PostgreSQL backend, a React and MUI frontend, and the Anthropic API (Claude) to power bot replies. The core is the reaction engine. When a human posts, the backend schedules two timed waves of reaction jobs. A background scheduler built with APScheduler polls for due jobs, calls Claude for an in-persona reply, and writes that bot’s comment and like. The 56 personas are stored as data in a roster file. Adding a voice requires only one new entry, so the crowd can scale without additional code. A subset of the personas are GIF-first bots: they ask the model for a caption and search tag, then pull a matching GIF from Giphy. The part I’m proudest of is the honesty layer. Every Claude call is metered and priced, and “The Meter” rolls the data up live with the cost per post, the dollar-per-minute burn rate, and a “spent on nobody” line for bot-to-bot chatter with no human at either end. A “% human” badge drains toward “dead internet” for each thread. The dead-internet loop—bots posting and replying to one another with no human present—is disabled by default and protected by three guardrails: generation decay, a per-thread cap, and a global spend kill switch. Optional cost controls include the Message Batches API at half price and prompt caching for a shared house-style prompt. The whole project is a working demonstration that manufactured engagement is cheap to produce and expensive to mean anything. Step-by-step: 1. I built the app with a FastAPI and PostgreSQL backend, a React and MUI frontend, and Claude replies powered by the Anthropic API. 2. When a human posts, the backend schedules two timed waves of reaction jobs. 3. APScheduler polls for due jobs and triggers Claude to generate an in-persona reply before writing the bot’s comment and like. 4. I keep the 56 personas in a roster file so adding a voice requires only one new data entry. 5. For GIF-first bots, I have the model generate a caption and search tag, then use that tag to pull a matching GIF from Giphy. 6. I meter and price every Claude call, then display live cost per post, dollar-per-minute burn, “spent on nobody” costs, and the “% human” status for each thread. 7. I keep bot-to-bot activity disabled by default and limit it with generation decay, a per-thread cap, and a global spend kill switch. 8. I can reduce costs further with the Message Batches API at half price and prompt caching on a shared house-style prompt.

I built an autonomous, end-to-end AI Sales Development Representative (SDR) engine entirely in n8n. On a scheduled trigger, the agent calculates targeting parameters, reads long-term CRM memory to avoid duplicate outreach, searches for and qualifies prospective leads, scrapes company websites for buying signals, drafts tailored outreach emails, writes structured relational data to PostgreSQL, and reports execution summaries through Telegram—with zero manual intervention. The system is currently deployed in production for a B2B agricultural export business, generating qualified international wholesale leads on a recurring schedule. Most AI automations rely on simple linear scripts or break down when handling complex agentic tool workflows. This system addresses three common failure points: - High API costs: Re-sending large system prompts and tool schemas on every agent iteration drains tokens. - Context blindness: Agents without memory of previous contacts can send duplicate outreach. - Database crashes: Agents may hallucinate ENUM values or fail to insert nested one-to-many arrays into relational tables. The workflow uses a Cloudflare-proxied Claude Sonnet 4.6 model with prompt caching, persistent CRM memory reads, and a fault-tolerant parallel database-write architecture. The stack includes n8n as the orchestrator; Claude Sonnet 4.6 through a Cloudflare Worker proxy as the LLM core with ephemeral prompt caching; PostgreSQL for CRM contacts, intelligence, and outreach tables with custom ENUMs; SerpAPI for prospect discovery; Firecrawl for website content extraction; and Telegram for execution reporting. The workflow exposes these tools to the n8n agent: - `read_relationship_memory`: Read-only SQL access to historical contact and outreach data, preventing duplicate prospecting. - `Lead_Finder`: Searches for and identifies target prospects by country and sector. - `Scrape_Website_Content`: Extracts website content, buyer-intent signals, and objections from discovered domains. - `write_relationship_memory`: Writes leads, intelligence facts, and drafted emails to Postgres in one resilient call. Step-by-step: 1. A Schedule Trigger feeds a JavaScript “Country Calculator” node that resolves the day’s targeting parameters—region and industry focus—using ISO week rotation. This cycles outreach across markets automatically. 2. The AI Agent connects to an OpenAI Chat Model node whose Base URL points to a custom Cloudflare Worker. The worker translates OpenAI-formatted requests into Anthropic’s Messages API, enabling Claude Sonnet 4.6 while injecting ephemeral cache-control headers into the system prompt and tool definitions to reduce repeat-token costs. 3. Before researching, the agent calls `read_relationship_memory` to check relationship status and outreach history, preventing duplicate contact attempts. 4. `Lead_Finder` searches target sectors in the day’s region and returns seven filtered candidates. `Scrape_Website_Content` then visits each domain, extracts clean page text, and surfaces offerings, value propositions, and likely objections. 5. The workflow writes nested one-to-many data—multiple facts and one outreach log per contact—without item duplication or ENUM crashes. The tool schema requires a strict JSON array with exact ENUM string choices spelled out in the description. 6. A sub-workflow triggered by “When Executed by Another Workflow” splits the array, then flattens nested `contact.*` fields to root keys using JavaScript. 7. An upsert query, `ON CONFLICT (email) DO UPDATE`, writes the contact, increments `email_count` for repeats, and returns `contact_id`. 8. A “Re-attach Context” node merges `contact_id` back with the original intelligence array and outreach payload because n8n strips extra data through single-row database nodes. 9. Two parallel branches run: one inserts the outreach log with `ON CONFLICT DO NOTHING`, while the other splits and inserts each intelligence fact with defensive ENUM sanitization. This eliminates crashes and duplicate rows during retries. 10. The agent’s final output triggers a Telegram message summarizing the discovered leads, extracted facts, and drafted emails, sent directly to the operator’s phone. The result is a production-grade, self-healing AI outbound pipeline running with zero manual intervention. It maintains CRM data integrity, avoids duplicate outreach, and uses prompt caching to keep LLM costs low at scale.

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.

I recently had an Evolt body scan. I've uploaded my results to Claude, shared my daily habits (sleep, diet, schedules, etc.), and asked it to create a full workout and diet plan based on the areas I want to improve. I was also able to include my recent Oura ring report to see if there's anything wrong with me. Will I follow it? We'll see.... Step-by-step: 1. I uploaded my Evolt body-scan results to Claude. 2. I added context about my sleep, diet, schedule, daily habits, goals, and the areas I wanted to improve. 3. I included my recent Oura report so the analysis could consider recovery and other wearable data alongside the scan. 4. I asked for a complete workout and diet plan tailored to the combined information. 5. I reviewed the plan as one organized starting point instead of trying to reconcile each source manually.

I built AllegraMente, a complete, free iOS cognitive training app, solo with Claude Code. It includes 11 exercise areas, 83 articles in five languages, and no tracking. My workflow starts with a new feature or content idea, a new exercise type, or an in-depth article about how memory works. Planning and execution stay separate, and the instruction document serves as the contract. Because everything is specified upfront, Claude Code almost never goes off track. Step-by-step: 1. I plan the feature with Claude in chat, define the data models and UX, and fact-check every scientific claim against primary sources before writing anything. 2. I package the result into one self-contained Markdown instruction document containing file paths, specifications, localization keys for all five languages (IT/EN/ES/FR/DE), edge cases, and acceptance criteria. 3. I create a Git restore point. 4. I give the document to Claude Code, which implements the feature end to end using SwiftUI, SwiftData, and MVVM. 5. A small script sends me a Telegram notification when the task is complete. I review the diff and test the app on a device. 6. I ship by creating an archive with `xcodebuild` and uploading it to the App Store with Transporter. This process is how I shipped 11 exercise areas, 83 articles in five languages, and a complete editorial system as a solo developer.

I had a project that was perplexing me, so I asked an AI for help by simply typing, "I'm a stupid moron." The AI helped me with the issues I was having with my project. 1. I described my project-related difficulties by typing, "I'm a stupid moron." 2. I used the AI's help to address the issues I was having with my project.

I kept forgetting who I had lent books to, and spreadsheets felt like overkill. So I built Runo, a book-lending app for friends, without traditional coding. Runo (runo.club) is a web app where I can catalog my home library, get a unique shareable link, and let friends browse my books and request to borrow them. I can approve or decline each request with one click. Step-by-step: 1. I used Claude to think through the feature set, data model, and UX flow before writing a single prompt. This helped me avoid building the wrong thing first and gave me a clear blueprint for the Lovable prompts that followed. 2. I used Claude to create precise, narrowly scoped prompts for Lovable, with each prompt focused on a single change so existing functionality would be less likely to break. This significantly conserved Lovable credits. The React, TypeScript, and Supabase stack came out of the box. 3. I added two ways to scan books instead of requiring users to type titles manually: - Barcode scanner: Point the camera at an ISBN barcode to autofill the title, author, and cover using the Open Library API. - Cover photo scanner: Photograph the cover so Gemini 2.5 Flash can extract the title and author in under 2 seconds. 4. I routed the cover scanner through a Supabase Edge Function using Lovable’s AI Gateway, so the API key never touches the client bundle. 5. For every bug fix and feature, I followed the same iteration loop: describe the problem to Claude, get a precise Lovable prompt, push the changes to GitHub, and let Lovable auto-sync them. Claude and Lovable’s bidirectional GitHub sync made the process feel like pair programming. Tools used: Lovable, Claude (Sonnet), Gemini 2.5 Flash (via Lovable AI Gateway), Supabase, and GitHub. Live at: runo.club — public beta and free to use. Feedback welcome. #appbuilding #vibecoding #buildinpublic #lovable #nocode

I ran a prompt to read and listen to all key notes from companies in the medical device industry over the last year. I used it to identify where attention was being drawn and where companies were investing. This helped me see the trends companies were discussing, investing in, or directing their efforts toward. Step-by-step: 1. I ran a prompt over key notes from medical device companies covering the last year. 2. I used the prompt to identify where companies were directing attention and investment. 3. I reviewed the results to see which trends companies were discussing and prioritizing.

I created an agent collaboration system called duo-agents that pairs Claude and Codex to work together on coding tasks... Claude acts as the implementer (coder), then Codex acts as the reviewer (checks and makes edits). They alternate in rounds, communicating through a shared file. The key difference: both agents actually edit files — the reviewer doesn't just leave comments, they make the fixes themselves. Describe your task and watch them iterate until the code is solid. Step-by-step: 1. I created a shared file that both coding agents could use to pass context and decisions back and forth. 2. I assigned Claude the implementer role and had it build the requested change directly in the codebase. 3. I assigned Codex the reviewer role and had it inspect the implementation for problems. 4. Instead of leaving comments, Codex edited the files and made the fixes itself. 5. I alternated the two agents in rounds until the shared task was complete and the code was solid.

I used to open calls by asking people to remind me where we left off. The notes existed, but they were scattered across transcripts that nobody reviewed. I built two scheduled tasks that work together: one files every meeting at the end of the day, and the other sends me a prep brief every morning. At the end of each day, the first task pulls the verbatim transcript of every meeting I had into a shared Notion database. I use the transcript rather than the AI summary because summaries may be useful that afternoon but are less useful three weeks later when I need the exact thing somebody said. Each meeting becomes a page with the date, client, and attendees stored as real relations rather than text, so everything is filterable later. My business partner has access to the same database, so neither of us has to recap our calls for the other. At 7 a.m., the second task reads my Outlook calendar, finds the email thread or threads tied to each meeting, reads the associated transcripts in Notion, and writes a short prep brief for each one: what we said last time, what I owe them, and what is still open. The part that took the most thought was deciding what should not be filed in the main database. Personal meetings are skipped by keyword. Small internal meetings are screened for topics such as pay, hiring, legal matters, or client-confidential material. Those meetings are routed to a separate database with different permissions. When a meeting is ambiguous, it defaults to the restricted database. Failing toward privacy is the right default when a robot is making the decision. Step-by-step: 1. I turned on Zoom AI Companion so every meeting produces a transcript, then connected Zoom, Notion, and Outlook. 2. I built a Notion database for meeting notes with Date, Client, and Attendees as relation properties connected to existing Clients and People databases. These relations make the notes findable later. 3. I wrote the end-of-day task to pull each transcript verbatim, create a page, match the client by keyword against my client list, and add attendees based on the transcript speakers. 4. I filtered the speaker list because notetaker bots appear as attendees. I removed Fireflies, Otter, Fathom, and the other notetaker bots, and automatically created a person page for anyone who was genuinely new. 5. I deduplicated meetings using the title and date. If a page already existed as a placeholder, I updated it in place instead of creating a second one. 6. I added a skip list for personal meetings and a confidentiality screen that routes sensitive internal meetings to a separate, permission-restricted database. When the classification is unclear, it defaults to restricted. 7. I wrote the morning task to read that day’s calendar, search email and transcripts for each attendee and company, and produce one short brief per meeting covering the last contact, open commitments, and what I owe them. 8. I scheduled both tasks: the filing task for the end of the day and the briefing task for early morning.

Microsoft is retiring Publisher on October 1, 2026. I have many `.PUB` files that I need to convert to PDFs before then, but I did not want to use online converters. I wanted a solution that would run locally on my computer. I worked with Claude to create a lightweight program that searches for `.PUB` files on a drive of my choice and converts them into high-quality PDF files, placing each new PDF in the same folder as its source file. Opening PowerShell manually and managing permissions was too cumbersome, so Claude also created a batch file to make the process easier. For anyone who wants to create their own mini-program, I asked Claude to create a reusable prompt. I posted that prompt at https://mediumseagreen-seal-177480.hostingersite.com/ along with my two files: the batch file and the PowerShell commands. Step-by-step: 1. I identified the `.PUB` files I needed to convert before Microsoft retires Publisher on October 1, 2026. 2. I decided to use a local solution instead of an online converter. 3. I worked with Claude to create a lightweight program that searches a selected drive for `.PUB` files. 4. I set up the program to convert the files into high-quality PDFs and place each PDF in the same folder as its source `.PUB` file. 5. I used a batch file created by Claude so I would not need to open PowerShell manually or manage permissions each time. 6. I asked Claude to create a reusable prompt for others who want to build their own version and posted it with the batch file and PowerShell commands at https://mediumseagreen-seal-177480.hostingersite.com/.

My pool water looks great, and I’ve taken over the weekly water-care routine myself after years of using a pool service. I first gave Claude the relevant information about my in-ground pool setup. Now, each week, I check the water’s chlorine, pH, alkalinity, and other chemical levels, then enter the results into Claude. I often take a water sample to a local pool store, where they provide a printed analysis. I snap a photo of the analysis with my phone and upload it to the Claude chat. Claude tells me which chemicals to add and when. Over time, the water has stayed balanced and looks great, while I’ve saved a lot of money on pool service and avoided wasting chemicals. This workflow has paid for itself many times over through this one use case. Step-by-step: 1. I gave Claude the relevant information about my in-ground pool setup. 2. I checked the pool water weekly, including chlorine, pH, alkalinity, and other chemical levels. 3. I either entered the results into Claude or took a water sample to a local pool store for a printed analysis. 4. I photographed the printed analysis with my phone and uploaded it to the Claude chat. 5. I followed Claude’s guidance on which chemicals to add and when. 6. I repeated the process over time to keep the water balanced and avoid wasting chemicals.

I developed a platform that helps users learn dimensional modeling and create entity-relationship (ER) diagrams through a drag-and-drop interface tailored to specific use cases. I noticed that many people struggle with visualization and face a significant gap between understanding database concepts and creating tables. This can make it difficult to work independently or determine which type of table to use and when, including whether to create a dimension or fact table. Step-by-step: 1. I identified the difficulty many people have visualizing dimensional modeling concepts. 2. I created a platform focused on learning dimensional modeling and ER diagrams. 3. I built a drag-and-drop interface tailored to specific use cases. 4. I designed it to help users understand how to create tables and determine whether to use a dimension table or a fact table.

Customer events trigger AI workflows that classify requests, automate actions, update systems, and keep teams in sync without manual intervention. Step-by-step: 1. Customer events trigger the AI workflows. 2. The workflows classify requests. 3. They automate actions and update systems. 4. They keep teams in sync without manual intervention.

I was initially told by my CA that I might owe close to $10K in taxes on my income. Since this felt higher than expected, I decided to double-check the calculation using Claude. I shared my contract structure, invoices, and payment flow, and asked it to review how my services should be classified under Goods & Services Tax. While going through the latest regulations, it pointed me to a recent government circular that clarified how certain digital services provided to clients can qualify as export of services. I discussed this with my CA, who reviewed and confirmed it applied to my case. This reduced my tax liability by several thousand dollars. Step-by-step: 1. I collected my contract structure, invoices, payment flow, and the original tax calculation. 2. I asked Claude to review how the services should be classified under Goods and Services Tax. 3. I had it search the current regulations for primary guidance that applied to digital services and exports. 4. Claude surfaced a recent government circular that appeared relevant to the way the services were delivered. 5. I took the circular and reasoning to my chartered accountant, who verified that it applied before the tax position was changed.

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.

I used Claude Code to find scientific seminars hosted by colleges and universities across the US and collate them into a single, searchable list. Researchers can use it to find talks that match their interests near them. The site, seminarsearch.org, runs mostly on free-tier SaaS services, costs me $5 per month to operate, and currently supports a few thousand users. The same pattern could be adapted to collate all 5K runs in the US, tennis matches, craft shows, quilting bees, or any other type of event that interests you. I started by explaining to Claude what I wanted to build. We then spent a few hours exploring where and how to identify seminar calendars at universities across the US, which was arguably the hardest part. We developed a pluggable framework with scraping plugins for the common CMSs used by universities, along with iCal parsers, HTML parsers, and JavaScript interpreters to handle the complexity of normalizing content from hundreds of departmental websites. Once we had the seminar-scraping infrastructure, we built a database schema in Supabase and simple APIs to create, read, update, and delete records. The APIs are written in Python and hosted on Railway for $5 per month. We used Vercel to deploy a simple React-based frontend for presenting the data. Now I can ask Claude to implement a feature or add a new university to the list of sources. It figures out where the data is hosted, creates entries for the university and its departments, finds their seminar feeds, collects the seminar data, puts it into the database, and runs GitHub Actions to send alerts to registered users. The scraping job runs once a week to collect new data, and it also runs through GitHub Actions. I wrote zero code during this process and have never even looked at the code. I only had to paste a few error messages from Railway into Claude so it could debug them, and there were only a few errors. Since building seminarsearch.org, I have cloned the infrastructure and codebase and modified it to build a site that collects road bike rides and group mountain bike rides across the country. The system is highly extensible to new areas of interest and is useful when traveling or living in a large metropolitan area where it is difficult to keep track of all the opportunities available for your interests. Step-by-step: 1. I explained to Claude Code that I wanted to build a searchable directory of scientific seminars hosted by colleges and universities across the US. 2. We explored where and how to identify university seminar calendars, focusing on the challenge of finding sources across many institutions. 3. We built a pluggable scraping framework with plugins for common university CMSs, plus iCal parsers, HTML parsers, and JavaScript interpreters. 4. We created a Supabase database schema and simple Python APIs for creating, reading, updating, and deleting seminar records. 5. We hosted the APIs on Railway for $5 per month and deployed a React-based frontend on Vercel. 6. We configured Claude to add universities and implement features by finding source locations, creating university and department records, locating seminar feeds, collecting seminar data, and adding it to the database. 7. We used GitHub Actions to run the weekly scraping job and send alerts to registered users. 8. When Railway returned errors, I pasted a few error messages into Claude so it could debug them. 9. I cloned and modified the infrastructure and codebase to create additional sites for road bike rides and group mountain bike rides across the country.

I built a workflow to reconstruct auditable, per-client billing for Claude usage after my Anthropic bill tripled in one month and I discovered there was no reliable way to see why. I run a solo consulting practice on a Max plan and pass AI costs through to clients. In September, my extra usage reached $1,805.76 in nineteen days. The usage page attributed 100 percent of one week to "Cowork" without session detail. Auto-reload was enabled by default with no spending limit, and the only usage I could independently verify—my local Claude Code logs—accounted for about $245. The support bot twice described analytics features that did not exist, including a per-day view it later retracted. When I finally reached a human, I got the truth in writing: Max subscribers have no session-level or per-day reporting, exports are Enterprise-only, and Cowork has been cloud-only on consumer plans since August. The Enterprise path to a readable meter starts at twenty seats. I am one person, so I built my own meter. The irony is that I used Claude to design and code it. Claude Code sessions write logs on my own machine. I price them at list rates with the open-source `ccusage` tool and attribute each session to a client by repo folder. That creates the measured pool: real receipts with no allocation. Other CLIs in the same logs, such as OpenAI Codex, are excluded automatically. Chat and Cowork run in Anthropic’s cloud and leave nothing on my disk, so the remaining overage becomes a cloud pool. I split that pool using evidence my workflow already produces: every Cowork document batch leaves a directive file, snapshots, and a report on disk. A Python script counts executed batches per project and measures the number of bytes each one rewrote. The script splits the cloud pool independently by batch count and byte volume, bills the midpoint, and shows both derivations so each client can see the bracket. Every column ties back to the dashboard total to the penny. A second script pulls per-account AWS charges from Cost Explorer because each client has a separate AWS account. Shell aliases make each report a one-command operation. A Claude skill and a monthly scheduled task turn the outputs into a draft invoice that I approve before anything is sent. The result is that a vendor hands me one unexplained number each month, while I hand my clients an evidence file. Month-end billing takes five minutes. It should not have been necessary to build this, but until consumer plans get real usage analytics, this is how I see in the dark. Step-by-step: 1. I collect local Claude Code session logs and use the open-source `ccusage` tool to price them at list rates. 2. I attribute each Claude Code session to a client by repo folder and automatically exclude other CLIs, such as OpenAI Codex, from the measured pool. 3. I treat the remaining overage from cloud-based Chat and Cowork usage as a separate cloud pool because those services leave no usage logs on my disk. 4. I use Cowork’s directive files, snapshots, and reports to identify document batches, then use a Python script to count executed batches per project and measure the bytes each batch rewrote. 5. I split the cloud pool independently by batch count and byte volume, bill the midpoint, and show both derivations as a client-facing bracket. 6. I verify that every column ties back to the dashboard total to the penny. 7. I use a second script to pull each client’s per-account AWS charges from Cost Explorer. 8. I run the reports through shell aliases, then use a Claude skill and a monthly scheduled task to create a draft invoice for my approval before sending it.

I fed Claude my sweat-test data, and it formulated a DIY high-carb cycling mix tuned to my sweat chemistry. It also scaled the batch to match my available supplies and generated print-ready labels and batch sheets. Step-by-step: 1. I provided Claude with my sweat-test data. 2. I used Claude to formulate a DIY high-carb cycling mix tuned to my sweat chemistry. 3. I had Claude scale the batch to match my available supplies. 4. I had Claude generate print-ready labels and batch sheets.