Share your best AI workflow. We could show it to 2M+ people.

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 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.

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 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 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 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.

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 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.

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.

My AI digest looked perfect and was quietly wrong. What actually fixed it. Every run succeeded. Every dashboard was green. And the content was still wrong. My digest invented "AI Moat Brief", a newsletter that does not exist. It reported scan counts nobody measured. It resurfaced week-old stories as fresh headlines. Here is what broke, and what fixed it. The sorting used to happen in my head: skimmed subject lines, unopened tabs, quiet guilt. The Signal is one email at 08:00: a single Make scenario calling Claude Sonnet through OpenRouter. It reads the last 24 hours of my RSS feeds and newsletters, keeps what touches what I am actively building plus the domains I need to stay current in, and arrives in the language I actually think in. Core items end with what it means for my work. Five to ten minutes, and I know where to go deep today. Structurally it looks like this, minus the content, rendered in English for this post (Image 1). No real edition is shown; section names and sample lines are illustrative. The dangerous failures were never pipeline failures. They were content failures, and the cause is structural: an LLM summarizing newsletters that already summarize primary sources is third hand by construction. Every hop strips attribution and adds confidence, and when data goes missing the model fills the gap the way LLMs do: fluently. Valid HTML, confident tone, green pipeline, wrong content. Image 2 is that whole failure class in one frame. Three rules closed the gaps I caught, all live in production: Step-by-step: 1. Verbatim or nothing. A source name is copied character for character, and a link exists only if that exact URL is in the input. The model copies; it never composes. 2. The model never generates metrics. Every count the report shows is injected by the pipeline after the model returns. 3. Recycled news gets demoted. A recap of recaps gets one line at most, and is dropped when the underlying story falls outside the collection window. Rules 1 and 3 lean on the prompt, and that is why the counters exist. The pipeline writes a hidden HTML comment into every email it sends: items, links, urls, cost, finish status. That line caught what I could not see. In one run, the published-links counter and the leftover-urls counter read 45 and 435: the only sign a new cleanup step was a silent no-op. Another morning the model stopped at 15,999 tokens against a 16,000 cap, one token from an email cut off mid-sentence. On the morning I wrote this they agreed, 21 links and 21 urls, and boring is the goal. Image 3 is that morning's actual comment, with the same two counters from the no-op run. The run itself has a dead man's switch on Healthchecks.io, so a missing 08:00 email reaches me before I notice. Honest limits: the $0.31 per report is a fresh measurement I am still validating, and I have not proven these rules hold as the source set scales. There is more behind every part of this; I would rather share it where it is wanted. Ask and I will put it in the comments: the three rules in full, the exact cost and what drives it, what this replaced in my day, how it compares to what is on the market, or the ugliest of the 15 documented bugs. I am sharing this because I doubt I am the only one building fragile things behind the scenes, and monitoring text is harder than monitoring uptime. What content-level checks do you run on LLM output, the kind pipeline monitoring cannot see? Real thresholds and embarrassing failures especially welcome.

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.

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.

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 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 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 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.

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.

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.

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.