DEV Community: Chad Dyar

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.

Four App Store rejections and what they taught about shipping.

Chad Dyar — Wed, 17 Jun 2026 16:10:33 +0000

Four App Store rejections and what they taught about shipping.

I built six web apps over the last decade. Four of them hit the App Store. Three of those four got rejected on the first submission. The fourth one sailed through, which taught me more than the rejections did because I could actually see what I'd done differently.

The first rejection came back with a note about "unclear purpose." I'd built something I understood perfectly because I lived in it every day. The reviewer had thirty seconds and a feature list that read like someone solving their own problem, not anyone else's. I rewrote the app description to start with the problem the app solved, not the tool itself. The resubmission cleared.

The second one was about payment. I'd set up in-app purchases the way I thought made sense. Apple disagreed. The guidelines are specific about how you implement subscriptions, and I'd skipped a step that seemed redundant. I thought I was being efficient. Apple thought I was being incomplete. Adding that step took two hours. It was the kind of thing that would have been obvious if I'd read the docs instead of skimmed them.

The third rejection stung because it wasn't about functionality. It was about imagery. I'd used a screenshot that included an interface element from another app. Not intentionally. Just screenshot overlap. The reviewer caught it. I thought it was invisible. It wasn't. That one taught me the difference between what you see when you build something and what a stranger sees when they look at it fresh.

The fourth app didn't get rejected. I'd learned by then what "clear" meant to someone else. Clear isn't clever. Clear isn't what makes sense to you. Clear is what makes sense to someone who's never seen your work and has no reason to care about it until you give them one.

Those rejections weren't failures. They were a conversation with the gatekeepers between your idea and the people who need it. Most of the time, they're right. Even when they feel arbitrary, they're usually protecting something real (app quality, user clarity, payment trust). Fighting them wastes time. Learning from them ships faster.

The difference between "this shouldn't happen" and "this cannot happen" in AI content pipelines

Chad Dyar — Wed, 17 Jun 2026 12:18:04 +0000

About three weeks ago I finished organizing something I had been avoiding for years. Two hundred and twenty-six files across my local drive, Google Drive, and a decade's worth of downloads. North of 1.2 million words with no index, no structure, and no way to find anything unless I remembered exactly what I named it.

I turned it into a queryable knowledge base, connected it to a Supabase project, and wired it to the content pipeline I use to run my apps and books. The system I built to write about this actually used the system it was describing to find source material. That part worked exactly as intended.

What almost didn't work was the security gate.

The problem with filters

When you give an AI agent access to a personal archive, you have two options for what it can see: you can filter, or you can wall.

Filtering means the query returns only certain rows. Walling means the agent structurally cannot reach the rows you want hidden. They look identical from the outside. The difference shows up when something breaks.

Here's the setup. I have a moments table in Supabase holding personal writing fragments, scenes, drafts, and notes. Some of it is clearly public and canonical. A lot of it is private, early, or structurally wrong for any agent to touch. I wanted AI content agents to pull only from verified public material.

The obvious solution: create a view.

CREATE VIEW public_seeds AS
  SELECT * FROM moments
  WHERE visibility  = 'public'
    AND is_canonical = true;

This looks right. It returns only rows where both conditions are true. But there's a problem that isn't obvious until you've read enough Postgres documentation at 11pm: by default, a Postgres view runs as the view owner, not the calling role.

That means row-level security doesn't apply. The view owner (usually your service role) has full table access, and the view inherits it. Your RLS policy exists, but the view bypasses it entirely, running as the owner. You've written a filter, not a wall.

"This shouldn't happen" and "this cannot happen" are not the same sentence.

The fix: security_invoker

PostgreSQL 15 added a security_invoker option for views. When you set it to true, the view runs as the calling role instead of the owner. RLS applies normally. The view stops being a filter and becomes a structural gate.

The correct version:

CREATE TABLE moments (
  id           TEXT     PRIMARY KEY,
  title        TEXT,
  content      TEXT,
  visibility   TEXT     CHECK (visibility IN ('public', 'private', 'restricted')),
  is_canonical BOOLEAN,
  source_file  TEXT,
  themes       TEXT[]
);

-- Without security_invoker = true, this view runs as the VIEW OWNER.
-- The owner has full table access. RLS does not apply.
-- security_invoker = true switches to the CALLING role, so RLS applies normally.
CREATE VIEW public_seeds
  WITH (security_invoker = true)
AS
  SELECT * FROM moments
  WHERE visibility  = 'public'
    AND is_canonical = true;

ALTER TABLE moments ENABLE ROW LEVEL SECURITY;

CREATE POLICY "public_only" ON moments
  FOR SELECT
  USING (visibility = 'public' AND is_canonical = true);

Now the wall is structural. A content agent calling public_seeds cannot reach private rows even if it tries to work around the view, even if the query is malformed in an interesting way, even if a future developer adds a join without thinking about it. The RLS policy enforces at the table level. The view is just a convenience wrapper on top of something that already holds.

Why this matters more when agents are involved

With a human querying a database, a filter is usually fine. Humans read error messages. They notice when results look wrong. They ask questions.

AI agents don't do any of those things. An agent that gets back more rows than it should doesn't know it got more rows than it should. It works with what it received. If your filter fails silently, the agent's behavior changes without any visible signal that something went wrong.

This is the core reason "this shouldn't happen" is architecturally insufficient when agents are in the loop. "Shouldn't" relies on correctness. "Cannot" relies on structure. Structure holds when correctness fails, when a query is written differently than expected, when a dependency changes, when a future developer adds a new code path that doesn't know about the filter.

For my pipeline specifically, the public_seeds view is the only surface area agents are allowed to touch. Private drafts, unpublished scenes, personal notes, things I wrote during a difficult year that I'm not ready to do anything with yet: none of that is reachable. Not because a query filters it out. Because the architecture prevents it from being returned at all.

What I'd do differently

The security_invoker flag is a PostgreSQL 15 feature. If you're running an older version or you haven't checked your Supabase project's Postgres version recently, you may not have it. The alternative is to manage access through the role system directly: create a dedicated read-only role for agents, grant it explicit SELECT on only the rows you want exposed, and never connect agents using the service role.

The service role bypasses RLS by design. If your agents are connecting with the service role key, no amount of view filtering will protect you. That's the first thing to check.

The second thing to check is whether any existing views in your schema were created before you thought carefully about security. Views created without security_invoker predate any RLS policy you add later. The policy won't retroactively apply to them.

The third thing I'd do differently: name the gate something explicit. public_seeds is clear enough, but I've started prefixing agent-facing views with agent_ so it's obvious at a glance what was designed for machine consumption versus human use. Small thing. Saves confusion later.

The knowledge base is running. The archive has a few hundred public moments indexed and retrievable. The content that came out of it is genuinely better for having source material to work from, which is the whole argument for building the thing in the first place.

The part that almost derailed it was a 13-word clause in a CREATE VIEW statement. Worth knowing before you wire anything up.

Three months running 6 apps. Here's what actually happened.

Chad Dyar — Sun, 14 Jun 2026 00:19:41 +0000

The honest version of a "build in public" post is the one you write when the numbers aren't what you expected.

Three months ago I shipped six apps in about six weeks. Momentum, PawFormance, PillPal, HomeGrown, Palette Pro, ContentForge. All live. All working. One paying subscriber across the whole portfolio at month one.

Here's what I learned.

The apps weren't the problem. Distribution was.

I built each app to solve a real problem I had or watched someone have. Momentum came from tracking my own workouts badly. PillPal came from watching my mother manage medications in a way that scared me. HomeGrown came from a garden spreadsheet that was getting embarrassing.

The apps work. They do what they say they do. The problem is that almost nobody found them.

Six months of Google Analytics data: direct traffic to five of the six apps is essentially zero. The two apps with real traffic — Momentum and HomeGrown — have it because I posted two answers on Quora. Not because of any launch strategy. Because I answered two questions that people were actually searching for.

That's the whole lesson: search intent > launch energy.

What I tried

Show HN posts (2 posts, 0 comments each — posted on a weekend, classic mistake)
Directory submissions across BetaList, SaaSHub, AlternativeTo, Uneed (all pending or no visible traffic)
Dev.to articles (this one included) — some SEO value, slow build
Mastodon presence (strong community engagement, zero app traffic)
LinkedIn posts about the build process (engagement but no conversion; wrong audience for the apps)

What actually worked

Two Quora answers that directly addressed the search query someone was already running
One Medium article that ranked for a specific keyword within two weeks

That's it. That's the whole list.

What month three looks like

Momentum: $7.99 MRR, 1 paying subscriber. That's not a mistake — that's one person who found the app and decided it was worth paying for.

ContentForge: free tier users, 0 paid. The free tier is active enough that I know the product works. The conversion problem is a pricing and messaging problem, not a product problem.

Everything else: free users acquired via the Quora channel, slow trickle.

What I'm doing differently

More Quora. More specific subreddit posts framed around the problem, not the product. One technical article per app on Dev.to optimized for the search query, not for the build story.

The build story is interesting to other builders. The search query is interesting to the person who has the problem. Those are mostly different people.

If I started over: I'd write the Quora answer before I wrote the app.

Real impact at work starts with authenticity. Surviving a heart attack taught me to live fully,not just play a role. ...

Chad Dyar — Thu, 11 Jun 2026 23:11:27 +0000

Real impact at work starts with authenticity. Surviving a heart attack taught me to live fully,not just play a role. My book 'Bring Your Best Self To Work' dives into how being yourself leads to better performance and satisfaction at work.

https://www.chadtdyar.com/books/bring-your-best-self-to-work

Breathing intentionally changed my life on an operating table. It connects our actions, whether singing or leading a ...

Chad Dyar — Thu, 11 Jun 2026 23:09:45 +0000

Breathing intentionally changed my life on an operating table. It connects our actions, whether singing or leading a team. I explore this in "The Deliberate Breath."

https://www.chadtdyar.com/books/the-deliberate-breath

Performance isn't just about hitting numbers. It's about people.

Chad Dyar — Thu, 11 Jun 2026 23:09:44 +0000

Performance isn't just about hitting numbers. It's about people.

My book, 'Performance is Personal,' explores how to create environments where individuals thrive. Inspired by real experiences, it might just resonate with you.

https://www.chadtdyar.com/books/performance-is-personal