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

I used Claude and Nano Banana 2 to create a detailed landscaping plan for my property. The plan included precise recommendations for plant types and locations, soil testing, purchase lists, local suppliers, expected wholesale pricing, and photorealistic images of the mature planting beds. I refined the plan through 20–30 iterations, incorporating all of my requirements. Because I have previous experience working with landscape architects, I was able to use the AI-generated plan effectively and legitimately saved $5,000 in fees. Step-by-step: 1. I used Claude and Nano Banana 2 to develop a landscaping plan for my property. 2. I included requirements for plant types and locations, soil testing, purchase lists, local suppliers, expected wholesale pricing, and photorealistic images of the mature planting beds. 3. I refined the plan through 20–30 iterations until all of my requirements were incorporated. 4. I used my previous experience working with landscape architects to evaluate and apply the plan. 5. I saved $5,000 in landscape architecture fees.

I built a weekly interactive training-course generator for my 10-year-old son and eventually landed on a much simpler final version than where I started. I wanted a way to teach him practical safety and life skills, starting with how to swim confidently and what to do if he gets into trouble in the water. I needed something more engaging than simply talking at him, but writing a polished, interactive lesson from scratch every week was not sustainable. First, Claude and I designed a single interactive HTML course as a proof of concept. It was a swim-safety course with a branded look, including a custom color palette, fonts, and a progress tracker styled like pool lanes. The course was divided into modules: a welcome screen, a comfort-and-basics lesson, a step-by-step skills walkthrough, a safety checklist, a “what to do if something goes wrong” module, a quiz, and a certificate at the end. The “what to do if something goes wrong” module was the most important part. Once the course worked, I wanted to reuse the same format for a new topic every week. Claude first built a version that called the Claude API live from inside the page to generate new content on demand. However, it only worked while the page stayed open inside Claude.ai, and occasionally a section failed to generate cleanly. We pivoted to a simpler approach. Instead of using a live tool, Claude documented the entire course format—including the visual identity, module structure, tone, and content rules—as a standing “brief” document. Each week, I open Claude Cowork, paste in the brief and that week’s topic—bike safety, fire safety, or whatever is next—and Cowork returns a finished, fully self-contained HTML file. There is no app to babysit and no live API call; I can simply open the file and hand it to my son. The result is a repeatable, no-maintenance weekly workflow for turning any topic into a polished interactive lesson for my kid. Step-by-step: 1. I identified a need for more engaging lessons on practical safety and life skills, starting with swimming and water safety. 2. I worked with Claude to create a proof-of-concept interactive HTML swim-safety course. 3. I structured the course into a welcome screen, comfort-and-basics lesson, skills walkthrough, safety checklist, emergency-response module, quiz, and certificate. 4. I tested a live-generation version that called the Claude API from inside the page, then noted that it only worked while open inside Claude.ai and that sections sometimes failed to generate cleanly. 5. I had Claude document the course’s visual identity, module structure, tone, and content rules in a reusable brief. 6. Each week, I open Claude Cowork, provide the brief and a new topic, and receive a finished, self-contained HTML course file. 7. I open the file and give the interactive lesson to my son without maintaining an app or making live API calls.

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

I write murder mysteries, and like every author, I need an editor to help carry a story from the first raw idea to a finished, publishable script. The trouble is that good editors are rare. The insightful, reliable ones are expensive, and they are often slow. My first murder mystery took the better part of six months to edit. Even after all that time, I still found typos and clumsy sentences that should have been caught during the line edit and proofreading. That is not a criticism of editors; it is the reality of a manual, human-paced process that does not scale to the way I want to work. I do not use AI to write my stories. The voice, plot, and subtext are mine. But line editing and proofreading are different jobs, and that is where I started using AI. Basic paid ChatGPT got me part of the way, but it was not enough. In February, I switched to Claude, and it was a quantum leap: sharper suggestions, better reasoning, and output I could actually trust. I wanted more than a clever assistant. I wanted a process. Rather than wait for the perfect human editor—affordable, brilliant, and available precisely when I needed them—I built my own. My Claude Editor-in-Chief contains my entire editing workflow, along with a few innovations of my own. At its heart is a framework I developed: the Tension Coefficient (TC), ReaderGrip, and StoryDrift. These three lenses show whether a scene is pulling its weight, whether it keeps its grip on the reader, and whether the story is quietly wandering off course. Everything feeds into a dashboard, so I can see at a glance what is working and what needs fixing. The result is a workflow that turns editing from a six-month slog into something that takes a fraction of the time and, more importantly, produces a cleaner, tighter manuscript. I stopped waiting for help and built the editor I always wished I could hire. Step-by-step: 1. I kept the creative work—my story’s voice, plot, and subtext—in my own hands and used AI specifically for line editing and proofreading. 2. I started with basic paid ChatGPT, then switched to Claude in February after finding that it provided sharper suggestions, better reasoning, and output I could trust. 3. I built a Claude Editor-in-Chief around my full editing workflow instead of relying on Claude as a general-purpose assistant. 4. I added my Tension Coefficient (TC), ReaderGrip, and StoryDrift frameworks to evaluate whether scenes are effective, maintain reader engagement, and stay on course. 5. I connected those evaluations to a dashboard that shows what is working and what needs fixing. 6. I use the workflow to reduce editing time and produce a cleaner, tighter manuscript.

I have set up Claude to give me a daily outfit recommendation based on the local weather and the type of brands that fill 70% of my closet. I've provided examples and feedback, so suggestions become more and more accurate to my style and what I would normally wear without needing to think about it. Step-by-step: 1. I told Claude my location and gave it access to the local weather context for the day. 2. I described the brands and clothing styles that make up most of my wardrobe. 3. I provided examples of outfits that felt like me and examples that did not. 4. I asked for one daily recommendation that fit both the weather and my existing style. 5. I kept giving feedback so the recommendations became more accurate over time.

I was deep in a Claude research session, trying to brainstorm an idea, rejecting its responses, asking for more, rejecting again. Eventually, it broke the pattern and stopped complying, telling me the problem was how I'd framed the question and explaining why. It had a point, and that may be one of AI's more interesting uses: not just an engine for fast answers but as a friction layer for thought. Step-by-step: 1. I used Claude as a brainstorming partner and kept reacting honestly when an answer did not move the idea forward. 2. When the conversation became repetitive, I paid attention to the pattern instead of simply asking for another variation. 3. I let Claude challenge the way I had framed the question and explain why the framing was constraining the answers. 4. I rewrote the problem around that critique and used the new framing to continue the work. 5. I treated the model as a source of productive friction, not just a machine for fast agreement.

I uploaded five years of echocardiograms to Claude and asked it to analyze them as though it were a medical technician. Step-by-step: 1. I uploaded five years of echocardiograms to Claude. 2. I asked Claude to analyze the series as though it were a medical technician.

I’m on a GLP-1 medication that heavily suppresses my appetite, and I’m also managing a bilateral vestibular condition that causes balance and gaze issues. I needed a way to hit my protein and calorie targets despite having a low appetite, track body composition accurately, log vestibular symptoms, connect my actual training data, and get coaching guidance that reflects my situation instead of generic fitness-app advice. I built FuelStrong: three connected apps created with Claude over many sessions. They include a daily tracker for meals, water, energy, and training check-ins; a Progress and analytics module; and a standalone Vestibular symptom tracker. They share a Cloudflare Worker and D1 database backend, with KV for cross-device sync. I describe a feature or problem to Claude in plain language. Claude proposes structural options, I push back or choose a direction, and Claude writes the HTML, CSS, and JavaScript. I program my lifts in Fitbod using an Upper/Lower/Upper split, with an arms-and-back priority and the Build Muscle goal. I export those workouts as CSV and drop them into FuelStrong’s import zone, which parses exercises, sets, reps, and volume into my training history. Custom foods receive macro estimates through a Claude API call routed through my own Worker endpoint. Evolt body-scan data feeds dynamic calorie and protein targets based on BMR × activity factor, minus a deficit, with hard floors instead of static numbers. The Vestibular module intentionally uses open text fields for now, so Claude and I can identify which data matters before formalizing the inputs. Everything syncs across devices through Cloudflare KV. The coaching layer uses a three-tier framework—evidence floor, confirmed operating range, and aspirational target—to drive every recommendation. Two calorie floors, a daily target of approximately 1,000–1,100 kcal and a weekly average of approximately 1,300–1,400 kcal, reflect that chronic under-eating—not missed protein—is the real GLP-1 risk. Muscle mass has remained stable since my February 2026 baseline, so the coaching treats that as a genuine win rather than a plateau. Vestibular-training coaching connects dry-needling focus areas—SCM, suboccipitals, and splenius capitis/cervicis—to gaze-stabilization symptoms, since cervical proprioception substitutes for non-functional vestibular canals. The result is one dashboard that brings together training, nutrition, body composition, vestibular symptoms, and coaching logic. My muscle mass has held stable through it all. Step-by-step: 1. I describe a feature or problem to Claude in plain language, review its structural options, choose a direction, and have Claude write the HTML, CSS, and JavaScript. 2. I use FuelStrong’s daily tracker to record meals, water, energy, and training check-ins, while the Progress and analytics module tracks body composition and related trends. 3. I program my Upper/Lower/Upper workouts in Fitbod with an arms-and-back priority and the Build Muscle goal. 4. I export Fitbod workouts as CSV and import them into FuelStrong so it can parse exercises, sets, reps, and volume into my training history. 5. I route Claude API requests for custom-food macro estimates through my own Cloudflare Worker endpoint. 6. I use Evolt body-scan data to calculate dynamic calorie and protein targets from BMR × activity factor, minus a deficit, while maintaining hard floors. 7. I log vestibular symptoms in the standalone Vestibular tracker using open text fields while Claude and I determine which inputs should eventually be formalized. 8. I sync the three apps across devices through the shared Cloudflare Worker, D1 database, and KV backend. 9. I use the evidence floor, confirmed operating range, and aspirational target framework to guide recommendations, including the daily and weekly calorie floors. 10. I connect vestibular-training coaching to dry-needling focus areas and gaze-stabilization symptoms, then use stable muscle mass since the February 2026 baseline as a positive outcome rather than treating it as a plateau.

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.

I built Timelanes so you can type any topic into one text box, such as “The Space Race” or “my grandfather's war years,” and generate a visually engaging, sourced, shareable timeline in seconds. Step-by-step: 1. Type a topic into the text box. 2. Let AI generate the timeline with dated events, short descriptions, and source links. 3. Review citation coverage for each event to see what's verified at a glance. 4. Edit and reorder events, add images and milestones, and choose a theme. 5. Publish the timeline with one click to create a shareable page and embeds that auto-render in Substack and Notion. 6. Export the timeline as a PDF, Markdown file, or CSV. Bonus: Compare mode places two or more timelines on one shared axis so overlaps stand out.

I built a model dispatcher to avoid paying premium usage for simple tasks. In Claude, every task runs on the model used by the current session, so a two-line formatting fix can consume the same level of model capacity as a difficult strategic problem. I had Claude build a scoring system that evaluates each task across six dimensions: required reasoning, the amount of context, the importance of craft or nuance, whether speed is the priority, the number of agentic parts involved, and the potential consequences if something goes wrong. Based on the score, it recommends a model—from a light, fast option for rote work to the most capable option for genuinely difficult tasks—and suggests how much effort that model should apply. The key design choice is that the dispatcher never spends anything automatically. Scoring is free and instant, while sending the task to a model through the API costs real money. Dispatching therefore requires an explicit confirmation flag every time. Nothing runs without me saying go. The payoff is not dramatic from day to day. It comes from many small savings that add up, along with a habit shift: I check the router before sending a task instead of wondering afterward why a simple request cost more than it should have. Step-by-step: 1. I identified the problem: every task in a Claude session uses the current model, even when the task is simple. 2. I had Claude build a scoring system that evaluates each task across six dimensions: reasoning, context, craft or nuance, speed, agentic complexity, and the potential consequences of failure. 3. I used the score to recommend an appropriate model, from a light and fast model for rote work to the heaviest model for genuinely difficult tasks. 4. I included a recommendation for how much effort the selected model should apply. 5. I kept scoring free and separate from dispatching, since sending a task through the API costs money. 6. I required an explicit confirmation flag before dispatching any task, so nothing runs automatically. 7. I check the router before sending tasks and benefit from small savings that accumulate over time.

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.

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 created an iPhone bookmark that looks and works like an app, using Claude. It includes massages, habits, and stretches targeting the shoulders, neck, jaw, and temples for when I feel a tension headache coming on. I took screenshots from a Gemini conversation about preventing and treating tension headaches, then uploaded them to Claude. I asked Fable to create a simple, accessible app I could use when I noticed my shoulders starting to rise or felt a headache coming on. Some stretches and massages include timers and tell me how many repetitions to do. It also reminds me to stop clenching my teeth and frowning while I’m working. Step-by-step: 1. I took screenshots from a Gemini conversation about preventing and treating tension headaches. 2. I uploaded the screenshots to Claude. 3. I asked Fable to create a simple, accessible app based on that information. 4. I saved the result as an iPhone bookmark that looks like an app. 5. I use the stretches, massages, and habits when I notice shoulder tension or a headache coming on. 6. I follow the built-in timers and repetition guidance, while using the reminders to stop clenching my teeth and frowning when I’m working.

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

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.

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.

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.

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.