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

I built a family calendar with Lovable and Claude that integrates with our Google Calendars and Todoist projects. My husband, son, dog, and I were struggling to track our schedules in one place. Although we had shared our calendars through Google, we did not have a central view displayed in the house, and the interface became cluttered when we tracked multiple calendars. We had considered buying a Skylight calendar for years, but it costs $300, and we were not convinced we needed all of its extra features. I decided to build my own instead. Step-by-step: 1. I created a product requirements document (PRD) for a family calendar in Claude. It prompted me to choose the available views, decide how to organize each family member’s calendars, support both events and tasks, and add extras such as the day’s weather and a photo background. 2. I shared the PRD with Lovable, which built the first version of the calendar. Lovable helped me integrate my Google Calendars and Todoist projects so that all of our events and tasks appeared in one place. It also helped me integrate Google Photos so our family photos could rotate in the background. 3. I launched the calendar as a password-protected website so any family member could access it from anywhere. 4. I placed the calendar on an iPad in our kitchen and edited it as we used it, learning which features were most and least helpful. I also added calendars for my in-laws when they visited for several months at a time. Claude continues to help me draft new requirements, which I share with Lovable. The calendar is tailored to our needs and costs much less than the Skylight option. The photo feature also makes it feel personal, and I look forward to continuing to evolve it over time.

This dashboard is remarkably simple and effective. I use it to show available beds across our hospital, and it has had the highest adoption of the many apps I have built. Because it contains no patient names and is not intended for diagnostic or therapeutic use, it does not create a compliance problem. Our hospital uses it extensively. Step-by-step: 1. I created a list of ward names, telephone numbers, and the disciplines assigned to them. 2. I built a simple dashboard that separates intensive care, intermediate care, and regular wards. 3. For each ward, I added the total number of beds and counters for available male, female, and neutral beds used for isolation. 4. I added isolation rooms where a male or female patient with a particular disease can be cohorted for isolation. 5. I also added monitored beds whose patients could be taken off monitoring if a monitor is needed. These are our “joker candidates.” 6. I kept patient names and diagnostic or therapeutic information out of the dashboard.

It starts when someone clicks “Find My Best AI Opportunity” on my website. Instead of going straight to a booking page, they enter a short AI chat. The assistant asks about their work, business, main pain point, AI experience, urgency, name, and email. The workflow runs in n8n. Once the chat has enough information, it creates an AI Readiness Summary, saves the lead in Notion, sends me an internal brief, and emails the visitor their summary with a link to book a 30-minute call through Cal.com. The result is a better-qualified call: the visitor gets useful value first, and I have the context I need before we meet. Step-by-step: 1. A visitor clicks “Find My Best AI Opportunity” on my website. 2. The visitor completes a short AI chat about their work, business, main pain point, AI experience, urgency, name, and email. 3. n8n uses the collected information to create an AI Readiness Summary. 4. The workflow saves the lead in Notion and sends me an internal brief. 5. The visitor receives their summary by email, along with a link to book a 30-minute call through Cal.com. 6. I review the context before the call, making it better qualified.

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 built a tool that makes it easy to collect feedback and reviews for digital products, meetings, YouTube channels, and physical items. Display a custom QR code on your screen or at your point of sale so people can scan it and leave feedback or a review. Users do not need a Google account to submit their responses. You can filter the feedback and share it on social media to help promote your service or product. The easy-to-use dashboard also provides sharing tools and widgets for websites. Step-by-step: 1. I created a custom QR code for the product, meeting, channel, or item. 2. I displayed the QR code on a screen or at the point of sale. 3. I let people scan the code and submit feedback or a review without needing a Google account. 4. I filtered the collected feedback in the dashboard. 5. I shared the feedback on social media and used the available website widgets and sharing tools.

This World Cup 2026 poetry generator scraped the web for match information and called LLMs to help users generate match-specific poems. 1. A daily schedule triggered web scraping to collect match information. 2. When a user requested a poem, the generator used that match information to create a new match-specific poem with help from LLMs.