Share your best AI workflow. We could show it to 2M+ people.

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 built a predictive maintenance workflow in Awish for one of my manufacturing clients. The client had machine telemetry, production data, and maintenance history spread across different systems. The problem wasn’t collecting the data—it was spotting failure risk early enough to act. I built a custom Awish workflow that continuously checks machine telemetry and production signals in Snowflake alongside asset, meter, and maintenance history from MaintainX. When it detects abnormal performance or increasing failure risk, it identifies the affected equipment, estimates the likely operational impact, and prepares a recommended maintenance action. Nothing is scheduled automatically at that point. The recommendation first goes to the maintenance manager in Microsoft Teams for approval. Once approved, Awish creates and assigns the work order in MaintainX, then keeps tracking and updating its status until the maintenance is completed. The useful part is that the system does not wait for a machine to fail before maintenance starts, but it also does not let AI make the maintenance decision on its own. The analysis is automated, while the actual intervention still requires human approval. Step-by-step: 1. I described the maintenance process I wanted in the Awish chat. 2. Awish planned the workflow and selected Snowflake, MaintainX, and Microsoft Teams for the required steps. 3. I connected the client’s accounts and approved the automation plan. 4. Awish continuously analyzed production and telemetry data in Snowflake together with MaintainX asset, meter, and maintenance history. 5. When it detected abnormal behavior or increasing failure risk, it identified the affected equipment and estimated the likely operational impact. 6. It prepared a recommended maintenance action and sent it to the maintenance manager in Microsoft Teams. 7. Once the manager approved the recommendation, Awish created and assigned the work order in MaintainX. 8. The workflow continued tracking the work order and updating its status until the maintenance was completed. Trigger → Analyze → Approval → Action Machine signals → Failure-risk analysis → Teams approval → MaintainX work order

I keep a long wishlist on Audible, but whenever I want a new audiobook, I face the same question: does my library already offer it for free through Libby? Checking hundreds of titles manually feels like too much work, so I often spend a credit instead. I had Claude build a workflow that checks for me. It reads my Audible wishlist and cross-references every title against my library’s Libby catalog, sorting each one into three categories: borrow now, join the waitlist, or not available. The important part was learning to interpret Libby accurately. Badges and time estimates can make an audiobook look ready when it isn’t, and a pending hold can look like an active one. The reliable signal is the exact text on the button: “Borrow” means I can borrow it; anything else means I should wait or move on. Step-by-step: 1. I gave Claude a workflow to read my Audible wishlist. 2. I had it cross-reference every title against my library’s Libby catalog. 3. I had it sort each title into “borrow now,” “join the waitlist,” or “not available.” 4. I configured the workflow to interpret availability using the exact button text rather than relying on badges or time estimates. 5. Before spending an Audible credit, I check whether Libby already has the audiobook ready.

I’m 71 years old, retired from owning a large cattle-feeding operation, and fairly new to AI and software development. I’ve discovered that I really enjoy using AI to build practical tools in Replit. My latest project is an app for our church to help us oversee a $13.5 million renovation of a 65,000-square-foot former movie theater into our new church facility. I’m not a programmer or a construction expert, so I’m using AI to help bridge both gaps. I built the app almost entirely by describing in plain English what I wanted it to do, testing what it built, and working back and forth with AI to improve it. The app uses AI to read meeting notes, emails, texts, and general project updates and identify decisions, action items, important dates, budget changes, and project events. Nothing is accepted automatically. I review, edit, approve, or reject what AI finds before it becomes part of the project record. The app also keeps our budgets, documents, meetings, and project history together. My goal isn’t to replace our project manager or construction software. I want to see whether someone my age, with no programming or construction background, can use AI to build a useful tool for helping an owner understand and manage a complicated real-world project. Step-by-step: 1. I described in plain English what I wanted the app to do. 2. I used AI in Replit to build the app based on those descriptions. 3. I tested what AI built and worked back and forth with it to improve the app. 4. I designed the app to read meeting notes, emails, texts, and general project updates. 5. I use it to identify decisions, action items, important dates, budget changes, and project events. 6. I review, edit, approve, or reject every item before it becomes part of the project record. 7. I use the app to keep our budgets, documents, meetings, and project history together.

I built an autonomous learning workbook in ChatGPT Projects to help me stay ahead of where I am and where I need to be. Keeping up with that gap has been a labor of love and tears. The goal of the project is to catalog: - What I know - What I’ve forgotten - What I’m currently learning - What skills I need for my career goals - What has changed in healthcare, AI, and my industry - The single highest-value thing for me to do next I use the following prompt in ChatGPT Projects. It may take some tweaking for your personal needs, but feel free to use it as you see fit: > Engineer dashboards for: Learning Progress, Competency Growth, Learning Hours, Weekly Progress, Monthly Progress, Retention, Knowledge Coverage, Executive Readiness, Upcoming Reviews, Learning Recommendations, Skill Heat Map, Learning Velocity, Credential Progress, Continuing Education Credits, and Certification Status. Step-by-step: 1. I created an autonomous learning workbook in ChatGPT Projects. 2. I defined the information I wanted the project to catalog, including my current knowledge, forgotten material, active learning, career-skill needs, industry changes, and highest-value next action. 3. I sent ChatGPT Projects a prompt to engineer dashboards for learning progress, competency, retention, reviews, recommendations, credentials, continuing education, and certification status. 4. I planned to tweak the prompt and dashboards for my personal needs.

I built a digital Second Brain after trying several approaches, including OpenBrain and LLM Wiki. OpenBrain and LLM Wiki are useful frameworks for building a digital brain. The theory is solid: flat Markdown files, AI-first conventions, and an ingestion pipeline that turns raw inputs into searchable knowledge. But when applied in practice, the process can be bumpy and may require adjustments—or an entirely different approach. I adapted the ideas to fit how I actually think and work. I kept what worked, discarded what didn’t, and built my own digital brain. The result is documented in a single file containing everything an AI needs to understand, maintain, or rebuild the system from scratch. Step-by-step: 1. I tried several digital-brain frameworks, including OpenBrain and LLM Wiki. 2. I evaluated their approaches, including flat Markdown files, AI-first conventions, and an ingestion pipeline for turning raw inputs into searchable knowledge. 3. I identified where the frameworks were difficult to apply in practice and adjusted my approach. 4. I kept the ideas that worked for me, discarded what didn’t, and built a digital brain suited to how I think and work. 5. I documented the system in a single file so an AI can understand, maintain, or rebuild it from scratch.

Most AI agents are built around general best practices. That’s useful, but it doesn’t mean they work the way I want them to. I’ve started using a simple calibration process to tailor my agents to my preferences. Instead of telling an agent what to do on each task, I have it interview me about how I like work done in its specific domain. A writing agent asks different questions than a research agent, and a strategy agent asks different questions than a coding agent. The goal is to make my working preferences part of how the agent operates. Step-by-step: 1. I pick an agent I use regularly, such as one for writing, research, strategy, coding, analysis, or career advice—especially where my personal preferences matter. 2. I ask the agent to interview me about how I prefer work to be done in its domain. A writing agent might ask about tone, structure, editing style, and how much pushback I want. A research agent might ask about source quality, depth, recency, citations, and how much synthesis I prefer. 3. I have the agent summarize what it learned and separate durable preferences from temporary or situation-specific ones. 4. I review the proposed changes and ask the agent to show me exactly how it wants to update its instructions or skills. I correct anything it misunderstood and explicitly approve the changes before anything is modified. 5. Once I approve the changes, I have the agent apply them to its instructions or skills so those preferences become part of how it works going forward. 6. I use the agent normally and pay attention to where it feels more aligned and where it still misses the mark. 7. When I notice recurring friction, I add or adjust the relevant preference instead of repeatedly correcting the same behavior task by task. 8. I repeat the interview periodically. My preferences, tools, and workflows change, so the agent should be able to ask which preferences are still valid, which ones I keep overriding, what has been annoying me, and what should be added or removed. The result is an agent that doesn’t just know how to do the job; it knows how I want the job done. Because every change is proposed and approved before it becomes permanent, the personalization stays intentional rather than turning into a collection of guesses about me.

I built a meal tracker where my only job is to photograph a plate and send it to an agent. Identification, portion estimates, macros, storage, corrections, and the weekly review happen without me. The part worth stealing isn't the food. The agent has its own email address and iMessage thread, so anything I can send from my phone becomes an input. I send a photo through whichever channel takes fewer taps. I send corrections as plain English with `CORRECTION` in the subject, and answer questions in the same thread. There’s no app and no form. Adding a channel took an afternoon and changed what the agent could be pointed at—the tracker is just one use of an agent you can talk to. It polls on a schedule instead of using a webhook because my laptop sleeps and a local gateway would be unavailable half the time. Storage is append-only JSONL. Corrections append a new record with the same ID using last-write-wins, so the stats layer sees one meal while the original estimate stays on disk. Every number can be traced back to the model’s first guess and my override. The accuracy mechanism is a challenge step. Every photo is estimated twice: first by the main model, then by a blind subagent that receives only the photo and the rubric—not the first answer. If it identifies different food, the entry is downgraded to low confidence and becomes a question for me. Testing before making the system autonomous caught bugs that otherwise would have failed silently. The API returns attachments under a different field than I had assumed, and only on the detail endpoint. As a result, a photo email was read as having no attachments, and every meal photo would have been dropped while the daily task logged a tidy “no new meals” and appeared healthy. The send path was separately broken, which would have killed the weekly review on a Sunday even with everything upstream working. A silent no-op that produces a plausible clean run is what this category of build is prone to. The bug that actually cost me was token usage: each blind challenge read used about 44,000 tokens, so a five-photo dinner cost roughly 220,000 tokens for one meal and capped my usage. The fixes, in order of effect, were to run the challenger on a cheap model, skip it once a named product or my confirmation has settled the entry, downscale photos for viewing, and republish the dashboard only when the data changes. Measuring first mattered—I would have blamed photo size, but that was the smaller half. The honest limits are important: calorie estimates from a photo are 20–25% off at best, identification error is a bigger risk than arithmetic error, and alcohol, water, and caffeine are never estimated from photos. The sequence in which I asked for things mattered more than any single instruction: Step-by-step: 1. I gave the goal and the one ingestion mechanic I was sure about, then insisted on an agreed plan before any code. Arguing about storage and failure modes is cheap before code is attached. 2. Before scheduling anything, I processed one real input end to end in front of me, including every outbound path. Inbound gets tested because I use it; the reply and the weekly digest do not. 3. When the agent reported something about my own input that I knew was wrong, I said so and made it re-check. Confidently wrong answers about things I witnessed were the cheapest bugs to find. 4. I asked for an independent second assessment of anything estimated rather than read, and decided up front what level of agreement was enough to accept the result. 5. I asked for a visible audit surface showing every field the agent claims to track, with a correction control on it. 6. I asked the agent to look up anything knowable rather than estimate it. A named product is a lookup; only the unnameable needs a guess. 7. I treated approval friction and token cost as requirements rather than complaints, and measured before changing anything. Almost every rule exists because something went wrong in ordinary use, not because it was designed up front. An agent I can email or text, which keeps records and answers back, is general-purpose; I’ve pointed it at one narrow job. What else would you point it at?

I built an agent from scratch that monitors my Claude and Codex usage by adding a runner node directly inside the root of each project repository. It includes agent templates for specific jobs, such as commit, research, janitor, and manager tasks. The agents run automatically at night, when I’m not actively using my five-hour usage period. They monitor their own usage and cap themselves so they leave usage available for me. Later, I built a hive dashboard where I can monitor all of these payloads in one place and execute them from the dashboard as the agents’ jobs become more complex. Step-by-step: 1. I added a runner node to the root of each project repository. 2. I created templates for specific agent jobs, including commit, research, janitor, and manager tasks. 3. I configured the agents to run at night when I’m not actively using Claude or Codex. 4. I had the agents monitor and cap their own usage so they preserve usage for me. 5. I built a hive dashboard to monitor and execute the payloads from a single place as the agents’ jobs became more complex.

I asked Claude to help me build a weekly and monthly habit tracker as an artifact. I prompted it to conduct a Q&A with me so it could understand everything I wanted to include. I also asked Claude to add an insights tab and provide tips for improving my own compliance. Step-by-step: 1. I asked Claude to build a weekly and monthly habit tracker as an artifact. 2. I prompted Claude to conduct a Q&A with me about the features and details I wanted included. 3. I asked Claude to add an insights tab. 4. I asked Claude to provide tips for improving my compliance with the habits.

Yesterday, I built a social media workflow in Awish for a business that wanted to post more consistently without managing three platforms manually. The idea was simple: let Awish understand the business first, then use that context to plan different content for Instagram, LinkedIn, and X instead of reposting the same thing everywhere. I built the entire workflow by describing what I wanted in the Awish chat. Step-by-step: 1. I opened Awish and wrote: “Analyze this business from its website. Based on what the company does, its audience, products, and positioning, create separate content plans for Instagram, LinkedIn, and X. Generate the posts, publish them automatically at the times I choose, analyze how each post performs, and send me the important insights on WhatsApp. I also want to be able to manage the workflow from WhatsApp.” 2. Awish analyzed the website, understood the business, and planned the complete content workflow. 3. I connected the company’s Instagram, LinkedIn, X, and WhatsApp accounts and approved the plan. 4. Awish created a different content strategy for each platform instead of copying the same post everywhere: more visual content for Instagram, business-focused posts for LinkedIn, and shorter, conversation-driven posts for X. 5. I chose the publishing schedule, and Awish started creating and publishing the posts automatically at those times. 6. After publishing, Awish tracked performance and analyzed which topics, formats, and messages were getting the strongest response on each platform. 7. Awish sent me short WhatsApp updates with the important insights, such as which post performed best, what topic was gaining traction, and what it recommended changing next. 8. I could also manage the automation directly from WhatsApp by asking what was scheduled, changing a publishing time, requesting another post, pausing publishing, or asking for the latest performance summary without opening Awish. The useful part for me is that this is not just automatic posting. The workflow starts by understanding the business, treats each social platform differently, learns from what gets published, and keeps the whole process manageable from WhatsApp.

Design taste is hard to put into words. I may know immediately that one website, presentation, report, or graphic feels right and another doesn't, but still struggle to explain whether the difference comes from the typography, spacing, colors, density, layout, or overall aesthetic. That makes working with AI frustrating. If I can't describe what I want, the AI has to guess. Instead of trying to explain my design taste upfront, I turned the process into an iterative visual feedback loop. I first asked the AI to suggest existing websites with different design styles so I could identify examples I liked. Once it had those references, I asked it to create three substantially different HTML mockups for the same content. I picked the direction I liked best, explained what I liked and disliked, and had the AI generate another set of alternatives based on that feedback. After about three rounds, the AI had a much better understanding of my design preferences than I could have given it in a written prompt. The basic loop is: show me examples → I choose → generate alternatives → I react → refine → repeat. This is essentially preference elicitation through examples. Research on human-AI interaction has similarly found that people can refine difficult-to-articulate preferences by reacting to concrete alternatives rather than specifying everything upfront. Step-by-step: 1. I asked the AI for several visual references, including websites or designs that represented distinctly different styles. 2. I reviewed the examples and identified the ones I liked. I didn't need sophisticated design terminology; I simply described what I preferred and anything obvious that I liked or disliked. 3. I gave the AI something real to design. I used an actual report I was working on so I could evaluate the styles in context. 4. I asked the AI to create three substantially different visual directions rather than minor variations of the same design. 5. I chose the direction closest to my taste and explained what I liked, what I didn't, and which elements from the other versions I wanted to incorporate. 6. I asked the AI to generate three new alternatives using everything it had learned so far. 7. I repeated the process until the designs began to converge. I did roughly three rounds, with each round narrowing the design space and giving the AI more information about my preferences. 8. I asked the AI to summarize what it had learned into reusable design guidelines so future projects could start with those preferences. Instead of trying to translate an aesthetic preference into design terminology, I let the AI learn my taste from my choices. The important shift is simple: don't describe what you like—show, choose, react, and refine. This can work for websites, presentations, reports, branding, graphics, interior design, clothing, invitations, or almost anything else where I know what I like when I see it.

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.

Like many people, I had tasks scattered across emails, meeting notes, reminders, recurring responsibilities, and things I was simply trying to remember. Standard task managers helped me store tasks, but they did not solve the harder problem: turning unstructured information into a reliable daily and weekly execution system. I used ChatGPT Work and Codex to build a private, responsive task management application around the way I actually work. The system combines AI-assisted task capture with a Command Center, daily planning, weekly reviews, task lists, a Kanban board, recurring tasks, deadline reminders, search, filters, subtasks, comments, attachments, and a complete activity history. The most useful part is the connection between AI and execution. Emails and free-text descriptions can be interpreted with the OpenAI API and converted into structured tasks, reducing the amount of manual copying and organizing required. Step-by-step: 1. I mapped my real workflow by identifying where my tasks came from and what information I needed to manage them properly: title, description, status, priority, category, deadline, responsible person, subtasks, comments, attachments, recurrence, and activity history. I deliberately designed the system around my existing working habits rather than adapting my work to a generic task management template. 2. I used iterative conversations with ChatGPT Work and Codex to define the requirements, review the interface, build the application, test it, and refine individual functions. Instead of creating one enormous prompt, I worked in short cycles: describe a problem, implement the change, test it with real data, and improve it. 3. I built the application as a responsive web app that works across computers, tablets, and phones. Access is restricted through authentication, an approved-user allowlist, and server-side authorization because the system contains real personal and professional tasks. 4. I migrated my actual task history rather than starting with an empty demonstration: 238 tasks, 37 categories, 25 subtasks, 5 comments, and 671 activity records. I preserved invalid or disconnected historical records in a separate archive instead of silently deleting them. 5. I connected the application to the OpenAI API. The AI can interpret emails and free-text task descriptions and help turn them into structured, actionable tasks. The application also supports an email-to-task workflow, so actionable emails do not have to remain buried in the inbox. 6. I built a daily Command Center that gives me an overview of what requires attention, including deadlines, priorities, task status, and upcoming work. I use the daily planning view to decide what to focus on rather than simply working through the newest emails. 7. I added two complementary execution views. The task list is useful for searching, sorting, and filtering a larger number of tasks. The Kanban board gives me a visual overview of progress; tasks can be dragged between five status columns, and the new status is saved automatically. The default task list shows the newest tasks first, making newly captured work easy to find. 8. I kept the context inside each task by allowing every task to contain subtasks, comments, attachments, and a complete activity history. This keeps the reasoning, follow-up, and progress connected to a task instead of spreading them across several applications. 9. I automated recurring work and reminders. Recurring tasks are recreated according to their schedule, while deadline reminders help surface tasks before they become overdue. This is particularly useful for responsibilities that are important but easy to forget because they do not arrive as new emails. 10. I run a weekly review to check overdue work, upcoming deadlines, open commitments, and tasks that have stopped moving. I can then reprioritize, update statuses, and prepare the following week from the same system. 11. I preserved portability and control through Excel import and export and a full JSON backup. This gives me control over my information and reduces the risk of becoming dependent on one interface or platform. The result is not an autonomous agent making decisions on my behalf. It is a private execution system where AI handles part of the interpretation and structuring, while I remain responsible for priorities and decisions. It has given me one trusted place for capturing, reviewing, prioritizing, and completing work. The tools I used were: - ChatGPT Work - Codex - OpenAI API

I built AIEnhancer to solve a problem I often encountered when working with low-quality images. Many images contain useful content but are too small, blurry, or lacking in detail to reuse effectively. The project uses AI-based image processing to improve image resolution and recover visual details. I wanted to make the workflow simple: upload an image, process it, and receive an enhanced version without needing professional image-editing software. One challenge was finding the right balance between sharpening details and avoiding artificial-looking results. During development, I experimented with different enhancement approaches and focused on keeping the output natural. I'm still interested in improving enhancement quality for different types of images. I'd like to hear how other developers handle image restoration and super-resolution, especially for difficult or heavily compressed images. Step-by-step: 1. I identified the problem of reusing images that were too small, blurry, or lacking in detail. 2. I built AIEnhancer to process low-quality images with AI-based image enhancement. 3. I designed the workflow around uploading an image, processing it, and receiving an enhanced version. 4. I experimented with different enhancement approaches to improve resolution and recover visual details. 5. I evaluated the results for a balance between sharper details and a natural appearance. 6. I continued exploring ways to improve enhancement quality for different image types, including difficult or heavily compressed images.

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.

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