Workflow Hub

I had about $2K in contributions from past jobs stuck in a government scheme for more than two years. The portal was slow, spread across several forms, and unclear about how to withdraw the money. I gave the task to Claude and Perplexity Comet. Claude worked through the rules and found the withdrawal route that kept my tax bill lowest. Comet then verified and implemented that route. It ran the portal in my browser, filled in and submitted the claim forms, and let me watch the screen and check each detail before submission. Two weeks later, the $2K arrived. After that, Claude compared the amount I received with the scheme’s online statement and found a gap: interest that had not been paid out. It filed a second form for the difference, and I’m waiting for the payment now. I’ll use the same technique to solve this for my wife too. Step-by-step: 1. I gave Claude the details of the contributions stuck in the government scheme and asked it to work through the withdrawal rules. 2. Claude identified the withdrawal route that kept my tax bill lowest. 3. I had Perplexity Comet verify and implement that route in the scheme’s browser portal. 4. Comet filled in and submitted the claim forms while I watched the screen and checked each detail before submission. 5. Two weeks later, I confirmed that the $2K had arrived. 6. I asked Claude to compare the payment with the scheme’s online statement. 7. After Claude identified unpaid interest, Comet filed a second form for the difference. I’m waiting for that payment now.

I created a system to keep records of frozen seafood orders, including PO numbers, dates, item codes, pallet quantities, pounds, cases, and lot numbers. I need to make the system more efficient. Step-by-step: 1. Record each frozen seafood order. 2. Capture the order’s PO number, date, item code, pallet quantity, pounds, cases, and lot number.

We adopted a two-year-old Yorkie Poo who was only partially pad-trained. Grok helped me create a daily crate-training schedule for taking her outside, and I asked it about every issue or question that came up. For example, I would take her outside and she would stand there staring at me. Grok explained that she might be trying to demand that we go back inside. It told me to turn my body away from her and avoid eye contact, which worked. She eventually toileted outside. Grok also explained that I could not expect her to use indoor pee pads and reliably go outside at the same time. She needed a strict reset schedule to break her old habits. I reported each issue to Grok, and it adjusted her schedule accordingly. I knew exactly when to take her out next and how long to wait for her to pee. She received treats only after eliminating outside. At the beginning, she was out of the crate for only 10 minutes of playtime three times a day. As her compliance improved, Grok increased her time outside the crate. Grok told me that its guidance drew on information from kennel clubs, top breeders, veterinarians, and others, so I felt I was getting high-quality direction. It took her 14 weeks to become reliably trained, and now she is out of the crate most of the time. Grok also rearranged her schedule when we had a party to attend. This is what one of her early schedules looked like: Step-by-step: 1. I took her on her morning walk after the bus as usual and rewarded outdoor elimination. After a short play session, I put her in the crate. 2. At 11:00 a.m., I took her out for a potty break. If she eliminated, she received 45–60 minutes of supervised time in sight or on a leash, followed by crate time. 3. At 2:00 p.m., I took her out again. If she eliminated, she received 30–45 minutes in sight or on a leash, then went into the crate by 2:45 p.m. 4. At 3:15 p.m., I gave her the evening meal. 5. Between 3:45 and 4:00 p.m., I took her outside for a potty attempt and stayed out long enough for her to try properly. I rewarded her only if she eliminated. 6. At 4:00 p.m., I put her in the crate. Water in the crate was fine. 7. If she did not eliminate during the 3:45–4:00 p.m. outing, I still put her in the crate and left for the party at 4:30 p.m. I took her outside as soon as I returned. 8. At 8:30 p.m., I took her out immediately after getting home, rewarded outdoor success, and crated her for the night. 9. I did not give her extra free time after 2:45 p.m. or leave her loose near the table while I got ready. The day was for management, not a training test. She could learn the house rules over time within this structure, but when I could not watch her, she stayed in the crate. I did not cancel the evening because of an unsuccessful potty attempt.

I built an AI fundraising campaign assistant with Make.com. The workflow reads emails sent from the crowdfunding platform used for the campaign, extracts the relevant information, and records it in a spreadsheet. It also uses spreadsheets from previous years’ campaigns to maintain a list of people who have not donated to this campaign yet but have donated in the past. I can ask the agent questions by email, such as who has already donated or who has not donated this year but donated previously. It can also answer questions with specific parameters, such as who has not donated but previously gave more than $1,000, or how much a specific person donated. I built the workflow in Make.com using its AI tools. I connected it to a Gmail account, a Google Drive account containing the spreadsheets, and a ChatGPT account that processes the information as the AI agent. Step-by-step: 1. I connected Make.com to the Gmail account that receives emails from the crowdfunding platform. 2. I configured the workflow to extract relevant information from those emails and record it in a spreadsheet. 3. I connected Google Drive so the workflow could use spreadsheets from previous years’ campaigns. 4. I used the historical spreadsheets to identify people who have not donated to the current campaign but have donated in the past. 5. I connected ChatGPT as the AI agent that processes the campaign and donor information. 6. I configured the agent to respond to questions sent by email, including who has already donated, who has not donated this year but donated previously, who previously gave more than $1,000, and how much a specific person donated.

My wife and I used ChatGPT to bring our vision for a new master bedroom to life instead of hiring a designer. We started by sketching the basic layout, which ChatGPT rendered into a floor plan. We identified the wood, the type of cut we wanted, and the finishes. Then we had a detailed conversation about what we wanted the room to look like from each side. For smaller details, we scanned Google Images and Pinterest for inspiration pictures and designs we liked. We used ChatGPT Voice for back-and-forth conversations and final tweaks, re-rendering the images as our ideas developed. We took the final images to our contractor to help him understand the higher-level vision we wanted to achieve. Step-by-step: 1. We sketched the basic layout for the new master bedroom. 2. We used ChatGPT to render the sketch into a floor plan. 3. We identified the wood, the type of cut, and the finishes we wanted. 4. We described what we wanted the room to look like from each side. 5. We scanned Google Images and Pinterest for inspiration pictures and designs. 6. We used ChatGPT Voice for back-and-forth conversations and final tweaks, re-rendering the images as needed. 7. We shared the final images with our contractor to communicate the higher-level vision for the room.

I’m 78, and I run a homestead, a home server, and a senior center, with dozens of jobs underway at once. Most jobs get done a piece at a time, while to-do apps only track whether something is “done” or “not done.” So I built Taskmaster: a plain-text ledger inside a Claude Project. I first tried building a large custom app, then scrapped it. One of my own rules is, “Build the ugly version first.” In the field, I speak notes into the Claude app on my phone. Claude saves my exact words, updates each job’s progress, and asks me one question at a time when something is unclear. When I ask, “What’s next?” it considers deadlines, weather, and my energy level, then gives me one to three things to do. Anything tied to a specific time goes on my Google Calendar. Home Assistant then reads the reminder aloud through my hearing aids. Today, it checked the forecast and scheduled my paint job for the one day this week that stays above 50°F overnight. The machine carries the complexity, so I don’t have to. Step-by-step: 1. I keep each ongoing job in a plain-text ledger inside a Claude Project. 2. When I’m in the field, I speak notes into the Claude app on my phone. 3. Claude saves my exact words, updates each job’s progress, and asks one question at a time when something is unclear. 4. When I ask, “What’s next?” Claude weighs deadlines, weather, and my energy, then gives me one to three tasks. 5. I put anything with a specific time on my Google Calendar. 6. Home Assistant reads calendar reminders aloud through my hearing aids. 7. For example, Taskmaster checked the forecast and scheduled my paint job for the one day this week that stays above 50°F overnight.

I built Able (uable.store) because I was tired of chat tabs that explain how to do a job but leave me to paste the result into PowerShell. I wanted an agent that lives on this Windows PC and can actually move files, run tools, and write code here after I approve the actions. I work on Able, so this is the workflow I run on my own machine—not a theory. The job was to organize a Downloads folder that had become a dump and make a code change without affecting the live app. Step-by-step: 1. I open Able on Windows and describe the task conversationally: “organize my Downloads — keep installers, put photos together, leave anything I’m not sure about.” 2. I review the actions Able plans to take and let it run only after I approve them. Native file moves stay on this PC and do not use cloud credits. 3. For a code task, I enter `able job:` followed by the ticket. Able creates a separate Git worktree, writes a plan, and runs `cargo check` on that copy so the live app stays unchanged. 4. I keep secrets in the local vault, Septaguard. Cloud models—Claude, Gemini, Grok, and Kimi—receive the prompt I send, not the vault password. I enter Google and Gmail logins in the masked vault UI rather than in chat. 5. I remember that the job stops if the PC is off; there is no cloud-based substitute running in the background. 6. I verify the result on this machine: the folders are sorted, and the code check either passes or fails locally. If I only needed a sentence, I would have stayed in ChatGPT. The point of this loop is that the disk actually changes. What I learned is that “agent” is cheap until it has to touch the real folder and the real compiler. Chat is the easy half; confirm-then-act on Windows is the hard half. If you already use Claude or Cursor in a tab, what is the first job on your PC you still do by hand because the model cannot touch the files?

I run an out-of-home advertising agency in Malta, covering billboards, buses, hotel screens, and radio. Our entire business ran on Monday.com boards for CRM, deals, bookings, supplier bills, and bus-campaign reconciliation. The system was expensive, difficult to change, and full of broken formulas. I’m not a developer, but in about two weeks I worked with Claude to replace it with our own CRM built on Google Sheets and Google Apps Script. The team now uses it every day. Step-by-step: 1. I mapped our real processes first, explaining in plain language how we sell, book, invoice, and pay partners. Claude read our existing Monday.com boards and imported the data. 2. I built the system screen by screen, releasing each part and testing it with live data before moving on. The CRM now includes contacts, companies, deals with order lines, bookings, billing, partners, tasks, and a dashboard. 3. I automated repetitive tasks. When I upload a signed order form, the app reads the lines. Bookings are created automatically from deals, and a Gmail side panel and shared mailbox file client emails under the correct contact or deal. 4. I connected QuickBooks Online. The system pulls invoices and supplier bills, calculates each partner’s revenue share according to its own rules, produces the monthly partner report, and creates the bill. I approve anything that writes to the accounts. 5. I turned a monthly spreadsheet chore into an automatic check for bus campaigns. The app compares what we committed to the client with what the bus operator billed us and flags overbilling or margin problems month by month. The first run found a supplier bill that appeared to be a duplicate. 6. I made the system safe to hand over. Every change is logged and can be undone, with user roles and a shared drive in place. We also wrote a short user guide and test checklist before the team started using it. The main lesson I learned was to treat AI like a capable builder who needs your business rules spelled out. Starting with real data, releasing small pieces, and checking each one before adding the next made the build manageable. The tools I used were Claude, Google Sheets, Google Apps Script, Gmail, and QuickBooks Online.

I created a media player for Android Automotive OS—not to be confused with Android Auto. I had been using an old, unmaintained app that lacked several features I wanted in a music player. I used Claude Code to build a new app from scratch, test it in an emulator, and eventually publish it for internal testing through the Google Play Store. After working through several bugs, I now have version 3 running reliably enough for day-to-day use in my car. I plan to add a few more features before ultimately releasing it publicly for free on the Play Store. Step-by-step: 1. I pointed Claude Code to the unmaintained package and gave it the option of using that as a starting point or starting from scratch. Claude chose to start from scratch. 2. I described the additional features I wanted. Claude suggested using Kotlin and Gradle, which I endorsed. 3. Claude created an initial build and installed an emulator to run alongside it. I did all of this on an Omarchy installation. 4. The initial build was buggy, so Claude and I worked together to identify and fix the problems. Claude often used the emulator autonomously to investigate what was going wrong. 5. Once I had a functional prototype, I needed to install it in my car. Claude guided me through creating a Google developer account and handling the administrative requirements beyond the app itself, including a privacy policy. 6. After the developer account was set up, Claude packaged the app for upload. I uploaded it and marked it for internal testing, which allowed me to access the app through the Play Store in my car. 7. Claude and I worked through a few more bugs. We are now on version 3, and the app is functional for day-to-day use. We plan to add more features, with the ultimate goal of releasing it publicly for free on the Play Store.

We’re narrowing down high school options for my daughter, who wants to focus on art. I’m using Astra to find public schools in our area and beyond with strong art programs and understand how they compare. Astra can research school rankings and academic results, review art courses and facilities, and bring admissions requirements, portfolio expectations, fees, and commute times into one clear comparison. It can also suggest preparation classes—such as drawing, painting, digital art, or portfolio workshops—based on what each school expects. From there, it’s helping me build a shortlist, organize open days and application deadlines, and prepare questions for school visits. We can work through the options together and find a school she’s excited about. Step-by-step: 1. I use Astra to find public schools in our area and beyond that have strong art programs. 2. I ask Astra to research each school’s rankings, academic results, art courses, and facilities. 3. I bring admissions requirements, portfolio expectations, fees, and commute times into one comparison. 4. I use each school’s expectations to identify helpful preparation classes, such as drawing, painting, digital art, or portfolio workshops. 5. I use the comparison to build a shortlist and organize open days and application deadlines. 6. I prepare questions for school visits so my daughter and I can work through the options together.

I built a Custom GPT Prompt Engineer to make the build phase more efficient. Instead of generating a result immediately, it helps transform ideas, business requirements, and objectives into production-grade ChatGPT prompts. The assistant is coached to operate as an expert prompt engineering partner. Its primary mission is to help produce consistently accurate, thorough, and useful results from ChatGPT. Its seven core responsibilities are: Step-by-step: 1. Understand the objective before writing by asking targeted clarification questions. 2. Ask questions one at a time instead of overwhelming the user with a questionnaire. 3. Never assume missing information; ask for clarification when something is unclear rather than inventing details. 4. Engineer structured, high-quality prompts that include: - Role assignment - Task and objective - Relevant context - Detailed instructions - Expected output format - Constraints and guardrails - Examples when beneficial 5. Minimize hallucinations by instructing ChatGPT to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Deliver enterprise-ready prompts that are professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Validate and refine each prompt by checking its completeness, ambiguity, consistency, and alignment with the requirements, then refine it based on feedback. The key difference is that the assistant engineers the instructions that produce the result rather than simply generating the result itself. For example, if I say, “I want ChatGPT to analyze my business and identify growth opportunities,” it does not immediately generate a generic business analysis. Instead, it helps construct a reusable prompt that specifies how ChatGPT should perform the analysis, what evidence it should use, what questions it should ask, and how it should present its findings. Its governing principle is: Clarity + Context + Constraints + Structure + Verification = A stronger prompt. The operating instructions also direct it to reference the Custom GPT Prompt Engineer – System Prompt document and check its work against that document’s guidelines. Ultimately, it is designed to be a prompt engineering partner for business strategy, marketing, finance, operations, research, analytics, and other professional applications. I built it to bring more efficiency to the build phase and am continuing to look for opportunities to improve it. Step-by-step: 1. Create a Custom GPT and position it as an expert Prompt Engineering Assistant. 2. Instruct it to understand the user’s objective by asking targeted questions one at a time. 3. Tell it never to assume missing information or invent details. 4. Require each completed prompt to include a role, task and objective, context, detailed instructions, output format, constraints and guardrails, and examples when beneficial. 5. Instruct it to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Set the delivery standards: professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Have it validate each prompt for completeness, ambiguity, consistency, and alignment with the user’s requirements. 8. Direct it to reference the Custom GPT Prompt Engineer – System Prompt document and use its guidelines when checking and refining its work.

I 3D-printed a custom threaded barrel nut without ever opening AutoCAD. I use my 3D printer to make parts for various projects, including a pinball machine and a boat, but I struggle with AutoCAD. As an alternative, I described the part to Claude in plain English and asked it to create a `.3mf` file. I opened the file in Bambu Studio and printed the part without using AutoCAD. Step-by-step: 1. I described the custom threaded barrel nut to Claude in plain English. 2. I asked Claude to create a `.3mf` file for the part. 3. I opened the file in Bambu Studio. 4. I printed the part on my 3D printer.

Every Friday, I inspect random parts of my company the way a factory owner walks the floor: looking for errors, slow processes, and handoffs that shouldn’t exist. The inspection takes 30–60 minutes, but the preparation used to take longer—choosing what to check, finding the right links, and remembering what I flagged the previous week. I turned the entire preparation process into one scheduled Claude task. It runs before I wake up on Fridays, builds the full inspection report in Notion, verifies whether last week’s findings were resolved by checking Slack for evidence, and sends me the link by DM. I arrive to a finished briefing and focus only on judgment. You need Claude with scheduled tasks, plus Notion (or your company’s notes page) and Slack connected. If you use different tools, the prompt can be adapted; the structure is what matters. Step-by-step: 1. Create a page or database in Notion where the weekly reports will live. 2. In Claude, create a new scheduled task, set it to run early Friday morning in your time zone, and paste the prompt below. 3. Replace every bracketed section with your own details. 4. Customize the checklist and wildcard pool for your business. Mine is built for a media company; yours might inspect deployments, client deliverables, or a sales pipeline. 5. Run the task once immediately to identify configuration issues before relying on it on Friday. I use this prompt: ```text You are preparing [your name]’s weekly Digital Factory Inspection report. Context: [your name] runs [your company — one line on what it is and team size]. Every Friday they “walk the factory floor” digitally: inspecting parts of the company looking for errors, slow processes, unnecessary handoffs, and automation opportunities. Your job is to prepare the inspection report in advance so their 30-60 minutes is pure judgment, not gathering. You prepare; they inspect and decide. All reports live in [link to your Notion inspections database or page]. Do not create pages anywhere else. Steps: Read the most recent report. Collect: (a) any findings not clearly marked resolved, and (b) which wildcard areas were used in the last two reports. Create this week’s report as a new entry there, dated today, matching the existing format. Build the content in this order: A. “Follow-ups from last week”: every unresolved finding, each with its owner and a status check — search Slack public channels for evidence it was addressed and mark it “looks resolved”, “no activity found”, or “unclear”. If none, write “No open follow-ups.” B. The standard checklist — include ALL of these every week. Under each: random samples with direct links, 3-5 recent data points you can actually reach, and 2-3 sharp inspection questions: What is slow here? Which handoffs could disappear? What should be automated? What would make this 10 percent better this month? Where something sits behind a login you don’t have, do not attempt access — link it and list what to look for. Randomize sample picks genuinely, and never reuse a specific sample from the previous two reports. [Your standard areas — mine: 3 random published pieces of content, 3 random newsletters, 3 random social posts, ad performance, growth dashboards and funnels, product dev work, live events/workshops, community activity, the team’s weekly reports] C. “Wildcards this week”: pick exactly 2 at random from this pool, never repeating either of the last two weeks’ picks: [Your wildcard pool — mine: random customer support conversations, the public sign-up flow walked as a new user, one specific finance item to verify, one email automation sequence, ads on a secondary channel, one random SOP compared against how the team actually works now, one recent client/sponsor deliverable] D. “Notes \u0026 findings”: empty except the line “[Your name] fills this in during inspection — tag each finding with an owner and Open/Resolved.” E. “Wildcards used”: list the 2 wildcard names, for future rotation. Send [your name] a Slack DM (member ID [find yours in your Slack profile menu]) with the report link, the count of open follow-ups, and the 2 wildcards. Nothing else. Hard rules: this report contains candid internal assessments — the DM goes ONLY to [your name], never to any channel, and you never message anyone else. Read-only everywhere except the one report you create and the single DM. Do not reply to emails, do not post, do not modify existing pages. If Notion is unreachable, send the full report as the DM. If Slack is unreachable, still create the report. If both fail, do nothing. ``` The follow-up section is the whole point. I keep the workflow read-only: the agent gathers and drafts, but it never messages my team or touches live systems. Any feedback after the inspection comes from me, in my own words. Randomness is a feature, not laziness.

I’ve been experimenting with agentic coding for quite some time, and I’ve noticed that the tasks I let the agent handle keep getting bigger. For larger tasks and projects, I gradually moved to a standard workflow, which I published at https://github.com/evermeer/CodingAgentOrchestration in part 2 of the tutorial. I use this workflow professionally and in my side projects. My most recent side project is Quadrim, a Four in a row game played in a 4×4×4 cube. I made it open source and included all the prompts for both the code and the artwork: https://github.com/evermeer/Quadrim It took me about eight working days to publish the first version to the app stores. Step-by-step: 1. I start by describing the idea. 2. I brainstorm the idea with the agent. 3. I use `to-spec` to create a specification document for the idea. 4. I use `to-ticket` to create independent, executable tasks. 5. I review the specifications and tickets from the perspectives of a senior software engineer, architect, security officer, and product manager. 6. I implement one ticket at a time. 7. I code-review the generated implementation for each ticket. During the pre-implementation steps, I always add this instruction to my prompt: “Ask clarifying questions until any ambiguities are resolved.” Extra fine-tuning of the idea, specifications, or plan pays off during implementation. When I let the agent build code, I ask it to use TDD, perform a code review at the end, and resolve the major and critical findings.

Trivet is a recipe box for one household. I can photograph a recipe card—handwritten, printed, or a PDF—and get back a structured recipe with ingredients, quantities and units, numbered steps, prep, cook and rest times, oven temperature, and equipment. I can plan a dinner for each night of the week, and the shopping list builds itself: quantities are combined across meals, grouped by aisle, and texted to my phone. I built it because my family’s recipes were scattered across index cards in a drawer, including decades-old handwriting and cards from defunct meal services. Typing everything in was never going to happen. The entire AI workflow uses one model call. The photo is sent to Claude Opus as an image block with a Zod schema attached as the structured output format, so the response is already typed and validated—there’s no JSON parsing, retry loop, or “please respond only with valid JSON.” The extraction schema is intentionally looser than the database schema, with nullable numbers throughout. If a card has no cook time, the model returns `null` instead of inventing a plausible-looking value. The load-bearing instruction in the system prompt is that a missing cook time is a small gap, while an invented one is wrong every time somebody cooks from it. Nothing saves automatically. The extraction first appears in an editable review screen. The model also returns a confidence field, so a blurry card or a page that is not a recipe gets flagged instead of silently becoming a bad entry. Step-by-step: 1. I built a Next.js app with Postgres via Prisma and deployed it on Vercel. 2. I made the upload accept an image or PDF. I check the file size before encoding because the API limit applies to base64, which inflates the bytes by about a third; a 7 MB raw ceiling is the real limit. 3. I defined the extraction shape in Zod and sent it as the output format instead of describing JSON in the prompt. 4. I described fields in the schema. For example, `.describe("Unit as written, e.g. 'tbsp'")` does more than a paragraph of instruction. 5. I render the result into a review form and save it only when the form is submitted, never immediately after the model responds. 6. I store quantities as numbers with separate units so servings can be scaled and ingredients can be combined across recipes later. This is the decision that cannot be retrofitted easily. 7. I sum ingredients across planned meals, round at the end, group them by aisle, and send the list via Twilio. The pattern is not limited to recipes. Anything I would otherwise have to retype—receipts, notes, or forms—can use the same three moves: a schema looser than the database, a model told that `null` is better than a guess, and a review screen between the response and the database write.

Several months ago, my dad was in and out of the hospital. My two brothers and I were trying to coordinate his doctor appointments, manage his medications and potential interactions, and keep track of all the other details involved in his care. At one point, up to seven different doctors were seeing him in the hospital on any given day. It became important to track every medication he was taking, what each one was for, and information such as his weight and other vital statistics. When he returned home, we also had to make sure someone checked on him and his wife every day, helped him stay on schedule with his medications, and recorded his diet, mood, and weight. We initially used Apple Notes, a shared iCalendar, multiple text threads, and a weekly call between the three of us. The mental load was huge. If we needed to find information from the previous week, we had to scroll through pages of Apple Notes to locate it. We also struggled to keep the rest of the family updated. Before my dad passed away, I started using Claude Code and Codex to build a simple tool that would keep everything organized and searchable. It also displayed trends in areas such as his mood, appetite, and vital signs, and included a calendar showing who was covering which days and times. The tool was still fairly basic when he passed away. Afterward, we encountered the administrative headaches involved in closing out his estate. It was far more complicated than we expected. We thought having a will, power of attorney, and other documents meant we were prepared, but we were wrong. I began integrating those lessons—and the things we learned not to do—into the final product, Eldercare Log: eldercarelog.com. I built the final tool with Claude helping draft a PRD, which I then handed to Codex for the coding work. It took a few weeks of refining the product with Codex. The tool is hosted on Vercel, with Supabase and Stripe on the backend, and includes the security features I built into it. It is the tool I wish had existed when my brothers and I were going through this journey before my dad’s passing. Step-by-step: 1. I coordinated my dad’s doctor appointments, medications, vital statistics, and other care details with my two brothers while he was in and out of the hospital. 2. We tracked his medications, their purposes, his weight, diet, mood, appetite, and other vital signs while he was at home. 3. We coordinated daily visits and coverage using Apple Notes, a shared iCalendar, text threads, and a weekly call. 4. I used Claude Code and Codex to start building a searchable tool that organized his care information and showed simple trends. 5. I added a calendar to track which family member was covering each day and time. 6. After my dad passed away, I incorporated what we learned from handling his estate, including the things we wished we had known earlier. 7. I used Claude to draft a PRD, then gave it to Codex to handle the coding work and refined the product with Codex over several weeks. 8. I built the final tool with Vercel, Supabase, and Stripe on the backend.

I built a website that turns property photos, architectural renderings, or even just an address into cinematic property videos. I’m a civil engineer and photographer/videographer, not a software developer, so I used ChatGPT, Gemini, and Claude Code to help build the site and work through problems as they came up. Much of the process involved translating the way I would personally edit a real estate video into usable software. For example, kitchen and living room shots should usually stay together and have longer durations, bedrooms should stay near their bathrooms, an opening shot should feel different from a detail shot, and every clip should include some movement so the result does not feel like a generic slideshow. I used AI to turn those editing principles into actual logic for the site. The system analyzes and organizes the images, builds a storyboard, ranks scenes to decide which ones to use, creates prompts for video models, generates the clips, and assembles everything into a finished video. Most of the development has been iterative. I test the site with real properties I’ve shot, watch the results, identify what feels off, and then improve the prompts, scene planning, timing, or video assembly process. AI has been useful for much more than generating the final video. I’ve also used it to write code, troubleshoot errors, plan features, improve the user experience, and think through how the product should work from the perspective of its primary user. Step-by-step: 1. I defined the video-editing principles I use for real estate footage, including grouping related rooms, varying shot durations, distinguishing opening shots from detail shots, and adding movement to every clip. 2. I used ChatGPT, Gemini, and Claude Code to translate those principles into software logic. 3. I built the site to accept property photos, architectural renderings, or an address as input. 4. I had the system analyze and organize the images, build a storyboard, rank scenes, and select the footage to use. 5. I used AI to create prompts for video models and generate the clips. 6. I assembled the generated clips into a finished property video. 7. I tested the site with real properties I had shot, reviewed the results, and iteratively improved the prompts, scene planning, timing, and video assembly. 8. I used AI throughout development to write code, troubleshoot errors, plan features, improve the user experience, and think through the product from the primary user’s perspective.

I built a workflow that turned a single plain-English idea into a live, 24/7 crypto trading bot without being a developer. Claude handled the engineering; I made the decisions. Step-by-step: 1. I gave Claude the goal rather than detailed instructions. My first message was roughly: "Create me a trading bot that runs 24/7, makes faster decisions than a human, takes calculated risks, picks the lowest-fee platform, and has a dashboard with profit graphs. Make it your own." Claude designed the whole system and named it Kestrel. 2. Claude explained the setup options, including exchanges versus on-chain trading, laptop versus cloud hosting, and minimum funds. I chose BNB Chain and PancakeSwap, using a brand-new MetaMask wallet dedicated to the bot so it can never touch my other funds. 3. I let Claude build and test the bot. It wrote the strategy—holding good coins in healthy markets and moving to stablecoins in bear markets—along with hard safety limits, including a daily loss cap, emergency brake, and trailing stops. It also built cheapest-route swap selection and automated tests. When the backtests did not clear the bar we had agreed on, Claude told me honestly instead of curve-fitting. 4. Claude walked me through deploying the bot by renting a cloud server, running it in Docker, and locking the server down with Tailscale and a firewall so nothing was exposed to the internet. I only copied commands and sent screenshots when I got stuck. 5. I went live with a small amount and used a private phone dashboard showing the balance, trades, the bot’s reasoning, and Pause and Sell-everything buttons. 6. I kept improving the system through conversation. I added a “strategy league,” where 10 strategies trade on paper and can be promoted only with my approval, along with self-healing, backups, and one-tap sharing of wins and losses to X. My biggest lesson was to talk to Claude like a capable coworker: give it the goal, make the key calls yourself, and ask it to be honest about the risks.

“Honey, do you remember where Ryan’s practice is? Do you remember our Wi-Fi password? Do you know my TSA PRE number? Remember who that painter was that we used last year?” If you have a family with children, you may hear questions like these all the time. In a large family, there always seem to be questions about the house, the kids, or technology that could be answered more easily. The information is usually stored in different places: password files, a Rolodex of business cards, or sheets of paper in junk drawers. I set out to build an app where anyone in my family could use voice to save something for the future or retrieve something they had already stored. I integrated AI to understand the meaning of each voice note. It might create a calendar event, store a password in a vault, or simply remember a phone number. Then anyone else in the family could access the information. The app uses multi-factor authentication for anything particularly secret. It is not intended to be a dedicated password protector; I would build in much more security if that were the goal. Instead, it is an everyday-life app for remembering the little things: How long is the warranty on this appliance? Which exact light bulbs did we use here last time? What was our daughter’s email address that we needed to set up on her phone? Being able to use voice to enter information or retrieve it was the key for me. I think that will save people time. As I started adding entries and validating the idea, my wife came up with the name. After a few weeks, I knew she was completely right, because I now use it about 10 times a day—and I hear that exact phrase every time. Step-by-step: 1. I identified recurring family questions about locations, passwords, identification numbers, contacts, warranties, and household items. 2. I built an app that lets family members use voice to save or retrieve information. 3. I integrated AI to interpret the meaning of each voice note and determine whether to create a calendar event, store a password in a vault, or remember a phone number. 4. I made the stored information accessible to other family members. 5. I added multi-factor authentication for information that is particularly secret, while keeping the app focused on everyday memory rather than dedicated password protection. 6. I added entries and validated the idea through regular use, eventually using the app about 10 times a day.