Workflow Hub

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

Commercial vehicle maintenance information is often fragmented across driver reports, warning lights, fault codes, inspections, repair records, and vehicle history. This makes it difficult for smaller fleets to decide whether a vehicle can continue operating, requires scheduled repair, or should be stopped immediately. We built TruckFixr Fleet AI to turn an unstructured driver report into a clear, reviewable maintenance action. The workflow begins when a driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. The report is then evaluated alongside available vehicle history and previous repairs. The workflow provides decision support through three practical actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. Final safety decisions remain with authorized fleet or maintenance personnel. After an inspection or repair, the confirmed cause, work performed, and outcome are recorded, creating a more complete vehicle history for future cases. The general workflow can be recreated using a mobile form, OCR, a vehicle-history database, an AI model, automation software, and a human-review dashboard. Step-by-step: 1. A driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. 2. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. 3. The workflow compares the report with available vehicle history and previous repairs. 4. The system provides one of three decision-support actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. 5. Authorized fleet or maintenance personnel make the final safety decision. 6. After inspection or repair, the confirmed cause, work performed, and outcome are recorded in the vehicle history. TruckFixr has used this approach to support more than 100 vehicle-issue resolutions in early fleet pilots, helping fleets identify problems earlier, prevent avoidable breakdowns, and keep vehicles moving safely.

AI agents can generate impressive work quickly, but the agent that created something is not necessarily the best judge of whether it is correct, complete, secure, or ready to move forward. Without an independent review step, mistakes can compound as later stages build on work that was never properly validated. I created a system of specialized AI review agents that act as quality gates between stages of work. Instead of letting the agent that performed the work decide whether it is finished, a separate reviewer evaluates the output against explicit criteria and makes a gate decision: PASS or NEEDS REVISION. Different reviewers focus on different dimensions. In my software development workflow, I use reviewers for implementation fidelity, code quality, security, performance, and specification compliance. A feature does not advance until the required reviewers have passed it. Step-by-step: 1. Define what “good” means before the work starts. Give reviewers an explicit source of truth, such as a specification, plan, acceptance criteria, coding standards, security rules, or quality rubric. 2. Separate execution from evaluation. The agent that performs the work should not be the only agent deciding whether that work is acceptable. 3. Create specialized reviewers for important quality dimensions. For software, this might include implementation, code quality, security, performance, and specification reviewers. The same pattern can be used for research, writing, factuality, compliance, financial analysis, or brand review. 4. Run the appropriate reviewers when a stage is complete. Each reviewer independently inspects the work from its assigned perspective and actively looks for reasons it should not advance. 5. Require an explicit gate decision. A reviewer must return either PASS or NEEDS REVISION, along with concrete findings and recommended fixes. In my workflow, reviewers can block progression for issues such as missing tests, even when the underlying implementation appears correct. 6. Route failed work back to the appropriate agent. The worker fixes the identified problems and submits the work for review again. 7. Advance only after the required gates pass. Later stages should not build on work that still has unresolved review findings. 8. Keep humans at consequential decision points. AI reviewers can determine whether work satisfies their assigned criteria, but important actions such as merging, deploying, publishing, or otherwise committing the result can remain human decisions. Instead of treating AI-generated work as complete simply because an agent produced it, I create a controlled loop: Build → Review → Fix → Re-review → Pass → Advance The result is a more reliable workflow where specialized agents perform the work, independent agents challenge it, and errors are caught before they propagate into later stages.

It starts with one scheduled job that runs at 6 a.m., before I open anything. Every automated task in my business writes a single line to a shared table when it finishes. That log records which job ran, when it ran, and whether it succeeded. It is the foundation of the whole system because I am checking for silence instead of waiting for something to alert me. Step-by-step: 1. The 6 a.m. job reads the log and lists anything that was supposed to run in the last 24 hours but never checked in. 2. It pulls each client’s spend and traffic directly from the ad and analytics platforms. 3. It calculates where spend should be for that day of the month: monthly budget divided by the number of days in the month, multiplied by the number of days elapsed. Anything more than about 15 percent off pace is flagged. Accounts that return an authentication error are also flagged, which helps catch a dead access token before the client does. 4. It sends all of that to Claude along with a short brief on each client. Claude writes one email with broken items at the top in plain English, followed by a single line for each account that is fine. 5. The same table feeds the live dashboards clients use, so a monthly report is a link I already have rather than something I need to assemble. To rebuild this today without much code, I would start with the smallest version: Step-by-step: 1. Create a spreadsheet where each automation logs a row. 2. Add one scheduled script that emails me whatever is missing. 3. Use a Claude prompt to turn that raw list into the email. 4. Add the spend checks once the heartbeat is working. Alerting on silence is the part that does the real work.

The ETHOS™ Framework (Evaluation Through Hierarchical Oversight of Sources) is a multistage forensic audit system designed to transform AI-generated research into “audit-ready” ground truth. Its five-stage lifecycle is designed to ensure technical precision: Step-by-step: 1. EXTRACT (Stage 1): Using the Ground Truth Manifesto and the six-tier Authority Ladder, ETHOS extracts structured tax reports from multiple LLM archetypes: Technical Specialists, Strategic Advisors, and Operational Drafters. This forces their initial findings to follow a strict legal hierarchy. 2. TEST (Stage 2): The Tax Citation Auditor subjects the reports to a three-pass forensic review, testing every citation for existence, pinpoint accuracy, and application fit. Any citation that cannot be verified in a primary repository is immediately downgraded or flagged. 3. HEAL (Stage 3): The Post-Audit Correction Protocol (PACP) repairs the evidence chain by requiring the LLM to resolve flagged citations, replace fabrications with 3–15-word verbatim micro-quotes, and revalidate all “knock-on” effects across downstream computations and thresholds. 4. ORGANIZE (Stage 4): The Human-in-the-Loop (HITL) controller organizes the pre-audit and post-audit artifacts in a consolidated AI sandbox, such as Google Notebook, Claude Cowork, or Perplexity Spaces. This manages the collectively exhaustive data, elevates mutually exclusive advisory angles, and maintains institutional version control. 5. SYNTHESIZE (Stage 5): ETHOS applies MECE principles (Mutually Exclusive, Collectively Exhaustive) and the Weighted Authority Confidence Index (WACI) to adjudicate model conflicts and synthesize a single ground-truth memo. Every load-bearing conclusion is certified for release.

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

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

I 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

Earlier in my career, I spent a significant amount of time delivering security risk assessments. These engagements typically took 8–12 weeks from the initial client meeting to the final report, with complex projects often stretching to 3–4 months. Today, I can produce reports of comparable quality in 1–2 days. The automation runs end-to-end in about 15 minutes; I spend the remaining time reviewing and validating the output. The workflow starts with a structured questionnaire and uses ChatGPT, Perplexity, Claude, Make.com, Google Drive, and Gamma.ai to research, draft, format, and deliver the report. This compresses the delivery timeline while preserving quality and lets me focus on expert judgment, validation, and client communication instead of manual report production. Step-by-step: 1. I have the client visit a web page and complete a structured questionnaire built on Lovable.dev. 2. The submitted information triggers an automated Make.com workflow. 3. ChatGPT analyzes the client’s responses. 4. Perplexity conducts targeted research tailored to the client’s industry, context, and risk profile. 5. Claude drafts the report and saves it to Google Drive. 6. The draft is passed to Gamma.ai, which generates the final client-ready report. 7. I receive the report by email, perform a thorough review, and send it to the client once I approve it. 8. I use the time saved to focus on expert judgment, output validation, and client communication.

I’m researching two separate documentary films. For each project, the bot runs three web crawls and one health check every day. Based on my notes, scripts, and other existing initial research, it identifies research domains by theme and media type, favoring audio and images while applying a higher threshold to other documents. Anything scoring eight or higher is logged in Notion and downloaded automatically when possible. The bot cycles through different themes, and the health check adjusts the similarity threshold based on the results. If many items score eight, it may log and download only nines. If fewer qualifying items appear, it may begin downloading sevens. Most items cannot be downloaded because they are inaccessible to the bot, but they are still logged and linked. I review the items in Notion and mark each one according to criteria such as “people only for research” or “reject—permissions required.” It isn’t a full replacement for professional archival research, but I feel it’s getting me 90% of the way there. As an independent filmmaker, this is a huge benefit. Each morning, it sends me a synopsis, and each week, it sends me a list of pre-written emails to send to archives that require human interaction. Step-by-step: 1. I provide the bot with my notes, scripts, and existing initial research for each documentary project. 2. For each project, the bot runs three web crawls and one health check every day. 3. It identifies research domains by theme and media type, with a preference for audio and images and a higher threshold for other documents. 4. It logs items scoring eight or higher in Notion and automatically downloads them when possible. 5. It cycles through different themes and uses the health check to adjust the similarity threshold: it may focus on nines when many eights appear, or begin downloading sevens when fewer qualifying items appear. 6. It logs and links items that cannot be downloaded because they are inaccessible to the bot. 7. I review each item in Notion and mark it according to criteria such as “people only for research” or “reject—permissions required.” 8. Each morning, I receive a synopsis, and each week, I receive pre-written emails for archives that require human interaction.

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

I built a suite of teaching tools that work independently and together. Chalkline supports maths, while Penline supports literacy. Both tools provide quick access to the New Zealand curriculum for planning and feed information directly into my planning utility, Planline, making teacher planning faster. Planline integrates with Google Drive and is set up with Stripe billing for subscriptions. The suite also includes Compass World News, a news aggregator with a freemium model and a pro unlock. The apps are designed without user tracking. Findaroo is a freemium word-find game with ads. Slashkit helps Minecraft players quickly create commands to use in games. Everything is built into my website, www.danielsoutham.co.nz, which is hosted on Cloudflare. I push updates and changes through GitHub, so I can make changes—big or small—from anywhere, on any device. Changes are then pushed and merged in one prompt. Step-by-step: 1. I built Chalkline for maths and Penline for literacy, with each tool able to work independently. 2. I connected both tools to the New Zealand curriculum so teachers can quickly access it for planning. 3. I connected Chalkline and Penline to Planline so they can feed information into the planning utility. 4. I integrated Planline with Google Drive and set up Stripe billing for subscriptions. 5. I added Compass World News as a freemium news aggregator with a pro unlock and no user tracking. 6. I added Findaroo as a freemium word-find game supported by ads. 7. I built Slashkit to help Minecraft players quickly create commands for use in games. 8. I brought all of the apps together on www.danielsoutham.co.nz and hosted the website on Cloudflare. 9. I use GitHub to push and merge updates, allowing me to make changes from anywhere, on any device, in one prompt.

I built Future Quest to help sixth-grade students connect their career interests to the classes they are taking, especially the subjects they will encounter in sixth grade. Here's the prompt I used: > "Build me an interactive website portal for students to enter what they want to do when they grow up, or what they are interested in now, and what they are learning that they are not so interested in. Based on their entry/input choices make connections between what they are learning in school, especially what they will be learning in 6th grade, and how it's important to learn for their future based on what they want to do. Provide a link to a follow up site to show students images, website links, videos of their chosen profession or job or career ideas to get them excited about it drawing connections so how what they are learning in school will help them get there one day. This is for 6th grade students. Make it a single web page, mobile-friendly, in my brand colors that generates career pages for students created on the fly based on their input responses. Then give me the file so I can share or host it. > > Ask me some questions to make sure I get the best output possible." I used Claude Code and was amazed that it generated a one-page HTML file that creates a follow-up page for students based on their career choices. The page includes information about their chosen career and connections to the classes they are taking, helping them see how their current education can support the work they may want to do in the future. I created the site with a Star Trek theme based on my sixth-grade Math and Science classes: https://educatoral.com/equinox-future-quest.html It took about 25 minutes in total and about 9,000 tokens. Step-by-step: 1. I wrote a prompt describing an interactive, mobile-friendly, single-page portal for sixth-grade students. 2. I asked the portal to collect students' career interests, current interests, and subjects they are less interested in. 3. I asked it to connect students' school learning—especially sixth-grade classes—to their future career interests. 4. I asked it to provide images, website links, and videos about students' chosen professions, jobs, or career ideas. 5. I asked Claude Code to generate the page in my brand colors and provide a file I could share or host. 6. I used Claude Code to generate a one-page HTML file that creates career pages dynamically from students' responses. 7. I created the site with a Star Trek theme based on my sixth-grade Math and Science classes and shared it at https://educatoral.com/equinox-future-quest.html.

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.

I built an episode with the wrong voice. It was not a bad take; it was the voice of a different project entirely—a narrator I had cloned for another series months earlier. Nothing in my files identified which voice belonged to which show, so the assistant picked the one it had seen most recently. I did not catch the mistake until the mix. That is what working with agents on anything long actually costs you: not bad output, but amnesia. Every session starts cold, so settled decisions get reopened, undocumented rules get broken, and the same argument returns every week wearing a different hat. I run several short-form historical and science-fiction series at once, and they all survive on one file each. It is not documentation or a spec. It is what film crews have used for a century: a series bible combined with a daily production report, pointed at an agent instead of a hundred people. I use one Markdown file, read at the start of every session and updated when the session closes rather than when it opens. Four sections do the work: Step-by-step: 1. Closed canon: Each decision includes its reason. Mine says the opening shot is never a contemplative establishing shot. It opens mid-action, with the text hook on screen by the first second, and the beautiful wide shot comes second as the breather. I write the reason next to the decision because the plan for the current episode came back with that wide shot opening the sequence, and I had to reorder it again. The decision alone stops nothing; the reason keeps the rejected version from returning. 2. Rejected list: I record what was already tried and exactly why it was dropped. The wrong voice lives here now as one line: never reuse assets across projects without confirming. This is half the value of the document, and it is the half almost nobody writes. 3. State table: I track each item, its known defects, and the decision already made about it. Mine currently reads: lips at 62.5 to 63.5 seconds, native voice at 64.1 to 65.6, voice moved forward and the original position ducked. A defect written down with its fix is an instruction. A defect nobody records is work you pay for twice. 4. Next three actions: I list concrete next steps, each naming the file it touches. Never “keep going.” Step-by-step: 1. Create `HANDOFF.md` at the root of the project before any real work starts. 2. Write the goal, deadline, and delivery constraints. Anything external that forces your hand goes here instead of staying in your head. 3. Add every consequential decision to the canon, along with its reason and what broke with the alternative. 4. Whenever something is tried and rejected, add a row to the rejected table. It takes fifteen seconds and can save an afternoon. 5. Maintain a state table of the real items, including their defects and agreed fixes. 6. Close every session by updating only three things: the state, the new rejections, and the next three actions. 7. Open every session with: “Read `HANDOFF.md` in full before proposing anything. The canon and rejected list are not up for discussion. Verify the real state against the files, then tell me where we are in two lines.” The discipline that makes this work is updating the file when you close a session, not when you open one. At the end of a session, you still remember why you made the decisions. The next morning, you do not—and neither does the agent. The template is at the bottom. It costs nothing and it is a text file.

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

I use AI agents across roughly half of my startup, including search, security testing, development, and affiliate integrations. - Smart Shopping Deals search: It never relies on a single AI provider. I use a chain of backup providers for LLM-based search and embeddings with pgvector. If one provider fails or times out, the system silently retries with the next. A slow provider never hangs the request, and users never see the failure. In the worst case, the system falls back to plain search. - Security testing: I run the autonomous AI security agent Strix against my live preview after every deploy. It actively attacks the app the way a hacker would. - Development workflow: My real “team” is a four-layer testing rule enforced by the AI itself. Every feature has to ship with backend tests, component tests, full browser end-to-end tests, and test-data setup, all in the same commit. Claude Code doesn’t consider a feature “done” until all four exist—not just the code. - Affiliate parsing: One parser handles every affiliate network. I paste in the raw ad code from any network, and the same parser automatically extracts the banner link, image, and destination URL. No network-specific code is needed.

I built a band scraper to identify bands on Bandcamp, interact with them, and offer mixing and mastering services. A daily cron job runs an Apify Bandcamp scraper, stores the data, and supports a website hosted on Lightsail. Step-by-step: 1. I configured an Apify Bandcamp scraper to collect band data. 2. I scheduled the scraper to run daily with a cron job. 3. I stored the collected data. 4. I used the data to interact with bands and offer mixing and mastering services through a website hosted on Lightsail.

Teachers give assessments on devices provided to students, but students can use AI to cheat. I built TypeWriter to bring the level of security found in tests like the ACT and SAT to everyday assessments. Teachers can create assessments from existing materials, post them in a locked environment, and grade submissions and provide feedback on the same website. I built TypeWriter as a high school teacher, and it is free for teachers. Step-by-step: 1. Teachers create an assessment using their existing materials in TypeWriter. 2. They post the assessment in TypeWriter’s locked environment. 3. Students complete the assessment on the provided devices. 4. Teachers grade the assessments and provide feedback on the same website.

I built an Android mobile app that captures and organizes image photologs. Each photo is automatically saved with its date, time, and GPS location, including a link to Google Maps. I can dictate or type notes about an image, then add to or edit those notes later by typing or dictating. When I finish the notes, I add a tag to the photo. The tag remains persistent until I change it or close the app session. This makes it possible to retrieve all images from a session at a location, event, inspection, or other shared subject—such as a 1957 Ford—within seconds by searching by tag or date. All photos are stored exclusively on the user’s phone. Photos can be shared individually, or an entire set can be exported as a ZIP file. Shared and ZIP images arrive at the recipient’s end with all recorded dates intact. Each ZIP file contains the original raw image, an Excel sheet with one row per image and its date, and a formatted field report with each image and its related date in a single image card. The app works with or without cellular or Wi-Fi service. Step-by-step: 1. I capture an image, and the app automatically records its date, time, and GPS location with a Google Maps link. 2. I dictate or type notes about the image. 3. I add to or edit the notes later by typing or dictating. 4. I add a tag when I finish the notes; the tag remains active until I change it or close the app session. 5. I search for images by tag or date. 6. I share individual photos or export an entire set as a ZIP file containing the original raw images, an Excel date sheet, and a formatted field report.