Workflow Hub

I built a module that runs in MagicMirror on a Raspberry Pi and displays a real-time to-do list on a television in my office. Claude does an admirable job managing my daily task list, which is stored in `TASKS.md` on my local computer. I wanted an at-a-glance dashboard showing everything I have in progress, sorted by priority and synchronized with that file. I described the goal to Claude Code. Since I already had an old Raspberry Pi 3 and an off-the-shelf widescreen TV in my office, Claude Code suggested running MagicMirror on the Pi and Syncthing on both the Pi and my local computer to keep the file updated. Claude then built the MagicMirror module to read `TASKS.md`. After a few tweaks to remove the default modules and clean up the spacing between items, the display was up and running. I set MagicMirror to start automatically when the Pi boots, so now my to-do list is in front of me all day. Step-by-step: 1. I identified the need for a real-time, at-a-glance view of my prioritized tasks, which were stored in `TASKS.md` on my local computer. 2. I described the goal to Claude Code and told it about the Raspberry Pi 3 and widescreen TV I already had in my office. 3. I followed Claude Code’s suggestion to run MagicMirror on the Pi and Syncthing on both the Pi and my local computer. 4. Claude built a MagicMirror module that reads `TASKS.md`. 5. I removed the default MagicMirror modules and adjusted the spacing between items on the screen. 6. I configured MagicMirror to start automatically when the Raspberry Pi boots.

I built Lumi, an HR assistant in French, with Claude Code in about two hours. It was an experiment: could Claude Code build a working product from a plain brief while being left completely alone? Employees ask questions, and Lumi answers using their company’s own HR documents. Each company has its own space, and HR can see which questions the documents couldn’t answer. Step-by-step: 1. I set up one window with Claude Code on one side and the files appearing on the other. I didn’t write code, but I could always see what was being built. 2. I described the product in plain language. I dictated my brief out loud, typos included: who pays, who uses it, the problem, a demo client, keeping clients separate, the admin view, the language, and the price. 3. I let Claude Code build the product and make every call. Thirty-four minutes later, the first version had 47 files and 3,949 lines. It even invented a fictional client company with a full HR handbook so I could demo it immediately. 4. I put the product online. Claude Code wrote a setup guide for Supabase and Vercel. I followed it one step at a time and sent a screenshot whenever something broke. 5. I improved it with feedback. I told Claude Code that the design looked like it had been created by a junior designer. Eighteen minutes later, it came back with a name, a design system, pricing plans, and everything in French. 6. I checked security, although I had skipped this during the build. When I asked for a full security review eleven weeks later, it took less than six minutes and found three serious problems, including a database function that allowed anyone to read a company’s documents. Claude Code fixed all three. Run `/security-review` before sharing the link and before each new change. The full write-up, including the unedited prompts: https://www.theaithinker.com/p/how-to-build-a-saas-product-with

In my ongoing mission to go paperless, I created a web app that runs on tablets and replaces paper sign-in sheets. The admin console gives HR instant visibility and detailed reporting on employee and guest attendance across all our branches from a single pane of glass. In Phase 2, I’m expanding the app to eliminate even more paperwork by allowing employees and managers to request, approve, and manage PTO. Department calendars show everyone’s PTO balance and minimum coverage requirements. Step-by-step: 1. I created a web app that runs on tablets to replace paper sign-in sheets. 2. I added an admin console so HR can view and report on employee and guest attendance across all branches. 3. In Phase 2, I expanded the app to support employee and manager PTO requests, approvals, and management. 4. I added department calendars showing PTO balances and minimum coverage requirements.

I built a workflow for creating a living book that exists online and that I can add to, edit, and share whenever I like. I’m an occasional writer who publishes nonfiction essays about observations in life. I realized I could collect the essays into a book, but life doesn’t take an appropriate pause, so the book and the essays never really end. That raised the question: When should I publish it? I created a local Claude instance to access all the files on my laptop. Local is almost always better than a cloud instance, and you can ask Claude to enable remote control so you can access it from your phone as well. I used Opus 5.5 because I couldn’t be bothered experimenting with lower-level models to see whether they could do the task more cheaply. A friend who uses Claude professionally once told me to always use the highest model available and move down if I ran into usage limits. I’m on the monthly Pro plan. I gave Claude the locations of my existing writing on Substack and Medium.com. It downloaded all my essays and organized them into rough sections. I argued with it about the organization and approved the sections once it explained its logic. I then had Claude create a Ulysses folder for all my essays, organized into sections and chapters. I can use it to create a new essay, edit an old one, or reorganize and reorder the book, then tell Claude to update the online version. I could have had it scan the folder regularly and update the site automatically, but that seemed unnecessarily lazy. Claude created a section of a website I already owned where readers can access the living book: https://enwaken.com/read/ During the process, I also had Claude restructure and redesign my overall website several times. It’s amazing at that sort of task. I’m still amazed that I can say something like "I want blue and violet and black, but maximize the contrast between each of the colours" and it will actually pick colors that complement each other. I wish more website designers knew they could do this. Now I have a version of my book that is spectacularly easy to read online and that I can update whenever I like. It’s easier to navigate than an ePub on my Kindle and certainly easier to update. The whole process took two days, half of which was spent arguing about the organization of the chapters. Step-by-step: 1. I set up a local Claude instance with access to the writing files on my laptop and enabled remote control so I could access it from my phone. 2. I used Claude Opus 5.5 through the monthly Pro plan. 3. I gave Claude the locations of my existing essays on Substack and Medium.com and had it download them. 4. I reviewed Claude’s rough organization of the essays into sections, argued about its choices, and approved the structure once it explained its logic. 5. I had Claude create a Ulysses folder organized into sections and chapters so I could add, edit, and reorder essays. 6. I told Claude to update the online book when I changed the Ulysses folder. 7. I had Claude create the book as a section of my existing website and redesign the site as needed. 8. I now maintain a living online book that is easy to read, share, and update.

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

I made an orchestration skill to help me build faster while using my expensive Astra and Fable tokens carefully. The skill plugs into Astra or Fable and delegates tasks that can happen in parallel to multiple subagents running cheaper models suited to the work. This is especially useful for researching or finding data on the web or on my computer, analyzing code, collecting context, and indexing. The most expensive, newest models focus on maintaining delegation control, doing the difficult reasoning and strategic planning, and judging whether everything is coming together correctly. The cheaper agents handle the lighter-weight work, especially implementing code from the plans. The core idea is simple: the expensive model plans, briefs, and judges; cheaper agents do the reading and building. When I ask Claude or GPT to build the skill, I specify five things: Step-by-step: 1. I define a triage ladder: work can happen inline, with one agent, through a parallel fan-out, or in a multi-stage workflow. I choose the approach based on the task shape and include examples from my domain. 2. I define parallel versus sequential execution based on data dependencies. Independent pieces run in parallel, while anything that needs another piece’s output runs afterward. I never split one change into separate planner, coder, and tester roles. 3. I define model routing with a mandatory model pin: judgment work goes to the mid-tier model, mechanical bulk work goes to the cheap model, and every agent call names its model so nothing silently uses premium billing. 4. I define a brief template and a return-envelope cap. Every delegation includes the goal, inputs, output file path, definition of done, and constraints. Every agent returns a 250-word summary instead of raw files. 5. I define a cost gate with specific numbers. Below N agents, the workflow proceeds automatically; above N agents, it states the estimate and waits for approval.

I build an office platform for small nonprofits, and every week users ask how to do something. I also keep changing features they have already learned, so written instructions go stale quickly. Screen recordings take an afternoon each and can be out of date by Friday. I use Claude Code in my project to turn each user question into both a software change and a how-to video. The video runs against a throwaway copy of the app filled with a made-up organization, so no real data appears on screen. It performs the task as a person would—clicking, typing, and waiting—while displaying captions one step at a time and moving a yellow pointer to each button before clicking it. There is no voice. I tried narration but dropped it because captions can be paused and read, and they never mispronounce anything. The important part is that the script also tests what it films. After each step, it confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, there is no video yet; I fix the bug first. In one day, the videos found four real defects that our automated tests had missed, so the video is also the test. `ffmpeg` turns the recording into an MP4 and a poster image. I watch and approve the result, then publish it on our videos page and inside the app’s Help box, next to the instructions for that screen. When the screen changes, I run the same script again and get a new video in minutes. The first videos were too fast. I am not as fast as Claude, and the person watching is trying to learn something new. Now each caption stays on screen long enough to read—about 1.5 seconds plus a third of a second per word—before the next click. The workflow produced 35 how-to videos in five days, most of them one to three minutes long. The checking in step 4 started on day four, after the videos kept finding problems. Every video since then has checked itself. Step-by-step: 1. I take a user’s email question or request and use Claude Code in my project to make the requested software change. 2. In the same session, I have Claude write a short script for a how-to video of the task. 3. The script starts a throwaway copy of the app, fills it with a made-up organization, and performs the task by clicking, typing, and waiting. 4. The script displays captions one step at a time and moves a yellow pointer to each button before clicking it. I use captions instead of narration so viewers can pause and read them without hearing mispronunciations. 5. After each step, the script confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, I fix the bug before producing the video. 6. I use `ffmpeg` to create an MP4 and a poster image from the recording. 7. I watch and approve the video, then publish it on our videos page and in the app’s Help box next to the relevant screen instructions. 8. When the screen changes, I run the same script again to create an updated video in minutes. 9. I keep each caption on screen for about 1.5 seconds plus a third of a second per word before the next click.

Start with the property, not a generic landscaping template. Upload photos, measurements, site constraints, current problems, future plans, budget limits, and the look you want. Then use AI to build a complete picture of how the property functions today and how it should evolve over time. Next, work area by area. For overcrowded garden beds, map every tree and shrub, then assess mature size, spacing, health, irrigation coverage, sightlines, and maintenance demands. From there, use AI to determine what should stay, what should move, what should be removed, and how each bed should be reshaped and edged. Convert each recommendation into an execution plan that includes: Step-by-step: 1. The target design 2. A step-by-step build sequence 3. Required materials and tools 4. Budget and priority level 5. Seasonal timing 6. A year-by-year maintenance plan Finally, connect every individual project into one master roadmap. Plan the garden beds, trees, lawn, irrigation, drainage, driveway, shelterbelts, recreation areas, and future buildings together so one improvement does not create a problem somewhere else. The result is a living property operating system. Add a new photo, issue, or idea, and the plan updates with the next best action.

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.

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.

I built a daily literature quiz game from a spreadsheet containing thousands of classic literature quotes, which I previously posted on Instagram each day. I uploaded the document to Claude Code, which organized and tagged the quotes, created multiple-choice questions with increasing difficulty, and wrote short summaries of each book along with a fun fact supported by academic sources. I also vibe-coded the game’s UI/UX in a day or two, and I think it looks pretty beautiful. You can play it at play.writt.org. Step-by-step: 1. I collected thousands of classic literature quotes in a spreadsheet and posted them on Instagram each day. 2. I uploaded the document to Claude Code. 3. Claude Code organized and tagged the quotes. 4. Claude Code created multiple-choice questions with increasing difficulty. 5. Claude Code wrote short summaries of each book and a fun fact with academic sources. 6. I vibe-coded the game’s UI/UX in a day or two. 7. I published the game at play.writt.org.

Instead of relying on a single AI chat, I structure the work as an executive team of specialist perspectives. I define the problem, assign roles such as CTO, product leader, economist, marketer, and skeptic, and have each expert analyze it independently. Then I run several rounds of critique so they can challenge one another’s assumptions before synthesizing their areas of agreement and disagreement. The process ends with a recommendation that includes the rationale and any remaining uncertainties. Step-by-step: 1. Define the problem clearly. 2. Assign specialist roles, such as CTO, product leader, economist, marketer, and skeptic. 3. Have each expert analyze the problem independently. 4. Run several rounds of critique in which the experts challenge one another’s assumptions. 5. Synthesize the areas of agreement and disagreement. 6. Produce a final recommendation with its rationale and remaining uncertainties.

AI is good at generating polished answers, but polished answers are not always your answers. When people ask AI for help with writing, strategy, or difficult decisions, it can jump too quickly to a conclusion and fill in beliefs the user has not fully examined. I created a thought-partner agent that interviews me before producing recommendations or drafts. Its job is to ask probing questions, challenge weak assumptions, surface contradictions, and separate my actual views from ideas suggested by the AI. Instead of writing for me immediately, it helps me clarify my position first. Step-by-step: 1. I give the agent the topic, decision, or idea I want to explore. 2. I tell it not to draft the final output yet. Its first job is to interview me. 3. I have it ask one focused question at a time about my reasoning, evidence, assumptions, audience, and uncertainty. 4. I require it to challenge vague claims and point out contradictions or overlap with my previous thinking. 5. I ask it to clearly separate: - conclusions I stated - ideas the AI proposed - issues that remain unresolved 6. I continue until the central belief, argument, or decision becomes clear. 7. I have the agent create a structured synthesis containing the core thesis, supporting reasoning, counterarguments, open questions, and useful language from the discussion. 8. I pass that synthesis to a writing, planning, or execution agent. I end up with a position that reflects my actual thinking rather than a plausible answer generated by AI. The final writing or strategy is more original, more consistent, and easier for downstream agents to execute.

I used Claude to review the book *Why Machines Learn*. Then I went through each chapter while Claude questioned me at relevant points. To make the concepts more concrete, I used interactive graphs with x and y axes. The first graph shows the relationship between x and a function, along with the slope of the curve. It uses f(x) = x³ with a tangent line illustrating the derivative. I can drag a slider to move the point and watch the slope change, then switch to 3x to compare it with a straight line. The graph demonstrates several ideas: - Sliding x to 0 on x³ makes the tangent flat and the slope 0, so a small nudge barely changes the output. This is similar to a flat spot at the ends of a sigmoid, where learning stalls. - Sliding to 2 and then to −2 shows a slope of 12 at both points. Because the derivative is 3x², it is positive on both sides and the curve is always climbing. - Switching to 3x makes the tangent lie directly on top of the line, with a constant slope of 3 everywhere. - The nudge-check box tracks the derivative closely, showing that the derivative is essentially “change in output ÷ small change in input.” The second graph shows the input and output layers of a small pattern detector. It represents a 2 × 2 image flattened into four inputs, a hidden layer of two neurons, and two outputs. The weights are set by hand so the network can distinguish a vertical line from a horizontal one. I can click the pixels to change the image and watch the numbers flow through the network. The setup uses weight +1, weight −1, ReLU activation defined as max(0, z), softmax output, and all biases set to 0. For example: - Flatten: x = [1, 0, 1, 0] - h1 = ReLU((1)(1) + (-1)(0) + (1)(1) + (-1)(0)) = ReLU(2) = 2 — left column versus right column - h2 = ReLU((1)(1) + (1)(0) + (-1)(1) + (-1)(0)) = ReLU(0) = 0 — top row versus bottom row - Output: scores (2, 0) → softmax → Vertical 88%, Horizontal 12% The graph includes examples for a left vertical line, top horizontal line, right vertical line, and diagonal. Seeing the numbers change as the factors change really helps bring these concepts to life for me. Step-by-step: 1. I used Claude to review *Why Machines Learn* and question me as I worked through each chapter. 2. I used an interactive x-and-y graph to explore how a function changes and how its slope relates to the derivative. 3. I moved the slider across f(x) = x³, including 0, 2, and −2, to observe how the tangent and slope changed. 4. I switched the graph to 3x and used the nudge-check box to compare a constant derivative with the changing derivative of x³. 5. I explored a second interactive diagram representing a 2 × 2 image, four inputs, two hidden neurons, and two outputs. 6. I clicked different pixels and watched the ReLU activations, output scores, and softmax predictions change for vertical, horizontal, and diagonal patterns.

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.

Granola transcribes my one-on-ones with my boss. I use its API and an HTML dashboard to automatically ingest and categorize the conversations. A scheduled task and skill then process them into a “wiki.” In a custom project, I can ask how my boss would respond to a question. The results are scary good. Step-by-step: 1. I use Granola to transcribe my one-on-ones with my boss. 2. I use the API and an HTML dashboard to ingest and categorize the conversations automatically. 3. A scheduled task and skill process the one-on-ones into a “wiki.” 4. I ask a custom project how my boss would respond to a question.

Most people use AI as a single general-purpose assistant. The problem is that every new conversation starts from scratch, while one AI constantly switches between roles such as researcher, writer, programmer, strategist, and editor. This often leads to inconsistent results and repeated prompting. Instead, I built a team of specialized AI agents, each with a single responsibility. By giving every agent a clear role, instructions, and context, I created reusable experts that become more consistent over time. Step-by-step: 1. I identified the different roles I needed, including researcher, writer, programmer, strategist, and editor. 2. I assigned each AI agent a single responsibility instead of asking one general-purpose assistant to handle every role. 3. I gave each agent a clear role, instructions, and relevant context. 4. I reused these specialized agents instead of starting every conversation from scratch.