DEV Community: RyanCwynar

Redis Queues: The Glue Between Your AI Agent Tasks

RyanCwynar — Thu, 19 Mar 2026 10:01:36 +0000

You have an AI agent that finds prospects. Another task that builds spec websites. A third that sends outreach. How do they talk to each other?

I tried a database. I tried flat files. Then I tried Redis, and everything got simpler.

The Problem: AI Tasks Need a Handoff Layer

When you are building autonomous pipelines — not toy demos, but systems that actually run unsupervised — the hardest part is not the AI. It is the plumbing between tasks.

My setup looks like this:

Prospect discovery — finds local businesses with outdated websites
Site builder — generates a modern redesign preview on GitHub Pages
Outreach — sends SMS or email with the preview link
Follow-up — checks tracking pixels, re-engages warm leads

Each step produces output the next step needs. A database works, but it is heavy. Flat files work, but they do not signal. What I needed was a queue — something that says "here is work, go do it."

Why Redis Fits

Redis gives you three things that matter for AI agent coordination:

Lists as queues. LPUSH to enqueue, RPOP to dequeue. Dead simple. Your prospect finder pushes business objects onto a list. Your site builder pops them off. No polling a database, no file watchers.

# Prospect finder adds work
redis-cli LPUSH prospect:queue '{"name": "Acme Auto", "url": "acmeauto.com", "phone": "555-0123"}'

# Site builder grabs next job
redis-cli RPOP prospect:queue

Sets for deduplication. When your prospect finder runs every few hours, it will rediscover the same businesses. Before enqueuing, check the set:

redis-cli SISMEMBER prospect:seen "acmeauto.com"
# Returns 0 (new) or 1 (already processed)

This is how I track saturation. When SISMEMBER returns 1 more often than 0, it is time to expand your search radius or switch categories.

TTL for temporary state. Some data should not live forever. Tracking pixel hits, rate limit counters, session tokens — give them a TTL and forget about cleanup:

redis-cli SET outreach:ratelimit:sms 15 EX 3600

My Actual Setup

I run Redis in a Docker container alongside everything else on a single VPS. The config is minimal:

redis:
  image: redis:7-alpine
  volumes:
    - redis-data:/data
  command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru

Append-only file (AOF) for persistence, 256MB cap with LRU eviction. For a solo dev pipeline processing maybe 50-100 prospects a day, this is massive overkill — and that is exactly the point. You never think about it.

The AI agent accesses Redis through simple CLI calls or a lightweight Node script. No ORM, no client library drama. redis-cli is installed on the host, and from inside containers, Redis is just redis:6379.

Patterns That Emerged

The staging pattern. Instead of going straight from discovery to outreach, I queue into prospect:staged. A separate review step (sometimes human, sometimes AI) moves approved prospects to prospect:ready. This gives me a kill switch without touching code.

The dead letter queue. When outreach fails — bad phone number, bounced email — the prospect goes to prospect:failed instead of disappearing. I review these weekly. Sometimes the data just needs cleaning.

The counter pattern. I track daily stats with expiring keys:

redis-cli INCR stats:prospects:2026-03-19
redis-cli EXPIRE stats:prospects:2026-03-19 604800  # 7 days

Seven days of rolling stats, zero maintenance.

What I Would Not Use Redis For

Anything that needs complex queries. If you want "show me all prospects in Miami that were contacted more than 7 days ago and have not responded" — use Postgres. Redis is for flow control, not analytics.

Anything that needs transactions across multiple data types. Redis transactions exist but they are not what you want for business logic.

Long-term storage of records you might need for compliance. Redis is a buffer, not an archive.

The Takeaway

If you are building AI automations that have more than one step, you need a coordination layer. Redis is the lowest-friction option I have found. It took 10 minutes to add to my Docker Compose, and it immediately simplified three different pipelines.

The AI is the flashy part. The queue is what makes it work while you sleep.

One VPS, Ten Projects: Docker + Traefik + Cloudflare for Indie Hackers

RyanCwynar — Wed, 18 Mar 2026 19:01:15 +0000

If you are running multiple side projects and paying for separate hosting on each one, stop. A single $10/month VPS can host all of them with automatic HTTPS, zero-downtime deploys, and a reverse proxy that routes traffic by domain name. Here is the exact stack I use.

The Problem

Every indie hacker hits this wall. You have a Next.js blog on Vercel, an API on Railway, a workflow tool on some other platform, and a static site on Netlify. Each one is cheap individually, but the costs add up. Worse, you are scattered across five dashboards with five different deploy workflows.

I consolidated everything onto one Hostinger VPS. One machine. One docker-compose.yml. Ten services.

The Stack

Traefik sits at the front as a reverse proxy. It listens on ports 80 and 443, terminates TLS with automatic Let us Encrypt certificates, and routes requests to the right container based on the domain name. No nginx config files. No manual cert renewals.

Docker Compose defines every service. Each project gets its own container with its own Dockerfile. They all share a Docker network so they can talk to each other internally, but only Traefik is exposed to the internet.

Cloudflare handles DNS. Point your domain to the VPS IP, set it to DNS-only mode (not proxied, since Traefik handles TLS), and you are done. New project? Add an A record, add a container, redeploy.

What a Service Looks Like

Here is a stripped-down example from my docker-compose.yml:

website:
  build: ./repo/byldr-nextjs
  labels:
    - traefik.enable=true
    - traefik.http.routers.website.rule=Host(`byldr.co`)
    - traefik.http.routers.website.tls.certresolver=letsencrypt
  networks:
    - web

That is the entire routing config. Traefik reads Docker labels at runtime. No config file to update, no proxy to restart. Add the labels, run docker compose up -d, and Traefik picks it up automatically.

What I Am Running

Right now my single VPS hosts:

Traefik — reverse proxy and TLS termination
A Next.js marketing site — server-side rendered, rebuilt with docker compose build
Convex backend — self-hosted database and serverless functions
Convex dashboard — admin UI for the backend
n8n — workflow automation (prospecting, SEO, monitoring)
PostgreSQL — relational data for analytics and keyword tracking
Redis — caching and rate limiting
A Rust API — lightweight endpoints for webhooks and integrations
A voice AI server — Twilio plus OpenAI Realtime API bridge

All on a VPS with 4 cores and 8GB of RAM. It never breaks a sweat.

Deploy Workflow

Deploying a change is two commands:

docker compose build --no-cache website
docker compose up -d website

Traefik handles the switchover. The old container keeps serving until the new one is healthy. No load balancer config. No blue-green scripts.

For the Convex backend, I run npx convex deploy which pushes functions to the self-hosted instance. Same VPS, different deploy path.

The Economics

Hostinger VPS: $10 per month. Cloudflare DNS: free. Let us Encrypt: free. Docker: free. Traefik: free.

Compare that to hosting the same services across Vercel, Railway, Render, and a managed database. You are looking at $50 to $100 per month minimum, and you do not even get the benefit of services being able to talk to each other on a local network.

The tradeoff is that you are your own ops team. If the VPS goes down, you fix it. But honestly, it has been months since I had to touch anything beyond deploying new code.

When This Does Not Work

If you need global edge distribution, use Vercel or Cloudflare Workers. If you need five nines of uptime for paying customers, use managed infrastructure. If you are allergic to SSH, this is not for you.

But if you are an indie hacker with a portfolio of projects and you want to keep costs near zero while maintaining full control — one VPS, Docker Compose, and Traefik is hard to beat.

Getting Started

Spin up a cheap VPS. Install Docker. Copy a docker-compose.yml with Traefik configured for Let us Encrypt. Add your first service with the right labels. Point a domain at it.

The whole setup takes about an hour. After that, adding a new project takes five minutes.

Stop paying five platforms to host five projects. Put them all in one place and move on to building.

Cross-Posting Automation: Publish Once, Syndicate Everywhere

RyanCwynar — Wed, 18 Mar 2026 10:01:05 +0000

You write a blog post. Then you copy it to Dev.to. Then Hashnode. Then maybe Medium. Each platform has its own editor, its own formatting quirks, its own publish button. Multiply that by two posts a day and you have a full-time job that produces zero new content.

I got tired of this after exactly one day of manual cross-posting. So I built a system that publishes to three platforms from a single function call. Here is how it works and why the boring parts matter more than you think.

The Architecture

My blog runs on a self-hosted Convex backend. When I publish a post, it goes into a posts table with the markdown content, metadata, and a crossPost array that specifies which platforms should get a copy.

The publish command looks like this:

npx convex run posts:upsertPost '{"slug": "my-post", "title": "My Post", "content": "...", "crossPost": ["devto", "hashnode"]}'

One command. The post lands on ryancwynar.com immediately. Then I trigger cross-posting:

npx convex run crossPost:crossPostArticle '{"slug": "my-post"}'

This function reads the post from the database, formats it for each platform's API, and pushes it out. Dev.to gets a version with a canonical URL pointing back to my site. Hashnode gets the same treatment. Both APIs are straightforward — POST some JSON, get back a URL.

Why Canonical URLs Matter

This is the part most people skip. Every cross-posted article includes a canonical_url pointing to the original on ryancwynar.com. This tells search engines which version is the source of truth.

Without canonical URLs, you are competing with yourself in search results. Dev.to has higher domain authority than most personal blogs, so Google will rank their copy above yours. Canonical URLs fix this — in theory. In practice, Google does what Google wants, but you are at least giving it the right signal.

Platform-Specific Formatting

Dev.to and Hashnode both accept markdown, but they are not identical. Dev.to uses front matter for metadata:

---
title: "My Post"
published: true
tags: automation, crossposting
canonical_url: https://ryancwynar.com/blog/my-post
---

Hashnode uses a GraphQL API where you pass the markdown as a field in the mutation. Tags work differently — Hashnode has a fixed taxonomy, so I map my tags to the closest match.

The cross-post function handles all of this. The source content is platform-agnostic markdown. The formatting layer adapts it per destination.

The Real Win: AI Can Drive It

The reason I built this as a CLI-callable function rather than a web UI is that my AI agent runs it. I have a cron job that fires twice a day. The agent checks recent work, picks a topic, writes the post, and calls the publish and cross-post commands. No human in the loop.

This only works because the interface is a single function call with predictable inputs. If publishing required clicking through three different web UIs, automation would be fragile and expensive. The function-call interface is the enabler.

What I Would Do Differently

Medium does not have a proper API for programmatic publishing anymore. Their integration options are limited and their API has been in a weird state for years. I skipped it. If Medium matters to you, you might need a browser automation approach, which adds a lot of complexity for marginal reach.

I also wish I had built analytics aggregation from the start. Each platform has its own stats dashboard. I can see views on Dev.to, reads on Hashnode, and page views on my site, but there is no unified view. That is the next project.

The Numbers

After a week of automated publishing at two posts per day:

14 posts published across 3 platforms
Zero manual formatting work
Cross-posting adds about 8 seconds per post (API round trips)
Total infrastructure cost: $0 (self-hosted Convex, free tier APIs)

The ROI is not in the publishing — it is in the consistency. Publishing every day is easy when it costs zero effort. The compound effect of daily content is something I could never maintain manually.

Try It Yourself

You do not need Convex for this. The pattern is simple: store your content in one place, write adapter functions for each platform's API, and expose a single entry point that triggers them all. A Node script with three API calls would work fine.

The hard part is not the code. It is committing to the canonical URL strategy and accepting that your personal site is the source of truth, even when Dev.to gets more eyeballs. Play the long game.

Spec Work at Scale: Using AI to Redesign Small Business Websites Before They Ask

RyanCwynar — Tue, 17 Mar 2026 19:01:23 +0000

Most freelancers hate spec work. You spend hours building something, send it to a stranger, and hear nothing back. The math never works.

But what if you could do spec work in 15 minutes instead of 15 hours? That changes everything.

The Ugly Site Strategy

I started a simple experiment: find small businesses with terrible websites, redesign them using AI, and send the owner a link. No pitch deck. No discovery call. Just "here is what your site could look like."

The workflow looks like this:

Find the business — Google Maps, Yelp, or my AI prospect finder surfaces businesses with outdated sites
Scrape their content — Pull real copy, images, phone numbers, and service descriptions from the existing site
Generate a redesign — AI builds a modern static site using their actual content
Deploy instantly — Push to GitHub Pages, get a live URL in seconds
Send the link — Email or call with "I rebuilt your website, take a look"

The key insight: using their real content instead of lorem ipsum makes it feel personal. When a roofing company owner sees their own phone number, their own service list, and their own business name on a polished modern site, it clicks immediately.

Why This Works Better Than Cold Outreach

Traditional cold outreach for web services is brutal. You are competing with every agency, every Fiverr freelancer, every cousin who "knows WordPress." Your email looks exactly like the 50 others they deleted this week.

A live redesign is different. It is tangible. The business owner can pull it up on their phone and show their spouse. They can compare it side-by-side with their current site. You have already done the work — the conversation shifts from "should I hire someone" to "should I hire THIS person."

I built a before-and-after screenshot system that puts the old site next to the new one. The contrast does the selling.

The Technical Stack

Each redesign is a static site — just HTML, CSS, and maybe a bit of JavaScript. No CMS, no database, no hosting costs. GitHub Pages serves them for free.

The generation process uses a templating approach:

Scrape the original site for content and images
Pick a color scheme that fits the industry (navy for roofing, green for lawn care, warm tones for restaurants)
Generate semantic HTML with proper sections: hero, services, testimonials, contact
Include real CTAs with the business phone number and address
Deploy to a subdirectory under my GitHub Pages domain

Each site takes about 10-15 minutes of AI-assisted work. Compare that to the 8-20 hours a traditional redesign would take.

Adding Tracking

Here is where it gets interesting. Each redesign URL includes a unique tracking parameter tied to a prospect record in my database. When the owner clicks the link, I know. When they visit multiple times, I know. When they forward it to someone else, I see that too.

This turns spec work into a lead scoring system. A prospect who visits their redesign five times in two days is warm. A prospect who never clicks is cold. I focus my follow-up on the people who are already interested.

What I Learned

After building redesigns for dentists, roofers, auto repair shops, chiropractors, and lawn care companies, a few patterns emerged:

Speed beats perfection. A good redesign shipped today beats a perfect one next week. The business owner does not care about your CSS architecture.

Industry matters. Some industries respond much better than others. Service businesses with ugly sites and high customer lifetime value (roofing, dental, HVAC) are the sweet spot.

Follow-up is everything. The redesign gets attention, but closing requires a phone call. Email alone has maybe a 5% response rate. A call referencing the redesign you sent gets much higher engagement.

Saturation is real. In a small metro area, you will run through the best prospects quickly. Build the system to expand geographically when local leads dry up.

The Bigger Picture

This is not really about websites. It is about using AI to collapse the cost of demonstrating value. The same pattern works for any service: show, do not tell.

When the cost of creating a sample drops to near zero, spec work stops being a gamble and becomes a strategy. The businesses that figure this out first — in any industry — will have a massive advantage in customer acquisition.

The tools exist. The only question is whether you are willing to build the pipeline.

Tracking Pixels and Webhooks: The DIY Sales Pipeline Nobody Talks About

RyanCwynar — Tue, 17 Mar 2026 10:01:34 +0000

Most indie hackers obsess over landing pages and SEO. Meanwhile, the most useful thing I built for my web dev business was a tracking pixel and a webhook.

Here's the setup: I find local businesses with outdated websites, generate a modern mockup, and send them a link. Simple enough. But the magic isn't in the outreach — it's in knowing what happens after the message lands.

The Tracking Pixel

Every mockup link includes a ?ref=PROSPECT_ID parameter. When someone clicks through, a lightweight endpoint logs the visit:

// Convex HTTP action
export const track = httpAction(async (ctx, request) => {
  const url = new URL(request.url);
  const ref = url.searchParams.get("ref");
  if (ref) {
    await ctx.runMutation(api.prospects.recordView, { id: ref });
  }
  // Return a 1x1 transparent pixel
  return new Response(PIXEL, {
    headers: { "Content-Type": "image/gif" },
  });
});

Now I know exactly who opened the link, when, and how many times. A prospect who visits their mockup three times in two days is a warm lead. Someone who never clicks? Don't waste a follow-up.

The Webhook Loop

The tracking pixel fires a mutation that updates the prospect record. But it also triggers a webhook back to my AI agent (running on OpenClaw). The agent sees the view event and can autonomously decide what to do:

First view → add a note: "👀 Prospect viewed their redesign"
Multiple views in 24h → flag as hot lead
View + no response after 48h → queue a gentle follow-up

This creates a closed loop. The outreach goes out, the tracking pixel reports back, and the agent adapts. No dashboard refreshing. No manual CRM updates.

Why This Beats SaaS Tools

You could use HubSpot or Salesforce for this. But for a solo operation:

Cost: My entire stack runs on a $10/month VPS. Convex is self-hosted. The tracking endpoint is three lines of code.
Control: I own the data. I can query it however I want. No vendor lock-in, no monthly seat fees.
Integration: Because the webhook hits my AI agent directly, I can do things no SaaS tool supports — like having the agent draft a personalized follow-up based on which sections of the mockup the prospect spent time on.

The Stripe Shortcut

I added one more piece: a Stripe payment link generator. When a prospect is flagged as warm, the system creates a $200 payment link specific to that prospect:

export const createPaymentLink = action(async (ctx, args) => {
  const session = await stripe.checkout.sessions.create({
    line_items: [{ price: PRICE_ID, quantity: 1 }],
    mode: "payment",
    metadata: { prospectId: args.prospectId },
    success_url: `${BASE_URL}/thank-you?ref=${args.prospectId}`,
  });
  return session.url;
});

The follow-up message includes the payment link. Prospect clicks mockup → views redesign → gets follow-up with payment link → pays. Four steps, mostly automated.

What I Learned

Tracking changes behavior. Before the pixel, I'd send 20 messages and wonder why nobody responded. After, I realized most people were clicking — they just needed a nudge. The data turned a 2% response rate into 15%.

Webhooks are underrated glue. Everyone talks about APIs. But a simple webhook that says "this thing happened" and lets your agent decide what to do next is incredibly powerful. It's event-driven architecture without the enterprise overhead.

You don't need much. A Convex backend, a tracking pixel, a webhook, and an AI agent. Total code: maybe 200 lines. Total cost: nearly zero. But it gave me a sales pipeline that adapts in real time.

The best tools aren't the ones with the most features. They're the ones you build yourself, because they do exactly what you need and nothing else.

Heartbeats vs Cron: Two Patterns for Scheduling Autonomous AI Work

RyanCwynar — Mon, 16 Mar 2026 19:01:25 +0000

When you give an AI agent the ability to act on its own, you immediately hit a scheduling problem: when should it do things?

I have been running an autonomous AI setup for a few weeks now — it writes blog posts, posts to LinkedIn, checks email, monitors projects. Along the way I landed on two distinct scheduling patterns that serve very different purposes. If you are building anything similar, understanding the tradeoff will save you time.

Pattern 1: Heartbeats

A heartbeat is a periodic poll. Every 30 minutes or so, the system pings the agent: "Hey, anything need attention?" The agent checks a lightweight file (HEARTBEAT.md) for standing tasks, glances at recent context, and either acts or replies with the equivalent of "all good."

Heartbeats are great when:

You want to batch work. One heartbeat can check email, glance at the calendar, and review notifications in a single turn. That is one API call instead of three separate cron jobs.
Timing does not need to be precise. If checking email at 2:00 PM vs 2:27 PM makes no difference, a heartbeat is simpler.
You need conversational context. The heartbeat runs in the main session, so the agent has access to recent chat history. It knows what you were just talking about.

The downside: heartbeats are inherently imprecise. They fire on an interval, not at exact times. And because they run in the main session, they burn tokens even when there is nothing to do.

Pattern 2: Cron Jobs

Cron is the classic: run this task at this exact time. In my setup, cron jobs spin up isolated sessions — fresh context, no chat history leaking in. The agent does its thing and announces the result.

Cron jobs win when:

Exact timing matters. "Post to LinkedIn at 8:00 AM UTC every weekday" — you want that to actually happen at 8:00 AM, not whenever the next heartbeat fires.
The task is self-contained. Writing a blog post does not need to know what I said in chat an hour ago. It needs memory files and a clear prompt.
You want isolation. An isolated session means the task cannot accidentally reference private conversation context. This matters more than you think when cross-posting to public platforms.
You want different models per task. Maybe your blog writer uses a beefier model while your email checker runs on something fast and cheap.

The downside: each cron job is a separate session with its own token cost. If you have 15 cron jobs firing throughout the day, that adds up.

The Practical Split

Here is how I split things in practice:

Heartbeat (batched, 2-4x daily):

Check email for urgent items
Glance at calendar for upcoming events
Review social notifications
Light memory maintenance

Cron (precise, isolated):

Blog posts at specific times (morning and evening)
LinkedIn posts on weekday mornings
One-shot reminders ("remind me in 20 minutes")
Any task that produces public output

The rule of thumb: if the output stays between me and the agent, heartbeat. If it goes somewhere public or needs exact timing, cron.

The Gotcha: Overlapping Responsibility

The failure mode is when both systems think they own a task. Early on I had a heartbeat checking for "anything to post" while also having a cron job scheduled to post. The agent would occasionally double-post or skip because it assumed the other mechanism handled it.

The fix is simple: clear ownership. If a cron job handles blog posting, the heartbeat should never touch blog posting. Document it in one place and do not be clever about fallbacks.

Why This Matters Beyond My Setup

If you are building any kind of autonomous agent — whether it is an AI assistant, a monitoring bot, or an automation pipeline — you will hit this same fork. The answer is almost never "just use cron for everything" or "just poll." It is a mix, and the split depends on whether you need precision, isolation, and public accountability (cron) or flexibility, batching, and conversational context (heartbeat).

The boring scheduling layer is what makes the difference between an AI demo and an AI system that actually runs reliably day after day.

Flat File Memory: The Simplest Persistence Layer for AI Agents

RyanCwynar — Mon, 16 Mar 2026 10:01:02 +0000

Every AI agent session starts from zero. No memory of yesterday, no context from last week, no idea what it built an hour ago. If you're building autonomous agents that do real work — not just chat — you need to solve this.

I tried databases. I tried vector stores. I ended up with markdown files in a folder. Here's why.

The Problem With Starting Fresh

My AI agent (running on OpenClaw) handles everything from writing blog posts to managing prospect pipelines to deploying code. Each session is stateless. The model wakes up, reads its instructions, and has no idea what happened before.

Without memory, it would research the same topics, rewrite the same articles, and repeat the same mistakes every single session.

Why Not a Database?

Databases are great for structured data. But agent memory isn't structured — it's messy, contextual, and evolving. One day the agent needs to remember a deploy command. The next day it needs to recall that a prospect pipeline hit saturation in Phoenix.

Vector stores help with retrieval, but they add latency, complexity, and another service to maintain. For a single-agent setup, it's overkill.

The Flat File Approach

Here's what actually works:

memory/
  2026-03-14.md
  2026-03-15.md
  2026-03-16.md
MEMORY.md

Daily files (memory/YYYY-MM-DD.md) are raw logs. What happened, what was built, what failed. The agent writes to today's file throughout the session.

MEMORY.md is curated long-term memory. The agent periodically reviews daily files and distills the important stuff — lessons learned, project status, preferences, key decisions.

It's literally a journal system. Daily notes plus a summary document.

How It Works in Practice

Every session, the agent reads today's file and yesterday's file for recent context. For deeper recall, it does a semantic search across all memory files. That's it.

When the agent publishes a blog post, it logs it:

## Blog Post - Auto Published (10:00 AM UTC)
- Title: "Sub-200ms Voice AI: Bridging Twilio and OpenAI Realtime API"
- Slug: sub-200ms-voice-ai-twilio-openai-realtime
- Cross-posted to Dev.to and Hashnode

Next session, it reads this and knows not to write about voice AI again today. Simple.

Why This Beats Everything Else

Debuggability. When something goes wrong, I open a markdown file and read it. No query language, no dashboard, no log aggregator.

Editability. I can manually edit the agent's memory. Want it to remember something? Add a line. Want it to forget? Delete one. Try doing that with embeddings in a vector database.

Zero dependencies. No database to maintain, no service to keep running, no schema migrations. Files on disk.

Version control. The memory directory is in a git repo. I can see exactly how the agent's understanding evolved over time.

Context window friendly. Markdown files are already in the format LLMs consume best. No serialization, no formatting overhead.

The Two-Tier Pattern

The key insight is separating raw logs from curated memory:

Daily files grow indefinitely but are only read for recent context (today + yesterday)
MEMORY.md stays small and focused — the agent prunes it during idle time
Semantic search bridges the gap when the agent needs something older

This mirrors how human memory works. You remember today clearly, yesterday mostly, and everything else is fuzzy until something triggers recall.

When to Use Something Else

Flat files break down when you have multiple agents writing concurrently, when you need transactional guarantees, or when your memory corpus exceeds what semantic search can handle efficiently.

For a single autonomous agent doing real work? Markdown files in a folder. It's boring, it's simple, and it just works.

I'm building autonomous AI systems that handle real business tasks — from content to prospecting to deployments. Follow along at ryancwynar.com.

What Happens When Your AI Prospect Finder Runs Out of Prospects

RyanCwynar — Sun, 15 Mar 2026 19:01:19 +0000

You build an automated system to find local business prospects. It works great. Then one day it starts returning mostly duplicates. Congratulations — you have hit saturation, and it is one of the most useful signals your system can produce.

Over the past few weeks I have been running an AI-powered prospect discovery pipeline targeting South Florida businesses — doctors, dentists, law firms, CPAs. The system runs on cron jobs, searches Google Maps and web directories, deduplicates against a PostgreSQL queue, and adds new prospects for outreach via voice AI calls.

Here is what the trajectory looked like.

The Growth Phase

Early on, every search returned fresh results. A query for "dentists Fort Lauderdale" would yield five or six new prospects with zero duplicates. The queue grew fast — from zero to 200 in the first week.

The system was simple: search a category and geography, extract business name and phone number, check if we already have them, insert if new. Each cron run targeted a different vertical (medical, legal, dental) and a different city in the South Florida metro.

The Saturation Signal

Around prospect 240, things changed. A search for "doctors Miami" that previously returned six new leads now returned twelve candidates — eight of which were already in the queue. The duplicate ratio flipped from 20% to 70%.

This is not a bug. This is information.

When your automated pipeline starts hitting high duplicate rates, it is telling you that you have effectively covered that geographic and vertical combination. Continuing to search the same space burns compute and API calls for diminishing returns.

What Saturation Tells You

Your coverage is real. If you are finding the same businesses repeatedly across different search queries, your data is comprehensive. You are not missing the obvious ones.

Your dedup is working. The fact that duplicates get caught means your matching logic handles variations in business names and phone numbers. This is harder than it sounds — "Dr. Smith Family Practice" and "Smith Family Medical" might be the same business.

It is time to expand, not optimize. The instinct is to try harder searches or more creative queries. The better move is to expand geography. South Florida saturated at 260 prospects? Move to Tampa, Orlando, or Jacksonville.

The Architecture That Made This Easy

The reason saturation was easy to detect and act on is that the system was designed with simple, observable data:

Search results → Candidate list → Dedup check → Insert or skip

Every run logs how many candidates were found, how many were duplicates, and how many were inserted. When the inserted count trends toward zero, you know.

I use PostgreSQL for the prospect queue, which makes dedup queries trivial. A simple check on phone number catches most duplicates. Business name fuzzy matching catches the rest.

The cron jobs rotate through verticals and geographies on a schedule. Each job targets one combination — "dentists Boca Raton" or "law firms Palm Beach" — so when a specific combination saturates, you can see exactly which one.

Lessons for Any Automated Discovery System

1. Track your hit rate. The ratio of new results to total candidates is your most important metric. Plot it over time.

2. Design for expansion. When you saturate one dimension (geography, vertical, keyword), you need a clean way to add new dimensions. If your system is hardcoded to one city, you will hit a wall.

3. Saturation is a feature. It means your system works. It found everything findable in that space. Celebrate it, then move on.

4. Do not fight diminishing returns. When duplicate rates exceed 60-70%, stop searching that combination. Redirect those compute cycles to unexplored territory.

5. Log everything. You cannot detect saturation if you do not track what happened on each run. Every search, every candidate, every skip.

What Is Next

The South Florida queue is at 260 prospects and effectively saturated for the verticals I care about. The next step is geographic expansion — same verticals, new metro areas. The infrastructure does not change; only the search parameters do.

That is the whole point of building systems instead of doing things manually. When one market is covered, you change a config value and point the pipeline somewhere new. The boring infrastructure pays for itself when scaling is a one-line change.

Saturation is not failure. It is the system telling you it finished its job in that space. Listen to it.

Why I Self-Host Convex as My Personal API Layer

RyanCwynar — Sun, 15 Mar 2026 10:00:56 +0000

Every side project starts the same way: you need a database, an API, and auth. By the third project, you're drowning in Supabase instances and Railway deployments. I got tired of it, so I self-hosted Convex on a single VPS and turned it into the backbone for everything I build.

The Problem with Per-Project Backends

Most indie hackers spin up a new backend for every project. A Postgres here, a serverless function there, maybe a Firebase instance for real-time stuff. It works until you have six projects, four databases, and no idea which one has the customer data you need.

I wanted one place where all my data lives, all my functions run, and I can wire up new projects in minutes instead of hours.

Why Convex

Convex gives you a reactive database, serverless functions, and real-time subscriptions out of the box. The self-hosted version means I own the data and the compute. No vendor lock-in, no surprise bills, no rate limits.

The killer feature for my use case: functions are just TypeScript. I write a query or mutation, deploy it, and it's immediately callable from any project. No REST routes to define, no API gateway to configure. The function is the API.

The Setup

My stack is dead simple:

One $10/mo VPS running Docker
Traefik for reverse proxy and automatic HTTPS
Convex self-hosted (two containers: backend + dashboard)
PostgreSQL for Convex's storage layer

Deploy command is one line:

CONVEX_SELF_HOSTED_URL="https://convex-socket.byldr.co" \
CONVEX_SELF_HOSTED_ADMIN_KEY="your-admin-key" \
npx convex deploy

Every project in the repo shares the same Convex instance. New tables, new functions — just deploy and they're live.

What Runs on It

Right now, my single Convex instance powers:

Blog engine — posts, cross-posting to Dev.to and Hashnode
Contact forms — submissions from multiple sites
Prospect tracking — leads, payment links, follow-ups
API key management — auth for external integrations
Webhook logging — every inbound webhook gets logged
Email system — templates, send logs, credential management

That's six distinct "products" sharing one backend. Adding a new one takes maybe 20 minutes: define the schema, write the functions, deploy.

The Real Win: Cross-Project Queries

Here's what you can't do with separate backends: query across projects. When I want to see all activity — blog posts published, prospects contacted, emails sent — it's one query against one database. No API stitching, no data pipeline, no ETL.

My AI agent uses this constantly. It calls Convex functions to publish blog posts, check prospect status, and log activities. One set of credentials, one deployment target, zero context-switching.

What I'd Do Differently

I'd set up proper table namespacing earlier. Right now my tables are a flat list (posts, prospects, emailLogs). With ten more projects, that gets messy. Convex doesn't have schemas-within-schemas, but a naming convention like blog_posts, crm_prospects would help.

I'd also add a read-only dashboard earlier. The Convex dashboard is great for debugging, but I want a simple status page showing counts and recent activity across all projects.

Should You Do This?

If you're building one SaaS product, probably not. Use Convex Cloud or whatever managed service fits.

But if you're an indie hacker with multiple projects, a self-hosted Convex instance is genuinely underrated. You get a unified data layer, real-time by default, and TypeScript functions that deploy in seconds. All on a cheap VPS you already have.

The best infrastructure is the kind you set up once and forget about. Six months in, I've deployed dozens of function updates and haven't touched the Docker config once. That's the goal.

Sub-200ms Voice AI: Bridging Twilio and OpenAI Realtime API

RyanCwynar — Sat, 14 Mar 2026 19:01:04 +0000

Most voice AI feels like talking to a call center robot. You say something, wait two seconds, get a canned response. The latency kills the illusion.

I wanted something better — a voice agent that could hold a real conversation with near-human response times. Here's how I built it by bridging Twilio Media Streams directly to OpenAI's Realtime API.

The Architecture

The traditional approach to voice AI is a three-step pipeline: Speech-to-Text → LLM → Text-to-Speech. Each step adds latency. STT takes 500ms-1s. The LLM call takes another 500ms-2s. TTS adds another 500ms. You're looking at 1.5-3.5 seconds of dead air before your agent says anything. Humans notice pauses over 300ms.

OpenAI's Realtime API changes the game. Instead of three separate steps, you get a single WebSocket connection that handles audio in and audio out. The model "hears" raw audio and "speaks" back directly. No transcription round-trip.

The trick is getting Twilio's phone audio into that WebSocket.

How It Works

When someone calls our Twilio number, Twilio opens a Media Stream — a WebSocket that sends us raw audio packets (mulaw, 8kHz). Our Node.js server sits in the middle:

Phone Call → Twilio → Media Stream WebSocket → Our Server → OpenAI Realtime WebSocket

The server's job is simple: receive audio chunks from Twilio, forward them to OpenAI, and pipe OpenAI's audio responses back to Twilio. It's a bridge, not a processor.

Here's the core of it:

// Twilio sends audio
twilioWs.on("message", (data) => {
  const msg = JSON.parse(data);
  if (msg.event === "media") {
    openaiWs.send(JSON.stringify({
      type: "input_audio_buffer.append",
      audio: msg.media.payload  // Already base64 mulaw
    }));
  }
});

// OpenAI sends audio back
openaiWs.on("message", (data) => {
  const event = JSON.parse(data);
  if (event.type === "response.audio.delta") {
    twilioWs.send(JSON.stringify({
      event: "media",
      streamSid: streamSid,
      media: { payload: event.delta }
    }));
  }
});

That's the essential loop. Audio flows in both directions through our server with minimal processing overhead.

The Details That Matter

Transcription: I added input_audio_transcription: { model: "whisper-1" } to capture what both sides say. This runs async — it doesn't add to response latency, but gives you full transcripts after the call.

Voice selection: OpenAI offers several voices. I went with ash — it's deeper and more natural for a male-presenting agent. The voice quality from the Realtime API is noticeably better than traditional TTS.

Interruption handling: The Realtime API handles barge-in natively. If someone starts talking while the agent is speaking, it detects the interruption and stops. No custom VAD needed.

DNS and SSL: Twilio needs a public WebSocket endpoint. I pointed realtime.byldr.co at my VPS (not through Cloudflare proxy — WebSockets don't play nice with proxied connections) and used Let's Encrypt for SSL.

Real-World Results

End-to-end latency: roughly 200ms from when someone finishes speaking to when the agent starts responding. That's fast enough to feel conversational. People don't notice the gap.

I tested it by having the agent cold-call me with a comically aggressive sales pitch. I played along, gave a fake credit card number, and the agent handled the whole exchange naturally. Full transcript captured on both sides.

What I'd Do Differently

The Realtime API is still relatively new, and the pricing is steep — audio tokens cost significantly more than text. For high-volume use cases, the three-step pipeline with a faster STT (like Deepgram) might be more cost-effective, even with the latency hit.

Also, error handling on WebSocket reconnection needs more thought. Twilio's Media Streams can hiccup, and if either WebSocket drops, you need to gracefully restart the bridge without the caller hearing dead air.

The Stack

Runtime: Node.js on a $10/month VPS
Phone: Twilio (inbound + outbound)
AI: OpenAI Realtime API (gpt-4o-realtime-preview)
Process manager: PM2
Total infrastructure cost: ~$15/month plus per-minute API costs

You don't need a fancy MLOps platform to build voice AI that feels real. A VPS, two WebSocket connections, and some careful audio piping gets you 90% of the way there.

Building an Autonomous Content Pipeline: From Cron Job to Cross-Post

RyanCwynar — Sat, 14 Mar 2026 10:01:09 +0000

I have a confession: I didn't write this blog post. Well, I did — I built the system that writes it. Every morning at 10 AM UTC, a cron job fires, an AI agent checks what I've been working on, writes an article, publishes it to my site, and cross-posts it to Dev.to and Hashnode. No approval step. No drafts sitting in a queue. Just ship.

Here's how the whole thing works.

The Trigger

It starts with a cron job. Not a traditional crontab entry — this runs through OpenClaw's cron system, which can spin up isolated agent sessions on a schedule. The job fires a prompt that says: check recent memory files, pick a topic, write an article, publish it.

The key insight is that the agent has access to daily memory files (memory/YYYY-MM-DD.md) that log everything I've been building. So it's not generating content from thin air — it's writing about real work.

The Stack

The publishing pipeline is surprisingly simple:

Convex backend — My site runs on a self-hosted Convex instance. A single mutation (posts:upsertPost) handles creating or updating blog posts with title, slug, content, excerpt, and cross-posting flags.
Cross-posting — A separate Convex action (crossPost:crossPostArticle) takes the slug and pushes the article to Dev.to (via their API) and Hashnode (via GraphQL). Each platform has its own formatting quirks, but markdown is the common denominator.
Notification — After publishing, the agent sends me a WhatsApp message with the link. I find out about my own blog post the same way my readers do.

What I Learned Building This

Memory files are the secret sauce. The agent wakes up fresh every session with no context. But because it reads structured daily logs, it knows what I've been working on. Yesterday's memory file says we published an article about boring infrastructure. The day before, we drafted a LinkedIn post about AI automation. The agent picks something new and avoids repeating itself.

No approval gates means you actually ship. I used to have a "draft and review" step. Know what happened? Drafts piled up. I'd review them three days later, decide they were stale, and delete them. Removing the approval step was scary but effective. The quality is good enough because the agent has clear constraints: 500-800 words, practical and technical, my voice.

Cross-posting multiplies reach for free. Dev.to and Hashnode both support canonical URLs, so there's no SEO penalty. One article becomes three touchpoints. The API integrations took maybe two hours total to build.

Saturation signals matter. After running automated prospecting campaigns for weeks, I learned that more isn't always better. The same applies to content — the system checks what's been published recently and avoids flooding the same topics. It's not just about producing content; it's about producing varied content.

The Unsexy Parts

Most of the work wasn't the AI integration. It was:

Getting the Convex self-hosted instance stable behind Traefik
Handling API rate limits on Dev.to (they're strict)
Dealing with Hashnode's GraphQL schema changes
Making sure the cron job doesn't fire twice if the gateway restarts
Error handling when the cross-post fails but the main post succeeded

This is the pattern I keep seeing: 20% of the work is the cool AI stuff, 80% is plumbing.

Should You Build This?

If you're a developer who wants to write more but doesn't, yes. The barrier to publishing isn't writing ability — it's the friction of the publishing process. Automate the friction, and content flows.

If you're worried about quality: set constraints. Word count limits, topic guidelines, voice examples. The agent follows instructions well when they're specific.

If you're worried about authenticity: every article is based on real work I'm actually doing. It's not hallucinated thought leadership. It's a technical log with personality.

The whole pipeline took about a day to build. The ROI has been a steady stream of technical content that I genuinely wouldn't have published otherwise. Sometimes the best code you write is the code that writes for you.

When Your AI Pipeline Hits the Wall

RyanCwynar — Fri, 13 Mar 2026 19:01:14 +0000

You build an automated prospecting system. It works. It finds leads while you sleep, validates phone numbers, categorizes by campaign, queues everything for outreach. You wake up to 15 new qualified prospects. Life is good.

Then one morning you wake up to zero.

Not because anything broke. Because your AI exhausted the market.

The Setup

I built an autonomous prospect discovery system for AI receptionist demos targeting South Florida. The stack is straightforward: cron jobs trigger search queries every few hours, results get scraped and validated, duplicates get filtered, and qualified leads land in a CRM queue tagged by campaign type.

Dentists. Law firms. Medical practices. CPAs. The system ran 24/7 across multiple campaign verticals, and within a few weeks it had queued up 260+ prospects.

Then the dedup rate started climbing.

The Saturation Signal

At first, maybe 1 in 5 candidates was a duplicate. Normal. Then it was 1 in 3. Then 3 out of 4. One run searched four different queries across three cities and found exactly zero new prospects.

This is the saturation signal, and most people miss it because they are not tracking the right metric. Everyone watches the output count — how many leads did we add today? But the real signal is the rejection ratio. When your system is spending more cycles filtering duplicates than finding new targets, you have hit the edges of your market segment.

Why This Matters More Than You Think

In traditional sales, you rarely hit true geographic saturation. The Rolodex is infinite because humans are slow. But automation changes the math. An AI that searches, scrapes, and validates 24/7 can literally exhaust a vertical in a metro area within weeks.

This is not a bug. It is a feature — if you recognize it.

Saturation means you have complete coverage of that segment. Every dentist in Miami-Dade who has a website and a phone number? You have them. That is a powerful position for a sales team. Instead of wondering if you missed someone, you know the list is comprehensive.

What To Do When You Hit the Wall

1. Expand geography. South Florida is saturated? Move to Tampa, Orlando, Jacksonville. Same verticals, new territory. The system does not care about zip codes.

2. Expand verticals. You have every dentist. What about veterinarians? Chiropractors? Insurance agencies? The AI receptionist pitch works for any business that answers phones.

3. Go deeper, not wider. Instead of finding more prospects, enrich the ones you have. Pull Google reviews, check social media presence, estimate practice size. The best outreach is targeted outreach.

4. Shift from discovery to conversion. At some point the bottleneck is not finding leads — it is closing them. Redirect automation effort from prospecting to follow-up sequences, call scheduling, and nurture campaigns.

The Meta Lesson

Every automated pipeline has a ceiling. The interesting question is not whether you will hit it, but whether your system tells you when you do.

Most automation just keeps running, burning API credits on searches that return nothing new. The smart version tracks its own diminishing returns and raises a flag: "Hey, I am finding 90% duplicates. Time to change strategy."

This is the difference between automation and intelligent automation. The first one does what you told it. The second one tells you when what you told it stopped working.

Build the signal detection into your pipelines from day one. Your future self — the one staring at a dashboard wondering why lead volume dropped — will thank you.