Workflow Hub

A working preview makes it tempting to keep asking for features. But the first screen tells you little about who controls the database, how the application is structured, or what the next prompt might change. I developed this workflow by putting my best-practices guides to work on a client project, then separating the reusable process from that project’s architecture. This workflow is for AI app-building platforms, often called vibe-coding platforms, where you describe an application and the platform generates and runs a working prototype. It focuses on keeping control of the code, repository, backend, and platform connections. It is not a general guide to coding agents or AI-assisted editors. Anyone who has watched a code generator slowly degrade a clean codebase knows why the starting conditions matter. Before asking for features, establish what you own, what the tool may change, and how you will check its work. Step-by-step: 1. Set ownership before the first build prompt. Decide what the application needs and who controls it. If it needs a new database or backend, provision it in an account you control before asking the builder to create the app. An existing API is another option, not a requirement; some prototypes need neither. Confirm the repository destination, integration permissions, and recovery access. Keep production behind a reviewed release process. 2. Give each tool readable rules. Establish one authoritative set of architecture, coding, and design standards. Identify which files each tool may change and which it may only read. Naming a rules file in a prompt does nothing if the tool cannot access it. Assign responsibility for data, authentication, application logic, deployment, and recovery. One person can hold several roles, but a UI task does not grant permission to redesign the backend. 3. Build the framework before the features. Use the opening prompt to establish the framework, runtime, routes, layout, and state ownership. Ask for empty page shells first. Check that navigation uses real routes and that shared elements have a defined home. Keep design values in one designated place. Any temporary authentication placeholder must be clearly labeled and isolated from protected data. Real users require real authentication and authorization. 4. Inspect and preserve the foundation. Read the generated files and inspect the running scaffold. Check for unrequested services, dependencies, and structural changes. A green build alone does not tell you whether the tool followed your instructions. Once accepted, protect the foundation files from routine UI prompts. Record the accepted commit and preserve a recovery copy beyond the integration’s ability to modify or delete. 5. Set up a prompt factory. A prompt factory is an assistant configured to turn a plain-language request into a bounded implementation prompt. Give it the project rules, file map, technical references, and current capabilities. It checks whether the requested behavior is supported before producing instructions. If something is missing, it prepares a prerequisite request for the responsible owner instead of inventing data or behavior to make the screen look finished. Each prompt names the tool, permitted files, protected files, applicable standards, relevant data and interfaces, exact change, what must be preserved, and observable checks. The factory prepares instructions; it does not approve architecture or release changes. 6. Build one governed feature. Where data is involved, establish correct data behavior first. Follow with a separate placement and styling task. Inspect the changes and test the affected behavior. Apply the One Fix Rule: one repair prompt, one attempt. If it fails, the generator is done with that file. Move the repair to manual maintenance rather than feeding another round of guesses into the codebase. After acceptance, save the next recovery point and update the working rules. Preserve the reason behind each rule so a later cleanup does not remove the safeguard. The point is to make the next feature less likely to undo the work you already accepted. Your database, where needed. Your code. Your standards. You control the tether. Part 2 will cover cutover: leaving the development platform with a controlled release, verification, and a recovery plan. Download The AI Builder Playbook on GitHub: https://github.com/wildeyeai/ai-builder-playbook

Part 2 of my workflow for taking an AI-built prototype off the vibe-coding platform that created it. I wrote it so I could build, run, and recover the app without reopening that platform. It covers AI app-building platforms only, and I work from what the application actually uses, since some apps need a backend migration and others need only configuration changes. 1. Map every dependency before disconnecting anything. I start with the repository, then check where users sign in, where records and files live, and what sends email, runs scheduled work, or handles payments. For each dependency I decide to keep, move, replace, or retire it, and I record where credentials are managed, not their secret values. 2. Preserve the working version and choose a release candidate. I record the accepted commit, build, and configuration, and keep a recovery copy the builder cannot change or delete. I finish or stop builder edits, confirm what reached the repository, and name an owner for each release decision. 3. Rehearse the destination without activating production. I build the candidate in an isolated environment with test data, and I check whether connecting a repository or merging triggers a deploy. Then I exercise the app on the destination before moving anyone. 4. Move only what needs to move. If the backend stays, I verify access and compatibility. Where needed, I plan pauses for writes, jobs, and incoming events. I check identities, files, and permissions separately. 5. Release the tested version and verify real behavior. I confirm the candidate and recovery plan, switch traffic through the rehearsed path, then test the production address: refresh pages, sign in, create and read back a controlled record, and confirm unauthorized users are blocked. 6. Plan recovery for new activity. Restoring old code does not undo new emails, payments, or database writes, so before release I define when rollback is safe and when I must reconcile instead. 7. Retire old connections and update the rules. After verification and the recovery window, I remove obsolete sync, credentials, and jobs, check shared integrations, confirm billing before canceling, and update the instructions for the next change. The goal is an app I can build, run, and recover from accounts I control, with any remaining platform dependency recorded honestly. The full Platform Detachment Runbook and checklists are at https://github.com/wildeyeai/ai-builder-playbook Part 1 is here: https://app.therundown.ai/community/posts/f1c34207-edc7-4b42-9252-3609d5edbfb7

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

I run nine AI agents on one VPS, each named after its job, with 65 scheduled tasks between them. Most of those tasks never call a model. This is for anyone who wants AI working in the background. 1. One agent per job, not one for everything. Each has its own directory and credentials file, so revoking a compromised one costs one service, not the estate. 2. Write the work as a schedule, not a prompt, using five field cron. "0 3 * * *" backs the fleet up, "0 6 * * *" runs the security scan, and "0 23 * * *" mines the day's session logs. Interval jobs cover the rest, every 15 minutes for the watchdog. 3. Pick the delivery target at creation time: a Discord channel, email, or a local file. Mine go to a channel per officer, so a failure is a message I see and a quiet job is one I stop noticing. 4. Attach a skill instead of pasting a paragraph. Each job loads a skill file with the procedure, pitfalls and exact commands, kept in version control instead of a prompt I edit by accident. 5. Use a plain script when the answer is deterministic. My watchdog is a shell script on a 15 minute interval that checks disk, memory and failed units and pipes the result to the channel. It has run 13,752 times with no tokens and no model. 6. Put a guard in front of the tools. A hook runs before every tool call and refuses secrets in a chat message, deletes without approval, and invites accepted on my behalf. 7. Count your jobs monthly. I have 85 defined and 65 enabled. A disabled job is a plan; an enabled job is a contract that should be able to say what it can reach. The boring half of running a small estate happens without me, the interesting half still gets my attention, and it runs on a VPS I already paid for. The skills are public at github.com/ciberjohn/Hermes-Skills. The agents were never the expensive part. My attention was.

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.

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.

I built an AI orchestrator called ADT (Agent-Dev-Team) that sits over Claude Code and GitHub and drives each step of the development pipeline: the ticket, the Definition of Done, the build, the quality check, and the cost. It contains around 6,000 lines of Python and prose and is open-sourced here: https://github.com/zurichrich/ai-orchestrator-adt I had been building with Claude for over nine months, so I documented what goes wrong when an agent receives a real problem. It can overcomplicate or duplicate work, or build the wrong thing. It builds quickly, but with questionable quality. I realized this is not necessarily a model problem: give any capable agent—or human—a vague ticket, and it can build the wrong thing quickly and confidently. Coding agents made implementation cheap, so the bottleneck moved upstream to planning. Planning was still me, typing prompts and becoming the slowest part of my own setup. I also became less focused by GitOps processes, with multiple parallel sessions colliding, so I needed a tool to remove that friction. I built ADT with Claude and put it to work on itself and on other personal projects that are currently in development. Step-by-step: 1. I put the backlog next to the code. Tickets live in GitHub Issues and mirror to a local Markdown cache, so the agent reads and edits them with the same tools it uses for the code. This keeps the process fast, reduces guesswork about what the ticket means, and keeps the full history visible to everyone. Claude writes in tickets far more than humans do, so GitHub Issues become the knowledge base of the future. 2. I write the Definition of Done so a machine can check it: a command that exits with 0, rather than a paragraph of good intentions. If I cannot write that command, the ticket is not ready and the build should not start. 3. I let the ticket do three jobs. It is the specification, the prompt Claude works from, and the record afterward. Keeping one description of the work prevents the build from wandering away from what was requested. 4. I track token use and cost per ticket, so when a product owner asks what a feature cost, I can tell them. 5. I run ADT on itself and on other personal projects currently in development. The results are 46% better plan quality, 37% fewer bugs, and 15 agents running in parallel without colliding.

I built a system that reads my AI newsletters every morning and turns them into a searchable catalog of AI tools, plus a chat website where I can ask questions about the catalog in plain English. The system has two parts: a workflow that collects the information and a website that answers questions about it. I subscribe to several AI newsletters, and each issue mentions five or ten interesting tools. I would read about one and think, “I should remember that.” Months later, I would vaguely remember it but have no quick way to find it. I wanted a repository of these AI tools that I could search easily. The collector is a scheduled Claude Code Routine that runs once a day. It searches Gmail for newsletters from the last 24 hours and reads each email in full. It extracts every AI tool’s name, description, category, official link if present, and source newsletter. It skips non-AI items and pure ads but keeps sponsors that are genuine tools. Before adding anything, it checks for duplicates. New tools are added under the appropriate category in alphabetical order. If an existing tool has fresh details, its description and “last updated” date are refreshed. Tools mentioned by three or more sources receive a “Highly Mentioned” tag, which is a useful signal for what is catching on. The workflow also creates categories when new tools do not fit into an existing one. The workflow commits and pushes the catalog to a private GitHub repository, then posts a summary to Slack. The catalog is a single Markdown file—plain text, human-readable, and versioned in Git, with no database. The chat website displays the tool count, category count, and last-updated date, along with clickable example questions. If I ask, “Is there anything for voice AI?” it returns a written answer listing every match with descriptions and working links. The site is a React single-page app on Netlify with two small backend functions: one returns the statistics, and the other handles chat. When I ask a question, the backend fetches the Markdown file from the private repository, sends it to Claude along with my question, and returns the answer. To recreate it, you’ll need a GitHub account, Netlify (the free tier is fine), an Anthropic API key, and Claude Code. The routine prompt is the most important part. It names the exact newsletters, lists the fields to extract, and explicitly says: never invent a URL, never delete an entry, and only add or update. Vague instructions produce files that degrade over time. I learned a few things the hard way. Newsletters deleted before the workflow runs may cause it to report “nothing new,” so the logic should also check Trash or Deleted items. Tokens expire, and mine quietly expired, which caused the search site to stop working. Choose a long expiration period and record the date. Also, explicitly say “never invent a URL,” or the workflow may produce plausible links that go nowhere. It now runs every morning without me. When I need something, I ask a question and get an answer in seconds instead of trying to remember which newsletter, and which month, mentioned the tool I’m thinking of. Step-by-step: 1. I created a private GitHub repository with a starter Markdown file containing “Last updated” and “Total tools” fields, category headings, and consistent fields for each tool. 2. I wrote a Claude Code Routine prompt that names the newsletters, specifies the fields to extract, and instructs the workflow never to invent a URL, never to delete an entry, and only to add or update tools. 3. I scheduled the routine to run daily with Gmail access. 4. Each day, the routine searches Gmail for newsletters from the previous 24 hours, reads them, extracts AI tools, skips non-AI items and pure ads, preserves genuine tool sponsors, and checks Trash or Deleted items when necessary. 5. The routine checks for duplicates, adds new tools alphabetically under the right category, updates existing tools with fresh details, creates categories when needed, and applies the “Highly Mentioned” tag to tools found in at least three sources. 6. The routine commits and pushes the Markdown catalog to the private GitHub repository and posts a summary to Slack. 7. I built the frontend with Vite and React, including a statistics header, a scrollable message list, an input box, and example questions. 8. I added two backend functions: one for statistics and one for chat, with the GitHub fetch handled by a shared helper with a short cache. 9. I created a fine-grained, read-only GitHub token limited to the single repository. 10. I deployed the site to Netlify with the required keys stored as environment variables rather than in the code. 11. When I ask a question, the backend fetches the Markdown catalog, sends it to Claude with my question, and returns the matching tools, descriptions, and links.

I built Shots2Points, a golf scoring app for iPhone and Android, using AI as my development partner. The idea came from organising and playing in golf society events. Stableford scoring itself isn’t particularly complicated, but running an event can be. Organisers have to prepare groups, handicaps, and courses; collect scores from different groups; calculate results; manage withdrawals and ties; and eventually produce a leaderboard. I wanted to simplify that process while also providing an easy scoring app for ordinary casual rounds. The unusual part is how I built it. I’m not a professional software developer, and I don’t have a development team. I started by describing what I wanted the app to do to AI and gradually turned the idea into a working product. My workflow evolved into this cycle: idea → discussion → specification → implementation → real-world test → refinement. I repeat it for each feature. Step-by-step: 1. I define the problem and user experience with ChatGPT. I discuss ideas, challenge assumptions, work through workflows, and decide how a feature should behave before changing the code. 2. Once the behaviour is clear, I turn the idea into an implementation task. I use AI to specify exactly what needs to change, including edge cases and how the new feature should interact with existing functionality. 3. I build and inspect the code with Cursor. Cursor works directly with the project codebase, allowing AI to investigate existing code, implement changes, and report exactly what it changed. I test the result rather than simply accepting AI-generated code. 4. I test development versions on real iOS and Android devices. I follow the actual user journey, take screenshots or capture errors when something isn’t right, and bring those results back into the AI workflow. 5. I use AI to diagnose problems, make another targeted change, and test again. The result is a real cross-platform application rather than a prototype. Shots2Points includes free casual Stableford scoring and an Event Mode designed for golf societies and groups. Organisers can create events, import players, allocate groups, and allow each group to enter scores while everyone follows a live leaderboard. Building the app has required much more than generating code. AI has helped me work through database design, APIs, authentication, in-app purchases, App Store and Google Play requirements, debugging, user-interface decisions, testing, and release management. The biggest lesson for me has been that AI doesn’t remove the need to understand the problem or make decisions. It gives one person access to capabilities that would traditionally have required several different specialists. I provide the product knowledge, requirements, judgement, and testing; AI provides much of the technical capability and an extraordinarily fast feedback loop. That combination allowed me to take a personal idea for improving golf scoring and event management and turn it into a functioning iOS and Android product.

I teach AI in Business at Western Washington University, and I built a free, case-based AI textbook with Claude and GitHub Pages: https://prof-califf.github.io/ai-in-business/ The 11-chapter digital textbook includes seven real company cases—EveryCure, Netflix, Spotify, Uber, Waymo, Airbnb, and Epic—plus chapters on AI’s environmental cost, ethics, regulation, and the future of work. Seven chapters include hands-on Python labs, and Chapter 8 has an interactive calculator that models the energy and water footprint of a reader’s own AI usage. The textbook is free, has no publisher, and costs $0 to host. The problem was that AI textbooks are stale before they ship. An 18-month publishing cycle means students can pay $200 for a book that is already two model generations behind. Textbooks also tend to teach theory first and postpone business relevance until much later. My students do not need to derive backpropagation. They need to understand why Spotify built a recommender, how it works, what broke, and what it cost—then build one themselves. My stack is Claude, GitHub Pages, VS Code, Google Colab for the labs, and n8n for the Chapter 7 agentic lab. The project started when I was assembling a reading list and could not find anything usable—only outdated textbooks and paywalled cases. I already had years of lecture notes scattered across documents. Step-by-step: 1. I locked in a framework first. I use the AI Factory model—Data → Model → Prediction → Decision → Value → loop—and run every company through it. This is the step people skip: it builds transferable skills for students and gives Claude a stable structural contract across every chapter. 2. I set up the repository before writing. I created a new repo, added `index.html`, opened Settings → Pages, and confirmed that the site deployed. Five minutes up front was better than debugging after 40,000 words. 3. I built one chapter completely and used it as the template. Each chapter is a single, self-contained HTML file with no build step or dependencies. Then I prompted Claude: "Here's my finished Chapter 1 as the format reference. Here are my notes on Uber. Draft Chapter 4 in the same structure and voice." A finished exemplar worked better than an abstract description. 4. I started from my existing material instead of using a blank prompt. Claude structured and clarified my notes, but it did not decide what I think. I rewrote anything that did not sound like me. That distinction preserved the resource’s voice and avoided generated filler. 5. I made the labs builds rather than exercises. Students reconstruct each system in Google Colab using Claude as a coding partner, then publish their work to their own GitHub repositories. They finish with artifacts. 6. I shipped an incomplete version and update it like software. I published with fewer chapters, then edit and push updates when regulation changes so students automatically get the current version.

An AI “executive brain” needs two things: intelligence that, combined with your context, forms the system’s “brain,” and a harness that gives it “hands”—the agentic capabilities to act on your behalf. Claude Code and Codex are two popular options. Their apps provide both the model and the harness in an easy-to-use interface. My workspace is GitHub because popular AI models already understand it and can handle its setup and administration for me. GitHub also syncs automatically with the local file system on my MacBook, so I retain complete ownership and control. If I ever wanted to leave GitHub, I could do so without lock-in. The same setup can work in any file system, from your local file system or Google Drive to a more sophisticated option like Obsidian. A good manager has a structured process for onboarding and staying aligned with a team. You need the same structure to work effectively with AI. My “executive brain” has four layers: the company layer, project folders, operations folders, and the process layer. The company layer contains the mission, vision, values, brand guidelines, and decision-making principles. Project folders contain one folder per project, including its specification, plan, open questions, and decision log. Operations folders cover ongoing areas of the business, such as marketing, finance, and support. They have the same shape as project folders, but they never finish: projects ship, while operations run. The process layer contains standard operating procedures for how we work together, such as processing a meeting, planning a project, publishing a post, and closing out the week. For AI to work successfully, your company has to be “legible” to it. If information is not written down and accurate, it is not legible, and the AI cannot help you with it. This is like onboarding a great new hire: explain what the company is trying to do, what each project is for, what has already been decided and why, and how you like to work. You do not need to write everything alone or all at once. The AI can interview you, draft the documents, and file them in the right place based on the structure you set up. An employee without logins cannot do much, and AI works the same way. Start with the places where you communicate. At my company, we primarily communicate through Zoom and our community forums, so my AI system is connected to both. This allows it to stay up to date as we progress and participate in discussions as an equal participant when asked. Once the AI is connected to your communications, give it access to the places where you want it to execute on your behalf. You can connect it directly through an API or MCP, or it can use a browser to interact with a tool the same way you do by clicking and typing. You decide what it can access, and you can start small. Each connection turns a category of “things I have to do myself” into “things I can delegate.” The final step is incorporating what the AI learns. After every working session and meeting, it updates the record: decisions are logged, task lists are reconciled, and project documents are brought up to date. When we learn something, it goes into the SOP, so every future run is sharper than the last. That is how the AI becomes more useful every week: its knowledge compounds inside the business instead of starting from zero in every conversation. Step-by-step: 1. Choose the intelligence and harness that will power your AI system. Claude Code and Codex are two popular options whose apps provide both in an easy-to-use interface. 2. Create a workspace for alignment, planning, feedback, and learnings. I use GitHub because AI models understand it, it handles setup and administration, and it syncs with my local MacBook file system without locking me in. 3. Organize the workspace into four layers: company information, project folders, operations folders, and process documentation. 4. Make the company legible by documenting its goals, projects, decisions, working preferences, and other relevant context. Have the AI interview you, draft the documents, and file them in the appropriate locations. 5. Connect the AI to your communication tools, such as Zoom and community forums, so it can stay informed and participate when asked. 6. Connect the AI to the systems where you want it to execute tasks. Use a direct API or MCP connection when available, or give it browser access when it is not. 7. After each working session and meeting, have the AI update decisions, task lists, and project documents. 8. Add new learnings to the relevant SOP so each future run improves on the last.

I've been thinking about the value of handoff documents and explanatory documents as we continue exploring efficient ways to work alongside AI to build software and improve communication. Even though we use many different tools, Markdown still has an important place. This new version of an HTML handoff document can document what exists, describe what could exist, or serve as a mockup for a brainstorm. It lets us communicate with remarkable fidelity through visuals, hierarchy, and formatting. It's also an efficient format for AI to understand. We shouldn't underestimate the significance of AI communicating with us through a visual medium. A visual flowchart with thoughtful design, layout, animation, and progressive disclosure can help us understand the logic and flow of incredibly complex systems much faster. I tried all kinds of tools, including React Flow and Mermaid. They're fun to experiment with, but Archify is a game changer for this use case. I can point it at any technology, repository, or brainstorm and work with it to build flowcharts with animations and clean, distinctive design. It's also completely free. https://tt-a1i.github.io/archify/# Step-by-step: 1. I identify whether I need to document what exists, explore what could exist, or mock up a brainstorm. 2. I use Markdown and an HTML handoff document to communicate the ideas with visuals, hierarchy, and formatting. 3. I consider tools such as React Flow and Mermaid for creating visual representations. 4. I point Archify at the relevant technology, repository, or brainstorm. 5. I work with Archify to develop a flowchart with animations, clean design, and progressive disclosure so the system's logic and flow are easier to understand.

I read the news every day, but it had become increasingly depressing and was making me miserable. What bothered me most was that it also felt inaccurate: although bad things are happening, there have been many positive developments over the past five years that rarely receive sustained coverage. Major news sites might publish an article or two about them, but those stories are quickly buried under negativity. I wanted a way to get only positive news stories in my feed each day. Keyword filters did not work: “record” and “breakthrough” also appear in stories about record wildfire seasons, while “war” can appear in “war ends.” Off-the-shelf sentiment analysis was not useful either. A happy press release about layoffs can be classified as positive, while a dry factual story about a disease being eliminated may be classified as neutral. So I trained a basic artificial version of my personality using a series of prompts about what I consider positive in the world. I connected it to Mistral through OpenRouter and gave it access to public RSS feeds from news sites I already trusted. This eventually became Rally News, which I published on Google Play. iOS has been more difficult. The app surfaces positive stories from more than 20 news sites in an endless scroll, giving me an alternative to my uncomfortable TikTok addiction. Because I made it public, I decided not to host article text: publishers keep their traffic and revenue, while the tool remains ethical. The system runs on a GitHub Actions cron job that pushes stories to a PHP and MySQL database. I built the app without coding experience for about $25 per month. Step-by-step: 1. I collected RSS feeds from established publishers I already trusted and stored the list as configuration. I started with about 10 feeds instead of a few hundred so I could realistically read the output. 2. I set up a scheduled GitHub Actions cron job to run a Python script that pulls new items from every feed. 3. I deduplicated incoming articles against the database using the URL and a normalized title. Syndicated stories frequently reappear under slightly different URLs, and I did not want to pay to evaluate the same article twice. 4. I wrote the filter prompt as a long persona document rather than a one-line instruction. It explains what I consider progress, what I consider a puff piece, and which cases should fail—for example, celebrity news is not good news, a company announcing an intention is not the same as taking action, and a local feel-good story without wider significance does not qualify. 5. I sent each new article to an LLM through OpenRouter and required JSON output containing a pass-or-fail decision and a short justification. 6. For the first few weeks, I read the justifications every day. Whenever I disagreed with the model, I added a new rule to the persona document. That review loop required nearly all of the actual work. 7. I wrote passing articles to MySQL with only the headline, source, link, and metadata, leaving the article body with the publisher. 8. I pointed the website and mobile app to the same database. 9. I added a second GitHub Actions job that assembles a daily newsletter from the same data through Brevo, allowing one evaluation pass to feed three surfaces.

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

Midlifecurious is a newsletter for women navigating midlife—honest, funny, and allergic to being talked down to. Its Sunday issue, the Midlife Missive, is a roundup covering health, wellness, money, beauty, and family. My sister, Claire, edits it; I build the machine behind it. That machine is Missive, a five-part publishing intelligence system that runs the newsletter as one closed loop: scan → triage → publish → measure → remember. It monitors Reddit, search trends, and RSS to identify what midlife women are paying attention to before those topics reach our feeds. Discovery pulls in those sources, ranks every feed using a click-rate-based quality score, and lets Claire triage articles into the week’s issue. Curation composes Sunday’s newsletter and drafts the introduction in her voice. Performance reads the Mailchimp results back into the system and feeds them into the rankings, so strong sources rise and weak ones fall over time. Underneath all four stages is Memory: a vector-searchable corpus of every article, save, rejection, and the reasoning behind each decision. Memory is the real spine of the system. It lets Missive ask editorial questions such as “Have we covered this before?” and “Is this source still earning its slot?” instead of requiring one person to hold everything in her head. We’re a two-person operation: I build with Claude Code, and Claire edits. The system runs on one database for under $25 a month. I built it because the alternative was Claire drowning in a Feedly-and-spreadsheet routine that discarded everything as soon as an issue shipped. We had no record of what we had run and no feedback on what actually landed. My bet is that the corpus is the moat. Claire’s editorial taste—every save, rejection, and “cornerstone” stamp, with the reasoning stored alongside the decision—is a training set no one else has. A system that remembers turns her job from synthesizer into judge. Missive is deliberately internal-only: no SaaS and no customers, ever. That frees me to build for our exact workflow instead of a hypothetical buyer, and to build for 2028 instead of this quarter. The near-term payoff is a calmer Sunday. The long-term goal is a proprietary editorial-intelligence layer we could never buy off the shelf—the foundation for the research and audience products that come next. Step-by-step: 1. I monitor Reddit, search trends, and RSS for topics that midlife women are paying attention to. 2. I pull those sources into Missive and rank each feed using a click-rate-based quality score. 3. Claire triages the ranked articles into the week’s Midlife Missive. 4. Missive composes Sunday’s newsletter and drafts the introduction in Claire’s voice. 5. I import the Mailchimp results so the system can update source rankings based on performance. 6. Missive stores every article, save, rejection, “cornerstone” stamp, and the reasoning behind each decision in a vector-searchable corpus. 7. We use that memory to check whether a topic has already been covered and whether a source is still earning its place. 8. I build and maintain the internal system with Claude Code, while Claire handles editing, using one database that costs under $25 a month.

I built my agent fleet around one question: could a single assistant become a coordinated team that keeps useful work moving even when its main machine goes dark? I didn't want a pile of chatbots. I wanted specialists with clear jobs, a shared board, a second set of eyes, and a real failover drill. Here's how it works. THE STACK Cloud: GrokBot runs as Fleet Commander. It routes work, runs routines, and stays with me on my phone. Specialist GrokBots take focused research, design, and budgeting assignments. Mac Studio (M2 Max, 64 GB) with two Studio Displays: home base. It runs Codex (my Chief of Staff), Hermes (my local operator), ChatGPT Dot, and Hindsight shared memory. Hermes runs Qwen3.6-35B-A3B, a 4-bit quantization served by llama.cpp with a 256K-token context. With about 3B active parameters per token, it stays responsive on Apple silicon. NVIDIA DGX Spark (128 GB unified memory): my independent compute node. It runs Qwen3.5-122B-A10B in NVFP4, with about 10B parameters active per token, and the model can read images. It also hosts a backup Hermes operator. Windows PC with a GeForce RTX 5090: dedicated GPU capacity for image work. MISSION CONTROL Mission Control is a Kanban board on a private GitHub repository. Every card opens with the question, deadline, evidence links, and done criteria. Labels route ownership. An urgent label fires a webhook that wakes the reviewing agent, and a needs-me label is the one that pulls me in. Agents hand off, report, and raise concerns in card comments, so the work and its evidence stay together. The roles are simple. GrokBot owns routine board moves. Codex checks evidence and records verification. Hermes handles local execution and machine-level evidence. Dot watches for new work and changes. Hindsight holds the shared operating rules, and the jobs themselves stay on the board. A REAL DEADLINE CROSS-CHECK Right before a major application package went out, Dot ran an independent, read-only cross-check of the narrative, the budget justification, and the walkthrough across connected email and Drive. It found three places where the documents contradicted each other and quoted the exact sentences, so each conflict was easy to find. Fleet Commander fixed all three before submission. That's the job of a watcher: spot the mismatch early, show the evidence, and hand whoever owns the work a clear fix. THE FAILOVER DRILL I wanted to know what happens if the Studio's primary Hermes gateway pauses. On October 5, I ran a controlled, reversible soft-pause to find out. During the pause, Hermes on the Spark stayed active through its own Telegram connection and answered a one-shot request with the local Qwen3.5-122B-A10B NVFP4 model. From that worker, I listed a Mission Control issue, verified service-account access and a vault credential check without exposing a secret, and ran the Studio health probe. The probe flagged the Studio Hermes gateway as paused and reported the other checked Studio services as passing. So I had an evidence-backed result: the independent worker could respond, use its local model, read the work queue, and report the primary gateway's health during a real, reversible pause. THE PATTERN Give each agent a narrow job. Put the work on one shared board. Require evidence before anything counts as done. Then pause one piece on purpose and record exactly what the backup can do. That's how capable models turn into dependable operations. The fleet catches contradictions before they get submitted, keeps routine work moving, and shows me exactly where its limits are. I set the goal. The fleet does the work. The evidence shows what actually happened.

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

Before I ship anything built with AI—whether I use Lovable, Cursor, Replit, or Bolt—I run a security and readiness audit. I ask my AI assistant to clone the free, open-source repo at github.com/edgewiselab/ship-kit and scan my project. It identifies my stack from the code on its own, with no configuration required. The audit checks for 113 known launch mistakes, including open databases, leaked secrets, emails going to spam, missing error tracking, and more. It skips anything that doesn't apply to my app. It generates a plain-English report: green means everything is fine, red means I need to fix something, and amber means I need to confirm it myself. I hand the red items back to my AI assistant to fix, then rerun the scan until the report is clean. The tool is free, MIT licensed, and runs entirely on my own machine. Step-by-step: 1. I ask my AI assistant to clone `github.com/edgewiselab/ship-kit` and scan my project. 2. I let it identify my stack from the code without adding any configuration. 3. I review its checks for 113 known launch mistakes, including open databases, leaked secrets, emails going to spam, and missing error tracking. 4. I review the plain-English report and focus on the red items while confirming the amber items myself. 5. I give the red items back to my AI assistant to fix. 6. I rerun the scan until the report is clean.

I run nine GitHub repos as one programme of work. Every project keeps its backlog as plain markdown inside its own repo, one Claude Code or ChatGPT Codex session works each project in parallel, and a single board in VS Code shows all of them moving at once. There is no project tool, no API and no sync job in the middle: the markdown file is the shared state that both I and the agents read and write. Step-by-step: 1. Put the backlog in the repo, as markdown. Every project gets `docstech/users/<me>/todo.md` and `done.md`. A story is a `###` heading. Structured fields ride in an empty markdown link at the end of it: `### Add rate limiting [](?status=doing&epic=api&time_estimated=180)`. GitHub renders an empty link as nothing, so the file still reads as prose in a pull request while carrying real metadata. 2. Write the story before the session starts. Each one has goal, background, scope, out of scope, the files it should touch, a checkbox task list, and acceptance criteria. That story is the prompt, and most of my thinking happens there rather than in chat. It decides whether the session comes back with anything shippable. 3. Open the parent folder in one window, and turn the files into a board. I open the parent folder holding all the projects and open any `todo.md` with NoteThink in Folder mode, which merges every markdown file under it into one view. Group the lanes by project and it is the programme view, one lane per repo. Group them by status and it is the delivery view, one Kanban across the whole portfolio. Each card carries a pill naming the project it came from, and clicking it opens that file at that story. 4. Start one Claude Code session per project. Every session opens with the same instruction: read `todo.md` top to bottom and take the top story. The sessions never talk to each other, because the file on disk is the only shared state. A session that dies costs nothing. 5. Let the board report progress instead of reading the sessions. Agents edit the markdown as they work: tick a task, flip `status=todo` to `status=doing`, move a finished story to `done.md`. The board watches the files, so cards animate into their new column as each change lands, and I can see which sessions are advancing without reading any of them. 6. Steer by dragging. Dragging a card between lanes writes the attribute back into the source markdown, so dropping one in "doing" makes the file say `status=doing` and the next agent turn reads it. Ticking a checkbox does the same. The board is the steering wheel and the file is the wire. 7. Close every story the same way. One slash command runs lint plus the full test suite, checks the story's tasks are ticked, and drafts the commit message; another ships to staging then production. The finished story moves to the end of `done.md`. Over time `done.md` becomes the programme record: what shipped, when, and what it cost. Try the board without installing anything. Here is a live example board, four projects merged into one view, and it is exactly what the screenshot shows: https://www.notegit.com/en/app/notegit.com/notegit/example_repo/blob/ai-board/board.md Results, honestly. Nine repos, about 260 open stories and about 1,400 completed ones, all in markdown inside the repos rather than a tracker. The backlog goes back to March 2024; the parallel sessions on top of it are the last four months. I run eight to twelve sessions at the same time, and the whole thing fits inside one Claude Max 20x subscription over a month of full-time work. Not all of it is code. The same parallel-session habit drives a nuclear reactor design study (https://github.com/cleverlight/mistergy) and several video and design projects. The board part fits best where the work already lives as files in a repo. Limits, honestly. The ceiling is my review capacity, not compute. Eight to twelve is where I sit; past that I stop reading output properly and start rubber-stamping, which is worse than running fewer. It only works when stories are genuinely independent, because two sessions in one file is a merge conflict you wrote yourself. Agents occasionally finish work and forget to move the story, so `done.md` needs a sanity check. And it assumes you will write the story properly first, which is real work that AI does not do for you. The screenshot is the public example board rather than my own, because my real one carries client project names. Disclosure: I build NoteThink, the free, open-source VS Code extension in step 3, and NoteGit, which hosts the example board. NoteThink is on the VS Code Marketplace, Apache-2.0, and genuinely early (v0.3.38, preview quality, a handful of installs). The workflow is tool-agnostic and the markdown is just markdown: any viewer will show it, and you can run the whole thing with no extension. NoteThink is what makes the cross-project board and the drag-writes-back-to-file part work.