DEV Community: Chad Dyar

I Found 799 Files in My Google Drive Root. Here's What I Built So It Never Happens Again.

Chad Dyar — Sun, 21 Jun 2026 20:00:02 +0000

I opened Google Drive on a Tuesday afternoon looking for one file. I found everything.

799 files sitting in the root folder. Thirteen years of daily output with no taxonomy, no system, no filing logic. Just the accumulated evidence of creating fast and never pausing to organize what I'd built.

Here's the inventory of what was actually there: sales enablement frameworks built for corporate clients, draft chapters from 17 books (6 published while I held a senior enablement role full-time), app audit logs from the early builds of what became Autonomous Revenue Labs, consulting invoices going back to 2013, cover letters from career transitions, AI training decks I built for internal sessions, and daily writing sessions that didn't become anything.

All of it, flat. One folder. One pile.

The cleanup

The manual sort took two hours. I created a folder structure that matched how I actually work now, not how I assumed I'd work in 2013, and moved everything to its correct location.

The more interesting decision was what I built after.

The real problem with 799 files in root isn't disorganization. It's that I'd built no system for routing output as it was created. The pile is the result of a decade of creating fast, publishing consistently, and treating filing as a problem to solve later.

The solution to "later" is automation.

What I built

I already run a content engine that publishes across 40+ platforms from a Supabase pipeline. The marketing_queue table routes content to Comet, which handles distribution to Mastodon, Pinterest, Medium, Substack, and the rest. The same logic scales to file routing.

For the Drive problem: a classification script (Python, about 120 lines) that reads file names and modification dates, infers content type (enablement doc, book draft, app log, personal writing), and moves to the correct Drive folder. A weekly cron job that checks root for files older than 7 days and routes them. A Supabase log table (file_routing_log) that records every move for audit.

Build time: 3 hours. It will run indefinitely.

Failure modes I hit during testing: files with no modification metadata got routed to a catch-all folder instead of classified correctly. Files with ambiguous names ("notes.doc", "draft.txt") required a content-inspection fallback. Google Workspace files don't have the same metadata structure as uploaded files, so they needed a separate handler.

Current state: handles about 90% of cases automatically. The remaining 10% goes to a review queue in Supabase for manual routing once a week.

The actual lesson

799 files was proof of output. The pile accumulated because I was creating. The problem was the capture layer, not the creation rate.

Most productivity advice targets creation habits. Write every day. Ship consistently. Build in public. All correct. What breaks down at scale isn't the creating. It's the organizing.

The system you build to handle your output after you create it is as important as the habits that produce the output in the first place.

I built ContentForge for the same reason. Reformatting content across 8 platforms was eating the time I should have been using to create more. The solution was automating the reformatting.

Build the system. Create faster. Let the system handle the pile.

What I'd do differently

Build the routing layer on day one of any creative system. Every time. The cleanup cost two hours. Building the router after the fact cost three. Building it at the start would have cost thirty minutes.

The pile is a symptom of the right problem: high output. The fix is infrastructure.

What's next

The content-inspection fallback needs improvement. Currently doing simple keyword matching on file content for ambiguous files. Moving to a lightweight classifier trained on my actual content types. If I get classification accuracy above 95%, I'll open-source the script.

If you're sitting on a similar pile: the root cause is almost always the same. You've been creating. You just need infrastructure to handle what you've built.

Four App Store rejections and what they taught

Chad Dyar — Sun, 21 Jun 2026 20:00:02 +0000

Four App Store rejections and what they taught about shipping. Seed: the specific lessons from each rejection and how they changed the build process.

[AUTO-DOWNGRADED TO PENDING: content validation failed — body too short (149 chars, minimum 200). Write real content and set status to ready manually.]

The Puppy Training Spreadsheet I Built at 2am (And Why It Actually Works)

Chad Dyar — Sun, 21 Jun 2026 16:00:04 +0000

Maya Rudolph turned one last week, and I found myself scrolling through photos from her first month home. There's one of her at eight weeks, sound asleep in a laundry basket. There's another of Tony holding her while she screamed bloody murder during her first bath. And there's a screenshot I took of a frantic Google search: "is it normal for puppy to hate me."

Summer adoptions spike every year. Shelters know it. Veterinarians brace for it. And about six weeks later, the training panic sets in. The problem isn't commitment or love. It's consistency across humans. When I'm saying "off" and Tony's saying "down" and our dog walker is using hand signals, we're not training a dog. We're confusing one.

I built a shared Notion database after the first week of chaos. Nothing fancy. Five columns: Command, Exact Word We Use, Hand Signal (if any), Treat Protocol, and Who's Consistent. We added our dog walker as a collaborator. It took fifteen minutes to set up and it saved us months of undoing mixed messages.

The structure matters less than the agreement. Some people use a shared Google Doc. Others pin a lamout sheet to the fridge. The trainer we worked with suggested Trello because you can add video clips of the correct technique. Pick whatever you'll actually update.

Here's what goes in ours: "Sit" means butt on ground, hand signal is closed fist moving up, treat immediately during learning phase, then intermittent reinforcement after two weeks of consistency. "Off" means all four paws on the floor (we don't use "down" for that because "down" means lie flat). "Place" means go to your bed and stay there. Every person who interacts with the dog regularly has access.

The Lean Six Sigma person in me wants to call this "process documentation." The realistic dog owner in me calls it "the thing that keeps us from yelling different words at a confused animal." Same outcome, less jargon.

We added a notes column later. That's where we track what's working and what needs adjustment. Turns out Maya responds better to a clicker than verbal praise during active training. Wick could not care less about the clicker but will do absolutely anything for freeze-dried liver. Benny just wants everyone to be happy and will sit seventeen times in a row if you forget you already asked.

Build the system before you need it. Your dog won't care about your methodology. But everyone involved will stop undermining each other by accident.

The Algorithm Ate My Tomatoes: What June Harvests Taught Me About Content Distribution

Chad Dyar — Sun, 21 Jun 2026 16:00:03 +0000

My partner Tony walked into the kitchen yesterday holding a colander overflowing with Cherokee Purples and Brandywines. "We have a problem," he said. The tomato plants had done exactly what we wanted them to do. We just hadn't planned for what happens after success.

This is the week every backyard gardener in the Northern Hemisphere faces the same abundance crisis. Search trends for "what to do with too many tomatoes" spike every June like clockwork. Meanwhile, half the posts I'm seeing from thoughtful creators on LinkedIn are getting buried under algorithm shifts that favor... well, whatever the opposite of a home-grown tomato is.

The connection isn't obvious until you've been on both sides of a distribution problem. When you grow something real, whether it's Cherokee Purples or a piece of writing that took you three weeks to refine, you assume the hard part is over. You made the thing. But making it and getting it to the people who need it are completely different challenges.

I spent twenty years in sales enablement before shifting to literary operations. The pattern holds across industries. You can build the best product demo, the most useful documentation, or the most helpful children's book about processing grief (like my current project, The Wiggles, the Woofs, and the Why), but if your distribution strategy is "post and hope," you're counting on an algorithm that doesn't care about your tomatoes.

Here's what actually works, whether you're a gardener with a harvest problem or a creator trying to reach parents searching for social-emotional learning resources: diversification and direct relationships. Tony and I don't just plant tomatoes and wait. We have a preservation plan, neighbor relationships, and a standing arrangement with TechCommuters' community garden network. Same principle applies to content. One platform, one algorithm change, and your reach disappears.

The practical solution isn't complicated. It's just unfashionable. Email lists. RSS feeds. Direct messages to people who've expressed interest. Cross-posting to platforms with different discovery mechanisms like Dev.to, Hashnode, or Medium. Building on your own domain. The same reason we make tomato sauce, salsa, and sun-dried preserves is the same reason I publish the same core message across multiple channels. Different formats, different platforms, different timelines for when someone needs what you made.

Your harvest will rot if you only have one basket.

I Built a Diagnostic Tool to Solve the Problem Every No-Code Platform Skips

Chad Dyar — Sat, 20 Jun 2026 16:00:02 +0000

Six apps live on Vercel. Seventeen books on Amazon. An AI agent network running autonomously. I built all of it. And the thing I couldn't find anywhere was help with the problem that comes before the build.

The build tools are excellent. React, Vite, Supabase, Stripe: I use these daily. They are great at building what you tell them to build. The problem they don't solve: most people don't know what to build. Or they think they do and build the wrong thing. Or they build the right thing and price it wrong. I spent eighteen months on that part.

PIQUE is a two-stage assessment on React 19 / Vite 8 / TypeScript / Supabase. Stage one is a five-question screener. Stage two is fifteen questions across six dimensions. Output: four-archetype scoring engine returning archetype, dimension scores, personalized build sequence, first move. Supabase captures everything. Resend handles welcome email. ConvertKit runs four segmented nurture sequences by archetype.

Architecture decision worth sharing: solve the upstream problem first. What comes before the build is figuring out what the expertise is worth, who will pay for it, and which systems to stand up first. PIQUE lives entirely in that upstream space.

Stack: React 19 / Vite 8 / TypeScript / Tailwind / Supabase / Vercel / Resend / Stripe / Claude API

Why Building With AI Is a Disposition Problem, Not a Skill Problem

Chad Dyar — Fri, 19 Jun 2026 04:00:05 +0000

Here's the thing nobody told me when I started building with AI seriously: the bottleneck was never technical.

I've shipped real apps — real backends, real subscriptions, real users. I built a memory layer that persists decisions across sessions. A supervision system that runs twenty automated checks on a schedule. A nine-agent team that builds, tests, ships, and logs its own mistakes. More than 2,000 agent sessions ran last year, most while I was asleep.

None of that required me to be a better engineer than I was when I started. It required a different set of dispositions.

When plain language became the primary interface, the old technical gate fell. What got left standing was how you think, not what you can build.

Six things separate real AI leverage from noise:

Comfort with unfinished thinking — You have to be willing to bring half-formed problems, not just clean specs. The messy middle is where AI is most useful as a thinking partner.

High tolerance for being wrong, quickly — A wrong output is fast, cheap signal. Treat the first output as a hypothesis. One of my agents once invented a nonexistent dog and tried to publish it. The system caught it. That's the method.

The ability to hold the wheel — AI fills silence. If you're passive, you go wherever it takes you. Knowing what you want and redirecting when output drifts is judgment, not prompting.

Domain depth in at least one area — Generalists get generic outputs because they can't judge what came back. Depth in one domain — any domain — gives you the ability to steer. It transfers across adjacent areas.

A bias toward synthesis over search — Search gets you an answer. Synthesis gets you the thing you didn't know to look for. Connecting across your own work over time is where the compounding starts.

The willingness to be surprised — The best outcomes I've gotten weren't the ones I planned for. Build the thing, then pay attention to what it actually does.

Notice what's missing from that list: technical skill, language choice, output speed. Those are outputs.

The curve accelerates because the work compounds in three directions simultaneously: each build lowers the cost of the next, the dispositions sharpen with use, and eventually the systems start helping you build the next system.

That's when it stops being a line.

I run a nine-seat AI agent operating model by myself.

Chad Dyar — Thu, 18 Jun 2026 23:17:54 +0000

I run a nine-seat AI agent operating model by myself.

Not a team. One person. The seats are: Chief (routing), Analyst (patterns), Builder (app-layer code), Cortex (database and backend), Sub (App Store submissions), Ledger (subscriptions and revenue), Forma (design review), Vera (verification), and Luxe (synthetic user testing).

Each seat has a scope, a job, and a veto condition. The memory layer is thirty-two files, six Supabase tables, four edge functions, and scheduled jobs that ingest and sync across the stack. Every agent session reads the full history before it touches anything.

Two thousand sessions a year. Most while I'm asleep.

Here's what a year of running this taught me about building agent systems:

The thing that builds is biased toward declaring itself done. Ask the same agent to verify its own output and it will tell you it succeeded. Every time. With confidence. Because confidence is cheaper than re-checking. Vera is a separate agent with authority to stop the line. She has caught regressions the builder swore were fixed.

The scaffold lies to you. Generated scaffolding for my iOS projects shipped wrong architecture, wrong permission strings, and on two different apps didn't commit the platform folder to git at all. Pre-archive checklists now run every time. No exceptions.

Build to a contract, not to a tool. Every source in my asset engine plugs into an adapter contract. The engine doesn't know or care what it's talking to. Swap the model, keep the contract. Nothing downstream notices.

Memory in the database, not the model. The context window forgets everything on session end. I keep twelve recurring failure patterns codified with their fixes attached. A problem I've solved once can't re-run on me.

Self-improving loops drift unless you score them. Every optimization loop produces output scored against a threshold. Anything below it gets killed. Autonomy without a kill switch is confident drift at scale.

The thing I keep coming back to: the natural-language interface keeps getting easier. What stays hard is the wiring underneath. The contracts between components. The judgment about whether what came back is any good. The structure that keeps your judgment load-bearing instead of optional.

Happy to share more about the architecture if anyone's building something similar.

Comment: MCP Server for Content Publishing

Chad Dyar — Thu, 18 Jun 2026 21:10:42 +0000

The per-platform field handling problem is where this gets painful in practice. I publish across LinkedIn, Dev.to, email (Kit), and YouTube from a single content pipeline, and the formatting divergence is constant. LinkedIn wants short paragraphs with line breaks. Dev.to expects frontmatter and markdown. Email needs inline HTML with template wrappers. YouTube descriptions have their own character limits and link formatting.

An MCP server that abstracts that away would save me real time. The question I'd push on: does the server own the canonical format, or does each platform adapter? Because if the server tries to be format-neutral, you just move the complexity downstream.

Comment: I Run My Entire SaaS Solo Using 7 AI Agents

Chad Dyar — Thu, 18 Jun 2026 21:10:01 +0000

The part that surprised me running a similar setup (monitoring agent, browser distribution agent, per-channel content agents across LinkedIn, email, YouTube, blog, community) is that the bottleneck doesn't disappear. It relocates. Before agents, most of my time went to doing. Now most of it goes to deciding. Which draft is worth publishing, which engagement signal is a real person vs. bot noise, which channel deserves more allocation this week.

The orchestration layer between agents matters more than any single agent's capability. I ended up building a handoff protocol so one agent's output becomes another's input without me copy-pasting between them. That connective tissue is where the real operational gain lives.

Comment: Claude and React Chatbot Security Fix

Chad Dyar — Thu, 18 Jun 2026 21:09:24 +0000

Good walkthrough for getting started. One flag worth raising: the dangerouslyAllowBrowser: true option exposes your Anthropic API key in the client bundle. Anyone who opens dev tools can grab it and run up your bill.

The production pattern is a thin Express proxy. Your React frontend hits /api/chat instead of the Anthropic API directly. Key stays server-side, you can add rate limiting, and it costs about 10 extra lines of code. I built a chatbot widget this way (React + Express + Claude API) and it's been solid in production.

I Built a Content System That Runs While I Coach

Chad Dyar — Thu, 18 Jun 2026 21:09:23 +0000

Last week my content pipeline published to nine platforms while I ran two coaching sessions, walked three dogs, and went to bed at a normal time.

This is not a flex. It is a description of what I was trying to build when I started ContentForge, and why it is worth writing down now that it is working.

The problem it solves: I publish across LinkedIn, Mastodon, Pinterest, Substack, Medium, Dev.to, IndieHackers, Quora, and a personal blog. I have 17 books that need regular promotion. I run six web apps. I hold a senior enablement role full-time. Manually writing platform-specific content was consuming three to four hours every week, inconsistently.

ContentForge takes a single story and produces platform-appropriate versions for each channel. A LinkedIn post reads like a LinkedIn post. A Dev.to article has technical framing a Dev.to audience wants. A Pinterest pin has the SEO structure Pinterest requires.

The technical reality: Vercel-hosted app with a Supabase backend. The AI generation takes a seed input, extracts the relevant elements (the feeling, the insight, the tension, the proof), and generates platform variants. Output goes into a marketing queue table in Supabase. A local Python process called Clawbot watches the queue and drives publication.

AI generation happens at content creation time. Publication is async and does not require inference on the publish side. This keeps the publish process simple and the AI costs bounded.

What I got wrong first: the initial version tried to generate from topics. The output was technically correct and completely lifeless. Topics are not seeds. Moments are seeds.

The second version required a specific story as input. That changes everything about output quality.

The third version, which runs now, extracts story elements before generating. The moment, the feeling, the insight, the proof, the tension. If you cannot name those elements, you do not have a seed yet.

Numbers from this week: nine platform assets generated from one seed. Total active time on content: approximately 45 minutes reviewing before publish. Previous approach: three hours for the same volume, with worse platform-native quality.

ContentForge is at contentforgehq.com. The queue architecture is straightforward. Happy to share more detail if useful.

Dev.to article: Three months running 6 apps. Here's what actually happened. Real distribution data — Quora drove real traffic, d

Chad Dyar — Wed, 17 Jun 2026 16:25:21 +0000

Dev.to article: Three months running 6 apps. Here's what actually happened. Real distribution data — Quora drove real traffic, directory submissions drove nothing, Show HN 0 comments. Momentum $7.99 MRR. Honest builder reflection. ~800 words.