DEV Community: shrey vijayvargiya

Claude Code Skills Directory: Every Official Skill Repo I Use, From React to Rust

shrey vijayvargiya — Thu, 15 Oct 2026 08:15:48 +0000

Claude Code writes decent code out of the box. It also writes code that looks like it was trained on every tutorial from 2021, because it partly was. It reaches for useEffect where it doesn't need one, wires Stripe with the API you shouldn't use for new projects, and ships a Supabase table with row-level security turned off.

Skills fix most of that. A skill is a folder with a SKILL.md file that teaches the agent how a specific tool should be used today, written by people who know. The best ones are written by the companies that make the tools: Vercel for React and Next.js, Stripe for payments, Supabase for Postgres, Expo for mobile.

This post is the list I wish I'd had: every skill repository I use or keep bookmarked, grouped by category, with what each skill actually does and when to reach for it. I checked every repository on GitHub while writing this, so every link points at a real folder with a real SKILL.md in it.

It's long. Here's what's covered:

Design, UI and UX
React, Next.js, Vite, TanStack and Astro
Animation and motion
Testing frontend apps
Authentication
Payments and billing
Databases, BaaS and PostgreSQL
Mobile: Expo and React Native
AI, LLMs and deep learning
Servers and cloud functions
Rust
System design and API design
Docker and Kubernetes
Email, SMS and WhatsApp
Voice AI and audio
Web scraping and browser automation
Analytics, feature flags and error tracking
More databases, caching and queues
Vue, Nuxt and Svelte
Python, FastAPI and Go
Security and code review
Git, CI/CD and infrastructure as code
Marketing, SEO and growth
Documents and office files

Then the 20 skills I'd install first, and how to use skills without making things worse.

How Claude Code skills work (two minutes)

A skill is a directory containing a SKILL.md file. The top of that file has a name and a description in YAML frontmatter, and the body has the instructions. It can also carry extra reference files and scripts.

The clever part is that skills load in stages, which Anthropic's Agent Skills docs call progressive disclosure:

Level 1, always loaded: just the name and description, roughly 100 tokens per skill. This is how Claude knows the skill exists.
Level 2, loaded when relevant: the SKILL.md body, under 5k tokens, read only when your request matches the description.
Level 3, loaded on demand: reference files and scripts. A script's output enters the context, not its source code.

So you can install a lot of skills without filling the context window. The description is what decides whether a skill fires, which is why good skill authors write descriptions like "Use when the user mentions X, Y or Z."

Claude Code looks for skills in two places: ~/.claude/skills/ for personal skills and .claude/skills/ inside a project. Skills can also come bundled inside Claude Code plugins.

Installing skills: the three commands you need

Most repositories in this post support one or more of these:

# 1. The open skills CLI from Vercel Labs. Works for any GitHub repo with SKILL.md files.
npx skills add vercel-labs/agent-skills
npx skills add supabase/agent-skills --skill supabase

# 2. Claude Code plugin marketplaces (run inside Claude Code)
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

# 3. Plugins from the official Claude Code marketplace
claude plugin install stripe@claude-plugins-official

The npx skills CLI is the one I use most because it takes any repo, and you can pick single skills with --skill instead of installing a whole collection. Each repository's README lists its preferred command, and I've noted the official ones below.

If you want the bigger picture of how skills sit inside an agent (the loop, the tools, the permissions), I covered that in agent harnessing. And if you're curious what happens when you hand Claude a pile of growth skills and let it run a real site, that was this experiment.

Official vs community, and why it matters

Every entry below is marked. Official means the repository is owned by the company or project behind the tool (Vercel, Stripe, Supabase, Expo, Docker and so on). Community means a developer or team outside that company wrote it.

Official skills track the product: when Next.js ships a new caching model, the Next.js skills change with it. Community skills can be excellent (Emil Kowalski's animation skills are the best in this whole list), but they move at the speed of one maintainer. Where no official skill exists for a tool, I've said so instead of pretending.

One safety note before the list. Skills can include scripts, and an agent will run them. Read the SKILL.md and any scripts/ folder before installing a community skill, the same way you'd read a shell script before piping it into bash.

1. Design, UI and UX skills

This is the category that changes output the most. Without a design skill, Claude produces the same safe layout every time: centered hero, three feature cards, purple gradient. With one, it makes deliberate choices about type, spacing and hierarchy.

anthropics/skills (official, Anthropic)

frontend-design: guidance for distinctive, intentional visual design. It pushes Claude toward an actual aesthetic direction and typography choices that don't look templated. Use it whenever you're building a new page or reshaping an existing one.
web-artifacts-builder: tooling for multi-component HTML artifacts built with React, Tailwind CSS and shadcn/ui, for when a single file isn't enough.
theme-factory: ten preset color and font themes you can apply to slides, docs or landing pages.
canvas-design and algorithmic-art: posters and static visuals, and generative art in p5.js with seeded randomness.

vercel-labs/agent-skills (official, Vercel)

web-design-guidelines: reviews your UI code against Vercel's Web Interface Guidelines. Trigger it with "review my UI", "check accessibility" or "audit design". This is my default pre-ship check.
writing-guidelines: the same idea for docs and UI copy, checking voice and tone against a writing handbook.

nextlevelbuilder/ui-ux-pro-max-skill (community)

ui-ux-pro-max: a large UI/UX knowledge skill for web, mobile and desktop, covering pages, components, design systems, accessibility, interaction and responsive layout. It's the heavyweight option when you want Claude to reason about design rather than just apply a style.
The same repo ships design-system (three-layer tokens: primitive, semantic, component), ui-styling (shadcn/ui plus Tailwind), brand, banner-design and slides.
Install with /plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill, then /plugin install ui-ux-pro-max@ui-ux-pro-max-skill.

shadcn-ui/ui (official, shadcn)

shadcn: manages shadcn components and projects (adding, searching, fixing, debugging, styling and composing UI, including chat interfaces), with component docs and usage examples. It lives inside the main shadcn repository.
migrate-radix-to-base: moves a project or single components from Radix UI primitives to Base UI.

If you're collecting shadcn extensions to pair with this, my list of cool shadcn libraries is still the one I point people to.

Tailwind CSS: I couldn't find an official Tailwind Labs skill repository. The two I'd use are ui-styling above and the community tailwind-design-system from wshobson/agents, which targets Tailwind v4 design tokens and component libraries.

Use this category when: you're starting a landing page, building a dashboard, or about to ship a UI you haven't had a designer look at.

2. React, Next.js, Vite, TanStack and Astro

Framework skills are where official repos matter most, because frameworks change faster than model training data.

React

There's no skill from the React team itself. The reference is Vercel's:

react-best-practices (official, Vercel): React and Next.js performance guidelines from Vercel Engineering. It's meant to load whenever Claude writes, reviews or refactors React code. If you install one skill from this whole post, make it this one.
composition-patterns (official, Vercel): composition patterns for components drowning in boolean props, for compound components and for reusable component APIs.
react-view-transitions (official, Vercel): React's View Transition API (<ViewTransition>, addTransitionType and the CSS pseudo-elements). More on this in the animation section.

Prepping for interviews alongside this? The 50 React interview questions post covers the same ground from the other side.

Next.js

The Next.js team keeps skills inside the main repository, under skills/ on the canary branch (official, Vercel):

next-dev-loop: verifies that a change works in a running app, not just that it compiles. It combines Next.js's built-in /_next/mcp endpoint with a browser.
next-bundle-optimizer: audits and reduces initial-load work, such as oversized client bundles and duplicate dependencies.
next-cache-components-adoption and next-cache-components-optimizer: turn on Cache Components, fix the blocking routes it surfaces, then optimize what renders instantly.
next-partial-prefetching-adoption and next-partial-prefetching-optimizer: the same two-step flow for Partial Prefetching.

These are the skills that know about features newer than any model's training cutoff. The bundle optimizer pairs well with my rant about why websites are slow. For starter projects to try them on, see the free Next.js boilerplates list.

Vercel also ships deployment and cost skills in vercel-labs/agent-skills: deploy-to-vercel, vercel-cli-with-tokens and vercel-optimize, which pulls real usage metrics before suggesting cost and performance fixes.

Vite and Vitest

antfu/skills (community, by Anthony Fu of the Vite and Vitest core teams): vite covers vite.config.ts, the plugin API, SSR and the Vite 8 Rolldown migration. vitest covers writing tests, mocking, coverage and fixtures. The repo also has skills for Vue, Nuxt, Pinia, UnoCSS, VitePress and pnpm.

TanStack

DeckardGer/tanstack-agent-skills (community): four skills, tanstack-query, tanstack-router, tanstack-start and tanstack-integration, which covers Query, Router and Start working together across SSR and caching.
TanStack's own approach is different: its Intent project is tooling for libraries to generate and ship skills alongside their npm packages, with meta-skills for generating skills and checking whether they've gone stale. Worth watching, because "the package ships its own skill" is probably where this all ends up.
If you use Clerk with TanStack Start, clerk-tanstack-patterns is official.

Astro

astrolicious/agent-skills (community): a single astro skill for components and pages, SSR adapters, content collections, static deploys and the CLI. I didn't find an official skill from the Astro team.
Official adjacent options: Clerk's clerk-astro-patterns, and Vercel's vercel-optimize, which lists limited Astro support.

Astro keeps coming up in my own cost work because it ships so little JavaScript. That's part of how we keep ihatereading.in under $100 a month.

3. Animation and motion skills

Agents are bad at animation in a specific way: they add motion everywhere, use the wrong easing, animate layout properties that drop frames, and never think about interruption. The skills here fix the decision-making, not just the syntax.

emilkowalski/skills (community, by Emil Kowalski, who teaches animations.dev and built Sonner and Vaul)

This is the best-written skill repo in this post. Install it with npx skills@latest add emilkowalski/skills.

animate: builds an animation from scratch by making decisions in order: should it animate at all, what for, which tool, which properties, which curve and duration, and how it handles interruption.
review-animations: reviews motion code against a high craft bar. In its own words, "approval is earned."
improve-animations: read-only audit of a codebase's motion code that produces a prioritized plan other agents can execute.
find-animation-opportunities: finds places that should animate and rejects the ones that shouldn't, with exact values.
animation-performance: keeps animations inside the frame budget by sticking to composite-only properties and keeping motion off a busy main thread.
animation-vocabulary: turns "the bouncy thing when a popover opens" into the actual term, so you and the agent are talking about the same effect.
apple-design: Apple's approach to fluid, physical, gesture-driven motion translated for the web.
animate-expo: the same decision process for React Native and Expo.
Also useful outside animation: break-ui (feeds your UI worst-case data like long names, emoji and zero items), pick-ui-library (an opinionated list for charts, OTP inputs, command menus and more), ask-sonner and emil-design-eng.

Framer Motion / Motion: I didn't find an official skill from the Motion team. Emil's animate and review-animations cover the decisions you make with Motion, and they work whichever library you pick.

Other motion skills worth knowing:

react-view-transitions (official, Vercel): native-feeling page and element transitions with React's View Transition API, without a library.
expo-animation (official, Expo): animation decisions for React Native, including which thread an animation runs on and spring vs timing.
remotion-dev/skills (official, Remotion): for video made in React code. remotion-best-practices routes to the rest, including remotion-create, remotion-render, captions and maps. If you've ever tried to turn a blog into an explainer video, this is the stack for it. I wrote about that format in understanding LLM output faster.

4. Testing frontend apps

The most useful thing a skill can do is give the agent a browser and tell it to check its own work. "It compiles" and "it works" are different claims, and these skills close that gap.

webapp-testing (official, Anthropic): a toolkit for testing local web apps with Playwright. It verifies frontend behavior, debugs UI, captures screenshots and reads browser logs. Use it after any UI change you'd otherwise check by hand.
playwright-cli (official, Microsoft): browser automation and Playwright test work through Microsoft's Playwright CLI.
next-dev-loop (official, Next.js): the runtime check for Next.js apps, described above.
vitest (community, Anthony Fu): unit tests, mocking and coverage.
clerk-testing (official, Clerk): end-to-end tests for auth flows with Playwright or Cypress, which is the part of an app most people skip testing.
e2e-testing-patterns (community, wshobson/agents): general Playwright and Cypress patterns for reliable suites.
break-ui (community): not a test runner, but it finds the layout bugs real users will hit first.

Use this category when: you've let an agent make UI changes across several files and you don't want to click through every screen yourself.

5. Authentication: Clerk, Better Auth, Firebase Auth, Neon Auth

Auth is where outdated training data hurts most, because SDKs change their APIs and the old ones still look plausible.

clerk/skills (official, Clerk)

Clerk has the most complete auth skill set I found, one skill per framework. Install the skills with npx skills add clerk/skills, or the plugin (skills plus the Clerk MCP server) with /plugin marketplace add clerk/skills and /plugin install clerk@clerk-skills.

Skill	What it covers
`clerk`	Router skill that sends Claude to the right Clerk skill
`clerk-setup`	Adding Clerk with the CLI and official quickstarts, or migrating from another auth system
`clerk-nextjs-patterns`	Middleware, Server Actions and caching in Next.js
`clerk-react-patterns`	React SPAs on Vite or CRA
`clerk-tanstack-patterns`	TanStack React Start
`clerk-astro-patterns`	Astro middleware, SSR pages and islands
`clerk-expo`	Expo and React Native with `@clerk/expo`
`clerk-orgs`	Organizations for B2B and multi-tenant apps
`clerk-billing`	Subscriptions with Clerk's PricingTable
`clerk-webhooks`	Verified webhooks for syncing users to your database
`clerk-custom-ui`	Custom sign-in flows with hooks and appearance
`clerk-backend-api`	Browsing and calling the Backend REST API
`clerk-testing`	E2E auth tests

There are also skills for Nuxt, Vue, React Router, Chrome extensions, Android and Swift in the same folder.

better-auth/skills (official, Better Auth)

best-practices: server and client config, database adapters, sessions, plugins and environment variables.
create-auth: scaffolds auth into a TypeScript app, detecting the framework and adding route handlers, OAuth providers and UI pages.
Plus focused skills for emailAndPassword, organization, twoFactor and a security skill.

Firebase and Neon

firebase-auth-basics (official, Firebase): sign-in, user management and auth-aware security rules.
neon-auth (official, Neon): Neon Auth, which its skill describes as managed Better Auth, covering sign-up, magic links, OTP, OAuth, passkeys and organizations.

6. Payments and billing: Stripe, Dodo Payments, Polar

All three payment providers I use have official skills, which says a lot about where integration work is heading. I'd treat these as mandatory before letting an agent touch money.

stripe/ai (official, Stripe)

Install with claude plugin install stripe@claude-plugins-official, or npx skills add https://docs.stripe.com.

stripe-best-practices: the one to always have. It guides integration decisions: test environments (separate sandboxes or the shared test mode), Checkout Sessions vs PaymentIntents, Connect setup and more.
stripe-docs: reads and searches Stripe docs and API reference, including gated docs. Its description tells the agent to prefer it over curl or web fetches.
upgrade-stripe: upgrading API versions, webhook endpoints, server SDKs, Stripe.js and mobile SDKs.
connect-recommend and connect-required-verification-information: for marketplaces and platforms on Connect.
metronome: usage-based billing with Metronome (event ingestion, rate cards, invoicing).
stripe-apps, stripe-projects, stripe-directory and stripe-pay: Dashboard extensions, provisioning services through Stripe Projects, and agent-side payments.

dodopayments/skills (official, Dodo Payments)

Dodo Payments works as a merchant of record, so it acts as the seller and handles the tax side for you. Its agent skills page lists 18 skills, installed with npx skills add dodopayments/skills:

Start here: dodo-best-practices (SDK setup, keys, the checkout-to-webhook architecture) and framework-adapters (official route handlers for Next.js, Express, Hono and others).
Core flows: checkout-integration, subscription-integration (trials, plan changes, proration) and webhook-integration (Standard Webhooks verification).
Billing models: usage-based-billing, credit-based-billing and license-keys. The credits one is the pattern most AI SaaS apps need.
Going live: testing-and-go-live and refunds-and-disputes.
Extras: mobile-checkout for React Native and Flutter, localized-pricing for purchasing power parity, billing-sdk for pricing table components and better-auth-integration.

polarsource/skills (official, Polar)

Four focused skills:

setup-polar: an interactive onboarding wizard for adding Polar from scratch.
polar-integration: Checkout, Customer Portal and Webhooks endpoints with @polar-sh/sdk, for any framework.
polar-testing: testing in Polar's sandbox, including checkout flows without real payments and Stripe test cards.
polar-migration: moving from Stripe Billing, Paddle, Lemon Squeezy or Gumroad.

Use this category when: you're adding checkout, changing plans, or upgrading an SDK. And always run the provider's testing skill before you flip to live keys.

7. Databases, BaaS and PostgreSQL

Supabase

supabase/agent-skills (official, Supabase) has only two skills, and both are broad:

supabase: for any Supabase task, covering Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron and Queues, plus supabase-js and @supabase/ssr in Next.js and other frameworks.
supabase-postgres-best-practices: Postgres best practices for Postgres running anywhere, not just on Supabase. It's meant to load before Claude creates or alters tables and columns. This is the best general Postgres skill I've found.

Install both with npx skills add supabase/agent-skills, or as plugins with claude plugin marketplace add supabase/agent-skills.

Firebase

firebase/agent-skills (official, Firebase). ihatereading.in runs on Firebase, so these are the ones I lean on:

firebase-basics: CLI install, login, project setup and app config.
firebase-firestore: Firestore data modeling, queries, indexes and SDKs.
firestore-rules-creation and firebase-security-rules-auditor: writing production security rules, then auditing them for privilege escalation, role bypasses and create-vs-update gaps. Run the auditor on any project an agent has touched.
firebase-data-connect-basics: Firebase's PostgreSQL-backed Data Connect.
firebase-ai-logic-basics: calling Gemini models from client code.
Also firebase-hosting-basics, firebase-app-hosting-basics, firebase-remote-config-basics, firebase-crashlytics and extension-to-functions-codebase.

My own SaaS starter kit is built on Firebase, and these skills cover the setup work it involves: CLI, Firestore, rules and hosting.

Neon and Prisma

neondatabase/agent-skills (official, Neon): neon-postgres (pooled vs direct connections, migrations, autoscaling, scale-to-zero), neon-postgres-branches (testing migrations on a copy of real data) and neon-postgres-egress-optimizer, which hunts down code that pulls too much data out of the database and inflates your bill.
prisma/skills (official, Prisma): prisma-orm-setup, prisma-client-api, prisma-cli, prisma-postgres and prisma-upgrade-v7.

PostgreSQL in depth

Beyond the vendor skills, three community skills go deeper into raw Postgres:

postgresql-table-design (wshobson/agents): schema design, data types, indexing, constraints and Postgres-specific features.
sql-optimization-patterns (wshobson/agents): query optimization, indexing strategy and reading EXPLAIN output.
postgres-pro (Jeffallan/claude-skills): EXPLAIN analysis, JSONB, extensions, replication and VACUUM tuning.

My Postgres combination: supabase-postgres-best-practices always on, postgresql-table-design when designing a new schema, and sql-optimization-patterns when something is slow.

8. Mobile: Expo and React Native

Mobile has the richest official skill set of any category, because Expo went all in. If you build with React Native, this section is the reason to read this post.

Expo

expo/skills (official, Expo). Install with npx skills@latest add expo/skills --skill '*', or as a plugin with claude plugin install expo@claude-plugins-official.

Start with expo-overview. It's the entry point and router for every Expo and EAS task, and it's meant to load before Claude picks any other Expo skill.

Building the app

expo-project-structure: folder layout for a new Expo Router app. It's for new projects only.
expo-router: file-based routes, groups, dynamic routes, modals, form sheets, link previews and NativeTabs.
expo-native-ui: native-feeling screens with Apple HIG styling, semantic colors, SF Symbols and native controls.
expo-ui: the @expo/ui package, which renders real SwiftUI on iOS and Jetpack Compose on Android, for sheets, pickers, sliders, toggles and menus.
expo-design-system: design tokens and a reusable component structure inside an Expo app.
expo-data-fetching: any network request, with React Query, SWR, caching, offline support and loading, empty and error states.
expo-animation: covered in the animation section.
expo-examples: points the agent at Expo's roughly 70 official with-* example projects (Stripe, Clerk, Supabase, OpenAI, maps, SQLite, Skia, NativeWind and more), so it copies a working integration instead of inventing one.

Going native and migrating

expo-module: writing native modules and views with the Expo Modules API in Swift and Kotlin.
expo-dom and expo-web-to-native: running web code inside native screens, and porting a whole Next.js, Vite or CRA app to iOS and Android.
expo-brownfield: embedding React Native screens in an existing native app.
expo-upgrade: SDK upgrades and dependency fixes.

Shipping with EAS

eas-app-stores: build and submit to TestFlight, the App Store and Google Play.
eas-update and eas-update-insights: over-the-air updates, then crash rates and adoption per update.
eas-workflows: CI/CD YAML in .eas/workflows/.
eas-hosting: deploying Expo web builds and API routes.
Plus expo-dev-client, eas-observe, eas-simulator (cloud simulators, marked experimental) and expo-app-clip.

React Native

callstackincubator/agent-skills (from Callstack, the React Native consultancy): react-native-best-practices covers FPS, time to interactive, bundle size, memory leaks, re-renders and Hermes. upgrading-react-native applies template diffs and handles CocoaPods and Gradle changes, which is the most painful job in React Native. There's also react-navigation, create-react-native-library, github-actions for simulator and emulator CI builds, and brownfield migration skills.
react-native-skills (official, Vercel): React Native and Expo performance, covering list performance, animations and native modules.
Related skills from other sections: clerk-expo for auth, Dodo's mobile-checkout for payments and Emil's animate-expo for motion.

9. AI, LLMs and deep learning

This category splits in two: skills for building apps on top of models, and skills for training models.

OpenRouter (building on many models)

OpenRouterTeam/skills (official, OpenRouter). I route most of my agents through OpenRouter, so this is the repo I check first:

openrouter-typescript-sdk: the reference for calling 300+ models through the TypeScript SDK and the callModel pattern.
openrouter-models and openrouter-benchmarks: query live model pricing, context lengths and capabilities, and benchmark rankings. Use these instead of letting the agent guess model IDs from memory.
create-headless-agent and create-agent-tui: scaffold an agent in TypeScript with @openrouter/agent, either headless (CLIs, API servers, queue workers) or with a terminal UI.
openrouter-analytics: answers questions about your own spend, model mix, latency and tokens.
openrouter-oauth: "Sign In with OpenRouter" with OAuth PKCE, so users bring their own model credits.
Media: openrouter-images, openrouter-video, openrouter-tts and openrouter-stt.

I used OpenRouter for the blog-to-carousel pipeline, and the images skill covers the same API.

Anthropic's own AI skills

claude-api (official, Anthropic): reference for the Claude API and Anthropic SDK, covering model IDs, streaming, tool use, MCP, caching and token counting.
mcp-builder (official, Anthropic): a guide to building good MCP servers that give models well-designed tools.
skill-creator (official, Anthropic): creates and edits skills and runs evals on them. Use it to write your own skills for anything missing from this list.

Hugging Face (training, evals and local models)

huggingface/skills (official, Hugging Face). Hugging Face wrote up getting Claude to fine-tune an open-source LLM with these skills.

huggingface-llm-trainer: trains or fine-tunes language and vision models with TRL or Unsloth on Hugging Face Jobs, covering SFT, DPO, GRPO and reward modeling.
trl-training: writing and debugging post-training code with TRL directly.
huggingface-vision-trainer: object detection and image classification fine-tuning.
huggingface-community-evals: evals with inspect-ai and lighteval on local hardware.
huggingface-local-models: picking GGUF models and quantizations for llama.cpp on CPU, Mac Metal, CUDA or ROCm.
transformers-js: running models in JavaScript and the browser.
huggingface-datasets, huggingface-gradio, huggingface-spaces, hf-cli and huggingface-best for choosing a model by benchmark.

LLM app patterns and fine-tuning theory (community)

wshobson/agents has two plugin folders worth installing whole:

llm-application-dev: rag-implementation, embedding-strategies, hybrid-search-implementation, llm-evaluation and prompt-engineering-patterns.
llm-finetuning: finetuning-method-selection starts by asking whether to fine-tune at all, then routes to SFT, DPO or GRPO. lora-qlora-recipes, dataset-curation and eval-harness-first cover the rest.

Jeffallan/claude-skills adds rag-architect and fine-tuning-expert.

If you want to understand what these skills are configuring under the hood, start with how large language models work, which walks through tokens, attention and transformers with code.

10. Servers and cloud functions: Hono, Express, Workers, Vercel

Hono

honojs/skills (official, Hono): hono covers routing, middleware, validation, testing and streaming, and triggers whenever code imports from hono. hono-jsx covers server-rendered UI with hono/jsx, built with Vite.

Hono is my default for small APIs. I once put an entire web scraping API in one Hono file, and that's exactly the kind of project the hono skill is built for.

Express

There's no official Express skill. Two good options:

nodejs-backend-patterns (community, wshobson/agents): production Node.js services with Express or Fastify, covering middleware, error handling, auth, database integration and API design.
Dodo's framework-adapters (official): if all you need is payment routes in Express or Hono, it has official route handlers for both.

Cloudflare Workers

cloudflare/skills (official, Cloudflare):

workers-best-practices and wrangler: writing Workers and running the Wrangler CLI.
durable-objects and agents-sdk: stateful coordination and Cloudflare's Agents SDK.
nextjs-on-cloudflare: running Next.js on Workers, including choosing between vinext and OpenNext.
web-perf: Core Web Vitals and Lighthouse audits. It works on any site, not just Cloudflare ones.

Serverless functions on your BaaS

Vercel: deploy-to-vercel and vercel-optimize.
Supabase Edge Functions: covered by the main supabase skill.
Firebase: firebase-app-hosting-basics for SSR apps, and extension-to-functions-codebase for converting Firebase Extensions into Cloud Functions code.
Neon: neon-functions runs long-running Node.js HTTP functions on your Neon branch, with DATABASE_URL injected automatically.

11. Rust

There's no official skill from the Rust project, but the community work here is serious.

actionbook/rust-skills (community): the most thorough Rust set I found. It's organized as numbered modules that trigger on actual compiler errors. m01-ownership fires on borrow-checker errors like E0382 and E0597, m06-error-handling covers Result, anyhow and thiserror, and m07-concurrency covers Send/Sync, channels, mutexes and Tokio. unsafe-checker reviews unsafe code and FFI, and rust-router sends each question to the right module.
trailofbits/skills (from Trail of Bits, the security firm): rust-review is a security review covering unsafe boundaries, concurrency hazards, panics that can cause denial of service, and FFI safety. The same repo has cargo-fuzz for fuzzing.
wshobson/agents (community): rust-async-patterns for Tokio and async traits, and memory-safety-patterns for RAII, ownership and smart pointers.
rust-engineer (community, Jeffallan/claude-skills): a general-purpose skill for idiomatic Rust, lifetimes, traits and async with Tokio.

My suggestion: install rust-router plus the numbered modules if you're learning, and add rust-review before anything with unsafe goes to production.

12. System design and API design

These skills don't write features. They make the agent think before it writes them, which is where most expensive mistakes happen.

API design

api-design-principles (community, wshobson/agents): REST and GraphQL design for new APIs and spec reviews.
api-designer (community, Jeffallan/claude-skills): resource modeling, versioning, pagination and error-handling standards, plus OpenAPI specs.
openapi-spec-generation (community, wshobson/agents): OpenAPI 3.1 specs from code or design-first, for docs and SDK generation.

System design and architecture

architecture-designer (community, Jeffallan/claude-skills): high-level architecture, diagrams and Architecture Decision Records.
architecture-patterns (community, wshobson/agents): Clean Architecture, Hexagonal Architecture and Domain-Driven Design.
microservices-patterns and microservices-architect: service boundaries, event-driven communication, resilience, and breaking up a monolith.
cqrs-implementation and saga-orchestration: separate read and write models, and distributed transactions without two-phase commit.
distributed-tracing: tracing requests across services with Jaeger and Tempo.

A fair warning: for a solo project, most of these will push you toward more architecture than you need. Use them to review a design, not to generate one. A monolith on one server gets you further than people think.

13. Docker and Kubernetes

Docker

docker/skills (official, Docker):

docker-build-strategies: writing and optimizing Dockerfiles, including multi-stage builds, smaller images, faster builds and production hardening.
docker-compose-patterns: wiring services together and adding a database to local dev.
docker-project-foundations: Dockerizing a project from scratch.
docker-destructive-guardrails: loads before any command that deletes or resets state. This is the one I'd insist on, because "clean up Docker" is how agents wipe volumes.
Docker's agent tooling: docker-agent-config, docker-agent-run, docker-agent-deploy, and the docker-sandboxes-lifecycle family for running coding agents in isolated microVMs.

Sandboxes for agents are a whole topic of their own. I covered the wider space in AI agent sandbox SDKs and APIs.

Kubernetes

No official Kubernetes skill exists that I could find, and Kubernetes is where model hallucinations are most dangerous: deprecated API versions, missing resource limits, privileged pods.

LukasNiessen/kubernetes-skill (community): a single SKILL.md built to stop exactly those mistakes: insecure workload defaults, resource starvation, network exposure, privilege sprawl, fragile rollouts and API drift.
kubernetes-operations (community, wshobson/agents): k8s-manifest-generator, k8s-security-policies (NetworkPolicy and RBAC), helm-chart-scaffolding and gitops-workflow with Argo CD and Flux.
kubernetes-specialist and devops-engineer (community, Jeffallan/claude-skills): manifests, pod debugging, CI/CD and Terraform.

14. Email, SMS and WhatsApp

Every SaaS sends email eventually: a magic link, a receipt, a weekly digest. Agents can write the send call easily. What they get wrong is deliverability, which is why these skills spend so much time on DNS records and spam rules.

resend/resend-skills (official, Resend). Install with npx skills add resend/resend-skills.

resend: the Resend email API, covering transactional sends (single and batch), inbound email through webhooks, templates, delivery events and domains.
react-email: building HTML email templates with React components, rendering them to HTML, and adding React Email's visual editor to your own app.
email-best-practices: the deliverability skill, covering emails landing in spam, bounce rates, SPF, DKIM and DMARC setup, and compliance with CAN-SPAM, GDPR and CASL. Run it before your first real send.
agent-email-inbox: for systems where incoming email triggers actions, such as AI support inboxes or email-to-task pipelines. Its description treats inbound email as untrusted input, which is the right default for anything an agent reads.
resend-cli: running Resend from the terminal (sends, domains, broadcasts, webhooks, logs).

twilio/skills (official, Twilio)

Twilio's repo is huge, with around 50 skills across Twilio and SendGrid. The ones most indie products need:

twilio-messaging-overview: start here. It compares SMS, WhatsApp, RCS and Messenger, and covers the unified Messages API.
twilio-verify-send-otp: one-time passcodes over SMS, voice, email or WhatsApp with Twilio Verify. This is the right way to do phone login, instead of building OTP storage yourself.
twilio-whatsapp-send-message: WhatsApp's 24-hour service window, template approval and sandbox testing. WhatsApp is how a lot of Indian businesses actually talk to customers, so this one matters if you build for them.
twilio-sms-send-message: SMS and MMS error codes, and a checklist for messages being filtered or blocked.
twilio-webhook-architecture: inbound events, status callbacks and signature validation.
twilio-sendgrid-email-send: transactional and bulk email through SendGrid, if you're on SendGrid instead of Resend.

15. Voice AI and audio

Voice agents are one of the fastest-moving areas right now, which makes official skills more valuable than usual. Model names, latency settings and pricing change month to month. I compared the main platforms in AI voice agents for SMB receptionists, and looked at a real use case in voice-first recruiting.

elevenlabs/skills (official, ElevenLabs). Install with npx skills add elevenlabs/skills.

agents: building voice AI agents, such as voice assistants, customer service bots and interactive characters.
speech-engine: adding real-time voice conversations to your own agent runtime, with WebSocket and WebRTC clients.
text-to-speech and speech-to-text: voiceovers in 90+ languages, and transcription and subtitles with Scribe v2.
dubbing: translating audio and video while keeping the original speakers' voices.
music, sound-effects, voice-changer and voice-isolator: generated music and sound, voice conversion and noise removal.

livekit/agent-skills (official, LiveKit)

LiveKit's set is the most complete lifecycle for voice agents I found, from build to production:

building-livekit-agents: voice and chat agents with LiveKit Agents and LiveKit Cloud.
reading-livekit-docs: looks up current API signatures, CLI flags and model support instead of answering from memory.
testing-livekit-agents: turn-level tests in pytest or Vitest.
writing-livekit-scenarios and running-livekit-simulations: simulated conversations to regression-test an agent before deploying.
debugging-livekit-agents and operating-livekit-agents: live debugging with lk agent debugger, then deploys, rollbacks and secrets in production.

Also in this space: Twilio's twilio-voice-conversation-relay for AI voice agents over phone calls, and OpenRouter's openrouter-tts and openrouter-stt if you'd rather keep one AI provider.

16. Web scraping and browser automation

Scraping is half of what I build: lead lists, trend trackers, the research agents behind this blog. I've written about how the scraping APIs compare and about the agent dashboard we run our scrapers from. These skills are the agent-side version of that work.

firecrawl/skills (official, Firecrawl). Install with npx skills add firecrawl/skills.

The repo is split three ways, which is a nice pattern for any skill repo:

Core (do it now): firecrawl handles any live-web task through the Firecrawl CLI. The focused ones are firecrawl-search, firecrawl-scrape, firecrawl-map (list a site's URLs), firecrawl-crawl (everything under /docs) and firecrawl-agent, which navigates sites on its own to extract structured data.
Build (put it in your product): firecrawl-build, firecrawl-build-scrape and firecrawl-build-search integrate Firecrawl into your app's code rather than running it once.
Workflows (finished jobs): firecrawl-lead-gen, firecrawl-lead-research, firecrawl-deep-research, firecrawl-market-research, firecrawl-seo-audit and firecrawl-website-design-clone, which extracts any site's colors, fonts and spacing into a DESIGN.md.

browserbase/skills (official, Browserbase). Install with npx skills add browserbase/skills.

browser and fetch: drive a browser with natural language through a CLI, or grab a URL without a full browser session.
functions: deploy browser automation as serverless cloud functions on a schedule or webhook.
browser-to-api: turns a site's network traffic into a best-effort OpenAPI spec, which is often better than scraping HTML.
ui-test: adversarial UI testing that reads your git diff and tests only what changed.
add-webmcp: adds WebMCP tools to your own web app so agents can use it properly. If WebMCP is new to you, start with the sweet shop explainer.
safe-browser and autobrowse: a browser agent restricted to an allowlist of domains, and a loop that improves a browsing strategy until a task reliably passes.

vercel-labs/agent-browser (official, Vercel Labs)

agent-browser: a browser automation CLI built for agents, covering navigation, forms, clicks, screenshots and extraction.
dogfood: exploratory QA. It explores your app hunting for bugs and UX issues, which pairs well with the testing skills in section 4.

17. Analytics, feature flags and error tracking

PostHog/skills (official, PostHog)

PostHog has the largest single skill repo in this post: 339 SKILL.md files when I counted, though some are packaged copies of the same skill. Most of them drive PostHog through its MCP server to analyze data, but the ones that matter most while you build are the instrumentation skills. Install with /plugin marketplace add PostHog/skills, then pick plugins such as posthog-integration or posthog-feature-flags.

instrument-product-analytics: adds analytics events for meaningful user actions. It's meant to run after you build a feature or review a PR.
instrument-error-tracking: exception capture with stack traces.
instrument-feature-flags: wraps new functionality in flags for safe rollouts.
instrument-llm-analytics: traces every LLM generation with token counts. Pair it with exploring-llm-costs to see spend by model, user or feature.
creating-experiments and creating-surveys: A/B tests, and NPS or feedback surveys.
investigating-error-issue and cleaning-up-stale-feature-flags: debugging one error end to end, and removing old flags and the code that checks them.

The habit worth stealing: these instrumentation skills describe themselves as things to run after a feature is built. Put "run instrument-product-analytics and instrument-error-tracking" at the end of your feature checklist and every feature ships with tracking already in place.

18. More databases, caching and queues

Section 7 covered Postgres and the big BaaS platforms. Every one of these also has an official skill repo:

Convex: get-convex/agent-skills (official). Over 30 skills. Start with convex and convex-quickstart. Before launch, run convex-reviewer for security, auth and validator checks, and convex-launch-readiness, which its description calls "Lighthouse for your backend." There are also skills for convex-auth, convex-crons, convex-migrate and convex-test.

MongoDB: mongodb/agent-skills (official). mongodb-schema-design covers patterns and anti-patterns, including migrating from SQL. mongodb-query-optimizer handles indexing and slow queries, mongodb-connection handles pools and timeouts, and mongodb-search-and-ai covers Atlas full-text, vector and hybrid search.

Redis: redis/agent-skills (official). redis-core picks the right data structure and key naming. redis-connections covers pooling, pipelining and avoiding slow commands like KEYS. redis-semantic-cache caches LLM responses by meaning, which cuts repeat LLM calls for similar questions. redis-search and redis-security round it out.

Upstash: upstash/skills (official). This is the serverless toolbox: upstash-redis-js for HTTP-based Redis on the edge, upstash-ratelimit-js for rate limiting an API route (do this before you launch anything with an AI endpoint), upstash-qstash-js for queues and scheduled jobs, upstash-workflow-js for long-running workflows that survive serverless timeouts, and upstash-vector-js for embeddings and RAG.

Turso (SQLite): tursodatabase/agent-skills (official). turso-db for the in-process database written in Rust (formerly libSQL), and turso-cloud for the managed version.

PlanetScale: planetscale/skills (official). These are built around letting agents operate databases safely: planetscale-postgres-safety-review, planetscale-pscale-cli-automation, planetscale-query-insights-and-tags, and planetscale-schema-recommendations-agent-loop, which turns schema recommendations into reviewed branches and pull requests without touching production.

19. Vue, Nuxt and Svelte

Not everything is React. The two non-React frameworks with the best skill coverage:

Svelte: sveltejs/ai-tools (official, Svelte team). svelte-core-bestpractices covers modern Svelte 5 code, including reactivity. svelte-code-writer gives the agent CLI tools to look up Svelte 5 docs and analyze components, and its description says to use it for any .svelte file. Svelte 5 introduced runes, so older training data is a real risk here.
Vue and Nuxt: antfu/skills (community, Anthony Fu). vue covers the Composition API, <script setup> macros and reactivity, nuxt covers SSR, server routes and useFetch, and pinia covers stores. Clerk also has official clerk-vue-patterns and clerk-nuxt-patterns.
pnpm, whatever framework you use: pnpm covers workspaces, catalogs, patches and overrides.

20. Python, FastAPI and Go

A lot of AI backend work is still Python. I covered the agent frameworks themselves in Python AI SDKs compared. These skills cover the language and tooling around them:

modern-python (Trail of Bits): sets up projects with uv, ruff and ty, and migrates old pip or Poetry setups. If you install one Python skill, make it this one.
wshobson/agents python-development (community): 16 focused skills, including async-python-patterns, python-testing-patterns (pytest, fixtures, mocking), uv-package-manager and python-project-structure.
fastapi-expert (community, Jeffallan/claude-skills): async APIs with FastAPI and Pydantic v2. The same repo has python-pro for type-safe Python 3.11+.
Go: golang-pro (community) covers goroutines, gRPC or REST microservices and profiling with pprof, and wshobson's go-concurrency-patterns goes deeper on channels, sync primitives and context.

21. Security and code review

Agents write code fast, so they write vulnerabilities fast too. These skills are the second pair of eyes. If you're thinking about audits more formally, AI agent auditing and compliance covers that side.

getsentry/skills (official, Sentry's engineering team). These are Sentry's internal engineering skills, not Sentry SDK setup. Install with claude plugin marketplace add getsentry/skills, then claude plugin install sentry-skills@sentry-skills.

find-bugs: bugs, security issues and quality problems in your current branch's changes. It makes a good "before I push" check.
security-review: an OWASP-style review for injection, auth problems and similar.
code-review and code-simplifier: PR reviews following Sentry's practices, and cleanup that keeps behavior the same.
gha-security-review: GitHub Actions workflows reviewed for exploitable patterns.
skill-scanner: scans agent skills for security problems such as prompt injection. Run it on every community skill in this post before you install it. That's the safety advice from the start of this post, automated.

trailofbits/skills (from Trail of Bits, the security firm):

differential-review: security-focused review of a set of code changes.
semgrep and codeql: static analysis scans. The Semgrep skill presents its scan plan for your approval before running.
supply-chain-risk-auditor: checks your dependencies for advisories and supply-chain risk.
sharp-edges: finds error-prone APIs and dangerous configurations that make security mistakes easy.

Also: Better Auth's security skill (rate limiting, CSRF, trusted origins, session cookies), Firebase's firebase-security-rules-auditor from section 7, and Jeffallan's security-reviewer and secure-code-guardian (community).

22. Git, CI/CD and infrastructure as code

Git and pull requests, from getsentry/skills (official):

commit: conventional commits with issue references.
pr-writer: PR titles and descriptions written for the reviewer.
iterate-pr: loops on a PR until CI passes and high and medium review feedback is handled. This is the closest thing to "fix it until it's green" that I've found packaged as a skill.

CI/CD pipelines:

github-actions-templates, deployment-pipeline-design and secrets-management (community, wshobson/agents): workflows for testing, building and deploying, multi-stage pipelines with approval gates, and secrets handling with Vault or AWS Secrets Manager.
Platform-specific: Callstack's github-actions for React Native builds, and Expo's eas-workflows.

Infrastructure as code: hashicorp/agent-skills (official, HashiCorp). Install single skills by path, for example npx skills add hashicorp/agent-skills/plugins/terraform/skills/terraform-style-guide.

terraform-style-guide: HCL that follows HashiCorp's official conventions.
terraform-test: .tftest.hcl tests with run blocks.
refactor-module: splits a monolithic config into reusable modules.
terraform-search-import: finds existing cloud resources and bulk-imports them into Terraform. This is how you rescue infrastructure someone clicked together in a console.
terraform-stacks, plus Packer skills like aws-ami-builder for machine images.

23. Marketing, SEO and growth

Building is the easy part. These skills cover what comes after, and they're the ones I'd point most indie hackers to first, since distribution is usually the actual bottleneck.

coreyhaines31/marketingskills (community, by Corey Haines). Around 50 marketing skills. Install with npx skills add coreyhaines31/marketingskills, or pick a few with --skill.

SEO: seo-audit, programmatic-seo (template pages at scale), schema (JSON-LD) and ai-seo, for getting cited in AI answers. That last one is the same problem I covered in the AEO guide and AI visibility checkers.
Launch and distribution: launch (Product Hunt and go-to-market), directory-submissions (pair it with our list of 393 SaaS directories), cold-email and lead-magnets.
Conversion and pricing: copywriting, cro, pricing, paywalls and onboarding.
Mobile: aso for App Store and Google Play listings.

Firecrawl's firecrawl-seo-audit from section 16 is a good companion, because it crawls the live site rather than reasoning from your code. And if you're producing content at volume, read how we write 100+ SEO blogs a day before you point an agent at a keyword list.

24. Documents and office files

Sometimes the output isn't code: an invoice PDF, a client report in Word, a pitch deck, a spreadsheet of leads. Anthropic's anthropics/skills repo publishes the source for its document skills:

pdf: read, extract, merge, split, fill forms and watermark PDFs.
docx: create and edit Word documents and templates.
pptx: create, read and edit PowerPoint decks.
xlsx: spreadsheets in .xlsx, .csv and .tsv.
doc-coauthoring: a structured workflow for writing specs, proposals and decision docs together with Claude.

Anthropic's docs note that the pre-built document skills aren't part of Claude Code itself, so installing them from this repo is how you get them there. Check the license in each skill folder before using them in a commercial product.

The 20 skills I'd install first

If this list is too much, start here. One per job, mostly official.

#	Skill	Repo	Why
1	`react-best-practices`	vercel-labs/agent-skills	Fixes the most common React performance mistakes
2	`frontend-design`	anthropics/skills	Stops the default-template look
3	`web-design-guidelines`	vercel-labs/agent-skills	Pre-ship UI and accessibility review
4	`ui-ux-pro-max`	nextlevelbuilder/ui-ux-pro-max-skill	Deeper UI/UX reasoning
5	`shadcn`	shadcn-ui/ui	Correct shadcn components every time
6	`next-dev-loop`	vercel/next.js	Proves a Next.js change works at runtime
7	`webapp-testing`	anthropics/skills	The agent checks its own UI in a browser
8	`animate`	emilkowalski/skills	Motion with intent, not decoration
9	`clerk-setup`	clerk/skills	Auth set up with current APIs
10	`stripe-best-practices`	stripe/ai	Picks the right Stripe API for the job
11	`dodo-best-practices`	dodopayments/skills	Merchant-of-record checkout and webhooks
12	`polar-testing`	polarsource/skills	Sandbox testing before real money
13	`supabase-postgres-best-practices`	supabase/agent-skills	Postgres rules for any Postgres
14	`firebase-security-rules-auditor`	firebase/agent-skills	Catches open Firestore rules
15	`expo-overview`	expo/skills	Routes every Expo task correctly
16	`react-native-best-practices`	callstackincubator/agent-skills	React Native performance
17	`openrouter-typescript-sdk`	OpenRouterTeam/skills	300+ models through one SDK
18	`hono`	honojs/skills	Small, fast APIs done right
19	`docker-build-strategies`	docker/skills	Smaller, safer images
20	`skill-creator`	anthropics/skills	Write the skills nobody has made yet

The next five, from the later sections: find-bugs before every push, skill-scanner before installing any community skill, email-best-practices before your first real email, instrument-product-analytics after every feature, and upstash-ratelimit-js before any AI endpoint goes public.

How to use skills without making things worse

Install per project, not globally. Every installed skill puts its description in context, at around 100 tokens each. Fifty skills you don't need is 5,000 tokens of noise and more chances for the wrong skill to fire. Put framework skills in the project's .claude/skills/ and keep only general ones (design, testing) in ~/.claude/skills/.
Prefer official when both exist. They track releases. Community skills are great for gaps (Rust, Kubernetes, system design), but check when they were last updated.
Read before you install. Skills can run scripts. Open the SKILL.md and the scripts/ folder of anything community-made.
Update them. Manually installed skills don't auto-update. npx skills update refreshes them, and plugin installs update through Claude Code.
Pair skills with MCP when the vendor offers both. Skills teach the agent how; MCP servers let it act. Clerk, Expo, Stripe and Hugging Face all ship both, and the Expo README explains the split well.
Write your own for your stack. The prompts collection for Cursor, Codex and Claude Code is a good source of rules to turn into skills with skill-creator.

Where to go from here

Pick the three categories you work in most, install the official skills for them, and run your next feature through webapp-testing or next-dev-loop before you call it done. That's the shortest path from "the agent wrote it" to "the agent proved it works."

For the bigger lists, VoltAgent/awesome-agent-skills collects skills from official dev teams and the community, and wshobson/agents and Jeffallan/claude-skills cover almost every language.

Everything we've open-sourced ourselves is in the iHateReading open-source projects post. New tools and skill repos go into the monthly magazine as they land.

How to Convert Long Blog Lists Into Instagram Carousels With Nano Banana, AI HTML, and OpenRouter

shrey vijayvargiya — Fri, 09 Oct 2026 10:01:47 +0000

You can write a hundred solid blogs and still lose the week to Canva.

That is the real bottleneck for developer sites with a big archive. The writing is done. The distribution is not. Instagram wants short hooks, dense slides, and a consistent visual system. Your markdown folder wants H2s, code blocks, and 2,000-word essays. Bridging those two formats by hand does not scale.

This post is how we turned that gap into an admin workflow: load the blog list into a table, pick a row, then generate a carousel with either Google Nano Banana images through OpenRouter, AI HTML slides you export locally, or the same mental model as an AI React code generator when you want component-based slides instead of PNGs.

The live tool sits at /ig-post-creator. The ideas below are the design behind it, so you can rebuild the same pattern on your own stack.

The problem is not "more content"

We already publish from a static markdown catalog under blogs-content/. Each file has title, slug, description, tags, and a body with ## sections. That same catalog powers /blog, /articles.json, and the blog sitemap.

What we did not have was a second view of that catalog: one built for Instagram production.

Without that view, every post becomes a one-off design job. You open the essay, invent a carousel structure, rewrite the copy for mobile, pick colors, export slides, and forget which blogs you already turned into posts. After twenty articles the system collapses into a spreadsheet you never update.

So the product is not "an image model." The product is an admin table of blogs with a generate button.

Step 1: Build the admin table from your blog list

Start from the same source of truth you already trust for SEO.

For each markdown blog, derive a row:

Column	Where it comes from
Title / hook	Blog title, shortened for IG
Category	First tag, or a simple heuristic (AI, SaaS, Blog)
Sections	Every `##` heading in the body
Slide count	One slide per H2 (plus cover/CTA if you want)
Status	Idea vs Generated (localStorage is enough at first)
Blog URL	`/blogs/{slug}`

On iHateReading, loadBlogCarouselIdeas() walks the newest markdown posts, strips frontmatter, splits on ##, and returns JSON the admin UI can filter. The page loads that list server-side, then refreshes from /api/instagram/blog-carousel-ideas so the table stays current when new blogs land.

That mapping rule matters more than the UI chrome:

One H2 ≈ one carousel slide.

Long essays become carousels without a second outline. If a post has six sections, you get six teaching slides. If it has three, you get three. You stop inventing structure every time.

If you are still building the content engine that feeds this table, the pipeline in How we write 100 SEO blogs a day for under $10 is the upstream half. This post is the downstream half: archive → Instagram.

Step 2: Give every row two output modes

Once a blog is selected, the admin should ask one question: how do you want the slides rendered?

Mode A — AI images (Nano Banana via OpenRouter)

Google's image models ship under the Nano Banana family. Nano Banana 2 is Gemini 3.1 Flash Image: fast, good text rendering, native aspect ratios. OpenRouter exposes those models through a dedicated Image API at POST /api/v1/images, so you keep one API key and can swap models later.

Our path looks like this:

Read the full blog markdown for the selected slug.
Ask a planning model (chat completions, JSON mode) to turn each section into an IG-native slide plan: short headline, 2–3 word bullets, visual direction. No URLs on the image — link goes in the caption.
For each slide, call OpenRouter images with a 4:5 prompt (1080 × 1350).
Preview the carousel in the admin, then download the PNGs.

In code, the image call is boring on purpose:

const response = await fetch("https://openrouter.ai/api/v1/images", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
    "Content-Type": "application/json",
    "HTTP-Referer": "https://ihatereading.in/ig-post-creator",
    "X-Title": "iHateReading IG Post Creator",
  },
  body: JSON.stringify({
    model: "google/gemini-3.1-flash-lite-image", // Nano Banana 2 Lite
    prompt: slidePrompt,
    aspect_ratio: "4:5",
  }),
});

Use Lite when you are batching a long list. Step up to Flash or Pro when a single carousel needs sharper type. Google's own prompting guide for Nano Banana is worth reading once so you stop writing vague "make a nice carousel" prompts.

Mode B — AI HTML slides (cheap, local export)

Image APIs cost money and take time. For drafts, or for days when you only need structure, generate HTML slides instead.

OpenRouter chat returns JSON slides with layouts (cover, explain, steps, code, cta). The admin renders those as React DOM nodes styled for Instagram. Export uses html-to-image (or any DOM-to-PNG path) so you still leave with files you can post.

This mode is the same idea as AI HTML generators: the model writes structure and copy, the browser paints pixels. You keep brand CSS in your app instead of hoping the image model remembers your fonts.

Mode C — AI React code generator as the slide engine

If you already ship an AI React code generator — prompt in, Tailwind component out — you can treat each carousel slide as a component, not a bitmap.

That path looks like:

Prompt: "Return a single React + Tailwind slide component for this H2 and excerpt. Fixed 1080×1350 frame. No external images."
Preview the component in an iframe or React Live sandbox.
Screenshot or rasterize for Instagram, or keep the component library for Stories / web embeds later.

We wrote about building that generator with Next.js and the Vercel AI SDK in AI React Tailwind Code Generator App. For IG, you do not need a full IDE product. You need a constrained prompt, a fixed canvas size, and a download step. Same architecture, narrower job.

Pick the mode per row:

Nano Banana images when the post needs a strong visual brand.
HTML slides when you want speed and zero image spend.
React components when you want reusable slide kits across channels.

Step 3: Wire OpenRouter once, reuse it everywhere

Do not scatter provider SDKs across the admin.

One key (OPENROUTER_API_KEY), two endpoints:

https://openrouter.ai/api/v1/chat/completions for planning copy and HTML slide JSON
https://openrouter.ai/api/v1/images for Nano Banana / Gemini image models

That split matches how OpenRouter announced the unified Image API: chat for text, images for pixels. It also matches how we already use OpenRouter elsewhere — for example in the AI automated Reddit trend scraper — so ops stays one billing page and one key rotation.

Practical rules that saved us retries:

Keep image generation on the server. Keys never reach the browser.
Cap slides (six to eight) so a bad prompt cannot burn a full day of credits.
Store "Generated" status in localStorage first. Promote to a real DB only when multiple people share the queue.
Soft CTA only on the last slide. Every earlier slide should teach.

The carousel brief that actually works on Instagram

Whether you generate images, HTML, or React, the content brief is the same.

For each section of the blog:

Hook line — under ~8 words, readable at thumb size
Two or three bullets — facts, not paragraphs
One visual cue — sketch panel, code card, or product UI
No URLs on the slide — put the link in the caption / bio

Then close with a soft CTA: "Full write-up on iHateReading" beats "BUY NOW" for a developer audience.

If the source post is distribution-heavy — directories, launches, free traffic — pull hooks from pieces like How to Get Free Traffic to Your Website in 2026 or the 393 SaaS directories essay. The admin table makes that reuse mechanical: pick the row, generate, post.

For the agent-tooling side of wiring models and tools cleanly, the AI Agent Developer Roadmap still applies. This admin is a thin agent: tools are list_blogs, plan_slides, render_image, export_png.

What we are not automating yet

Honest scope:

We do not auto-post to Instagram from this admin. Publishing still needs a human eye.
We do not claim Nano Banana replaces a designer for brand campaigns. It replaces the blank-canvas hour for educational carousels.
We do not generate captions that sound like ads. The blog already has the voice; the carousel compresses it.

The win is throughput. A catalog of a hundred posts becomes a queue you can clear in batches: ten carousels a week from essays you already wrote, without opening Canva ten times.

Build order if you are starting from zero

Static blog list you can read from disk or an API (markdown is enough).
Admin table with search, category, and Generated status.
OpenRouter chat that returns slide JSON from one blog body.
HTML preview + html-to-image export so you can ship before paying for images.
OpenRouter Image API + Nano Banana for the rows that need real artwork.
Optional React generator if you want component slides for web and IG both.

If you want the monthly roundup of tools and posts in this lane, the iHateReading Magazine is the digest. If you want the creator itself, open /ig-post-creator and start from the Blogs tab.

More to come as we add caption drafts and a shared Generated queue.

Cheers,
ShreyZ

Text is Slow: Ask for a Page for AI Agent

shrey vijayvargiya — Mon, 05 Oct 2026 16:13:47 +0000

Andrej Karpathy made a simple point on X : as AI does more of the work, our job moves to oversight and understanding, and plain text is often the slowest way to understand anything. He suggests a ladder of output formats: controlled-language text, diagrams, interactive HTML pages and explainer videos. He also says code is now cheap enough to build large, throwaway software that you use once.

That idea is easy to agree with and easy to forget. This guide makes it practical. Below are five real cases you can set up today in Claude Code, Cursor or Claude, each with a prompt you can copy. Then there are five more ideas for later.

The rule behind every example

Every case follows the same loop:

Take text you already have (a course, a diff, logs, a transcript).
Ask the model for one self-contained HTML file with the data embedded.
Open it in a browser. Read it. Throw it away, or keep it.

Keep the file self-contained. No build step, no server, no external data. That one rule makes it work the same in every tool.

Use case 1: Course blogs into interactive storytelling lessons

Course Blog into Interactive lesson using AI

Problem: Course content is usually long text. Students skim it and forget it.

Fix: Turn each lesson into a scroll-based story with a diagram, a small interaction and a quick check.

Prompt:

Read lesson-03.md. Create lesson-03.html as one file. Make a scroll story: one idea per screen, an SVG diagram for the main concept, one interactive element (a slider, toggle or click-through), and three quiz questions at the end. Write the text in simple technical English: short sentences, active voice. Dark theme.

Where to run it: Claude Code or Cursor, with a loop over the lessons folder. Ask for the same layout every time so the course looks consistent. Check the facts in each lesson yourself before you ship, because a polished page makes a wrong claim look right.

Use case 2: Pull request previews from a commit or diff

Git difference into Visual PR preview

Problem: A diff shows what changed, not what it means. Reviewers read hundreds of lines to find the one risky change.

Fix: Generate a visual preview for each pull request.

Prompt (in Cursor or Claude Code, inside the repo):

Run git diff main...HEAD. Create pr-preview.html as one file. Include: a plain-English summary in five lines, a diagram of the files and functions that changed and how they connect, before and after snippets for the three most important changes, and a list of risks and things to test.

Open the file next to the real diff. Use it as a map, not as a replacement for reading the code. For a team setup, add the file as a CI artifact so every PR has a link. The model can miss a bug, so treat the "risks" list as a starting point.

Use case 3: Daily agent reports for teams

Daily agent report for the teams

Problem: You run several agents. Each one writes a long log. The person who needs the result, such as a manager, a client or the parents of a student using a learning agent, will not read raw logs.

Fix: One interactive daily report.

Prompt:

Here are today's logs from five agents (logs/*.json). Create daily-report.html as one file with the data embedded. Show: a top card with what got done, what failed and what needs a human decision; a timeline per agent; a filter by agent; and a "why" panel that opens on click. Use plain, calm language for a non-technical reader.

Where to run it: A scheduled script collects the logs, calls Claude, writes the file and emails or hosts it. Because the data is embedded, the page works offline when opened from an email attachment. For anything about children, show only what the parents need and do not include private details by default.

Use case 4: YouTube videos into lessons and explainers

YouTube videos into interactive examples

Problem: The best teaching is locked in long videos.

Fix: Archive the transcript, then turn it into a page. TubeLog saves each video's transcript as a Markdown file, which is the ideal input.

Prompt:

Read videos/<channel>/<video-id>.md. Create an HTML explainer with: five key ideas as cards, a diagram of the main process, a glossary of terms, and a link back to the original video. Stay inside the transcript. Do not add facts that the speaker did not say.

That last line matters. If you want a video instead, ask for a scene plan and Manim or Remotion code, one scene at a time. Always read the script before you render.

Use case 5: Codebase onboarding tour

Codebase onboarding tour with architechture map

Problem: A new developer opens a repo with 300 files and no idea where to start.

Fix: An interactive map of the project.

Prompt:

Explore this repo. Create onboarding.html as one file. Show an architecture diagram where each box is clickable and opens a panel with what the module does, its key files and how to run its tests. Add a "follow one request" walkthrough from the entry point to the database. Add a first-week reading order.

Where to run it: Claude Code is best here because it can read the whole repo. Regenerate the file when the architecture changes. Click a few boxes and compare them to the code, since models sometimes describe files they only skimmed.

Five more ideas to try

API docs explorer: Turn an OpenAPI file into a page where you can edit a request and see a sample response.
Incident postmortem: Turn logs and chat into a timeline with a cause diagram.
Meeting transcript to action page: Decisions, owners and deadlines as a checklist.
Contract or policy explainer: Plain-English version with the risky clauses highlighted.
Research paper explainer: The method as an interactive diagram with a glossary.

Implementation Tools

Claude Code: Best for repos, logs and many files at once. Give it a folder and a target filename.
Cursor: Best when you are already in the editor. Use agent mode and open the HTML file in the browser pane or your browser.
Claude (chat): Best for one-off pages. Upload the text and ask for an HTML artefact, then publish or download it.

Summary

Text is the default, not the best option.

For each task that ends with "someone has to understand this," ask for a diagram, an interactive page or an explainer.

Start with one case today. Pick the one you hit most often, paste the prompt, and see how much faster you understand the result.

More to come in the next one

Shrey

How to Build an AI Agent System That Researches 100 Blogs a Day (RSS, Google News, Reddit, YouTube)

shrey vijayvargiya — Sun, 04 Oct 2026 07:38:28 +0000

AI blog research pipeline — overview

We watch more than ten YouTube videos a day for iHateReading. On top of that come dozens of company blogs, a few subreddits, and a news feed. All of it ends up as posts on Rust, JavaScript, React, Node, Cloudflare, Vercel, AI, OpenRouter, Stripe, payments, testing, and whatever else is on the plate.

Reading that much by hand stops working fast. So we turned the research side into a system. Scrapers collect the material, an LLM decides what to look for, a memory stops us paying for the same page twice, and a person reviews what comes out.

This article explains what each source gives you, how to fetch it, where it breaks, what it costs, and how the same pipeline becomes a monthly content-ideas dashboard you can sell.

At a glance — quotable facts

An AI blog content pipeline for high volume research usually combines RSS feeds, Google News RSS, Reddit or OAuth APIs, YouTube transcripts via yt-dlp, an LLM query layer, and a URL hash store so you never pay twice for the same page. RSS is the cheapest source: one HTTP request and an XML parse, with no browser rendering. Google News search feeds use URLs like https://news.google.com/rss/search?q=anthropic&hl=en-US&gl=US&ceid=US:en but items often need redirect resolution and terms restrict commercial reuse. For deduplicate scraped URLs with hashing, normalise URLs (strip utm_*, sort query params, lowercase host) before SHA-256, and store content hashes to skip unchanged pages. A content ideas dashboard SaaS sells daily scored topics and format tags (Comparison, Glossary, FAQ, Explanatory), not auto-published articles — shared niche research keeps unit economics sane at roughly $60–$530/month stack cost before client revenue.

What this system covers

This is the research and ideation layer. It finds topics, pulls source material, and produces structured briefs. Writing, review, and publishing live in How We Write 100+ SEO Blogs a Day for Under $10, which covers the CRM-table writing pipeline and the review step.

Before any architecture, one warning about volume. Google's spam policy on scaled content targets large numbers of pages made mainly to manipulate rankings, whatever tool produced them. A page written by AI from real sources and checked by a person is fine. A thousand templated near-duplicates are not. So every draft in our system starts from real source material, carries a category and a format tag, and gets a human pass before it ships.

The category is the topic (Rust, React, AI, Payments). The format tag is one of Comparison, Glossary, FAQ, or Explanatory, and it picks the prompt template the writer uses later.

The architecture

The system is an AI agent in the practical sense: a loop, some tools, a model, memory, and evaluation. Agent Harnessing: The Part of Building AI Agents Nobody Talks About covers that framing. For blog research it looks like this:

 Goal ("trending AI news this week")
        │
        ▼
  LLM query layer ──► search queries
        │
        ▼
  Source tools:  RSS │ Google News │ Reddit │ YouTube │ LinkedIn/X
        │
        ▼
  Memory (URL hash store) ── skip if already scraped
        │
        ▼
  LLM: summarise, classify (category + format), score
        │
        ▼
  Ideas / briefs ──► human review ──► writer pipeline

Each source gets its own scraper, because each one breaks in its own way. Here they are, easiest to hardest.

Source 1: RSS feeds

Most public blogs publish an RSS or Atom feed, one URL that lists recent posts as XML. Ours is at ihatereading.in/rss.xml.

Fetching a feed takes one HTTP request with fetch or axios and an XML parse. No JavaScript rendering, no login. RSS is the cheapest and most reliable source by a wide margin.

What works for us:

Keep the feed list as data. A table with feed URL, category, and polling interval lets you add a site without a deploy.
Poll gently. Hourly suits most blogs, daily suits slow ones.
Send conditional requests. Pass the ETag or Last-Modified value from the last fetch, and the server can answer with an empty 304 Not Modified when nothing changed. Conditional requests save bandwidth on both ends, and most feed servers support them.
Treat the feed as an index. Many feeds carry only a summary. Store the item link, then fetch the full page only for items that pass your relevance filter.

We run 300+ feeds this way for the iHateReading Magazine. The list is in 300+ websites to stay updated in Software, and third-party reads are on Explore.

Source 2: Google News

Google News is the best source for "what happened this week" topics. You can get it two ways.

A paid news API. Google no longer offers an official News API, so "Google News API" in practice means a third-party service that structures the results for you. You pay per request or per record. It needs the least upkeep, but plans still come with quotas, so don't expect unlimited calls.

RSS and scraping. Google News exposes search and topic feeds as RSS. A search feed looks like this:

https://news.google.com/rss/search?q=anthropic&hl=en-US&gl=US&ceid=US:en

q is your query. hl, gl, and ceid set language and region. Parse it like any other feed. Two catches:

Items link to Google redirect URLs, not the publisher's page. Resolving one costs an extra request, so resolve only the items that pass your filter.
Google publishes the feed for personal use in a feed reader. It carries a notice restricting it to personal, non-commercial use. If you plan to sell something built on it, read the terms first, or use a licensed API.

Scraping the Google News website itself gets blocked quickly. That is where scheduling and rotating IPs come in (see the proxy section below).

Source 3: Reddit

Reddit is where developers ask the questions they can't find answers to: what confuses them, what they're comparing, which threads get upvoted. That makes it the best raw material for FAQ and Comparison posts. We built ours in AI-Automated Reddit Trend Scraper that saved us $1000/month on Content Creation.

The old trick was appending .json to a subreddit URL or using the /rss feeds. Don't count on either. Reports conflict: one analysis says the endpoints still work but are rate-limited, filtered by User-Agent, and unreliable at volume, while other tool authors say unauthenticated JSON access was shut off in 2026. Test from your own server before you build on it.

If you go ahead:

Set a descriptive User-Agent. A blank or generic one is the most common self-inflicted block.
Back off on 429s with exponential delays, not retry loops.
Use the official OAuth API for anything you depend on. Its limits are documented.
Run on intervals. A trend scraper doesn't need second-level freshness. Every 15 to 60 minutes per subreddit is enough.
Add proxies last. Datacenter IPs get blocked fast, and residential ones cost more.

Save score, comment count, and post age with the text. The votes are the signal: 40 comments in two hours beats 2,000 upvotes on a year-old thread.

Source 4: YouTube transcripts

YouTube gives you ideas, plus long spoken explanations that turn into written posts well. The flow: find a video URL, pull the transcript, hand it to the model.

We use yt-dlp for the transcript. It's a command-line tool you install with pip or brew, and Node can call it as a child process. These flags skip the video and fetch captions only, as this subtitle guide shows:

# list available subtitle tracks
yt-dlp --list-subs "VIDEO_URL"

# manual captions if they exist, no video download
yt-dlp --skip-download --write-subs --sub-langs en --sub-format "srt/best" "VIDEO_URL"

# otherwise fall back to auto-generated captions
yt-dlp --skip-download --write-auto-subs --sub-langs en --sub-format "srt/best" "VIDEO_URL"

Try manual captions first. They're cleaner.

Language isn't a problem either. A Hindi video gives a Hindi transcript, and the LLM can summarise it and write the post in English in one pass.

Wrap this in a small endpoint that takes a video link and returns the transcript, and the agent can call it like any other tool. We build these the way we did in One honojs file for entire web scraping API.

Source 5: LinkedIn, X, and Instagram

These are the hardest sources, so use them sparingly.

The official APIs are stable but rate-limited, often pricey, and some need an approved app. Scraping works at small scale with careful pacing and rotating proxies, but it breaks whenever a layout changes, and each platform's terms of service need checking.

We use them for signals only, like which topics a niche is talking about this week, and never as the main source of article text. RSS, news, and transcripts give cleaner material for far less money.

The AI query layer

Collecting data is the easy half. Finding the right data is harder. "Latest AI news" isn't one query, and a hand-written keyword list misses most of what a reader cares about. An LLM is better at trying many angles.

The steps:

Give the agent a goal, like "find the latest trending YouTube videos on AI".
The LLM writes a few focused queries: "top AI news", "latest AI trending", "OpenAI trending news", "Anthropic latest".
Each query runs against a search surface: web search, YouTube search, or Google News.
A scraping step reads each results page and pulls out the URLs.
Each URL goes to the right tool by domain: YouTube links to the transcript endpoint, Reddit links to the Reddit scraper, news links to the article fetcher.
The LLM summarises each result, tags it with a category and format, and drops anything off-topic.

Lock the query generator to an output schema. Ask for JSON with a query string, a target source, and a freshness window, and validate it before running anything. Models write good queries but drift from the format unless you enforce it.

Use a cheap, fast model for the query step, since it's high volume and low risk. Save the stronger model for summarising and scoring, where mistakes cost more.

Memory: store every URL as a hash

Scraping the same page twice costs you twice, once for the fetch and again for the LLM tokens. Memory prevents that.

We store each scraped URL under a hash key with the scrape time. Why a hash:

The same URL always maps to the same key, so duplicates can't sneak in.
A key-value read is effectively constant time. No list scans.
A key plus a small JSON value is all the schema you need.

Normalise before hashing. Lowercase the host, strip tracking parameters like utm_*, sort the query parameters, and drop fragments. Skip this and ?utm_source=x makes every page look new.

import { createHash } from "node:crypto";

function urlKey(raw: string): string {
  const u = new URL(raw);
  u.hash = "";
  u.hostname = u.hostname.toLowerCase();
  [...u.searchParams.keys()]
    .filter((k) => k.startsWith("utm_"))
    .forEach((k) => u.searchParams.delete(k));
  u.searchParams.sort();
  return createHash("sha256").update(u.toString()).digest("hex");
}

// value stored per key
// { url, firstSeen, lastScraped, etag?, contentHash?, ttlHours }

The stored timestamp drives a re-scrape policy based on how the content behaves:

News and Reddit threads: re-check within hours or a day.
Blog posts and docs: wait longer, and re-check with the stored ETag so unchanged pages cost nothing.
Static pages (a published paper, an old announcement): scrape once, cache, never fetch again.

Keep a second hash of the page content. If the URL is old but the content hash changed, there's a real update worth processing. If it didn't change, skip the LLM call. That one habit cuts the biggest cost line in the system.

Scheduling and IP rotation

Give every source its own schedule and spread requests out. Bursts get blocked, and steady trickles mostly don't.

For sources that block datacenter traffic, rotating proxies give each request or session a fresh IP, so no single address hits a rate limit. Watch the bill. Residential rotating proxies commonly cost $3 to $20+ per GB, and some budget providers advertise lower entry prices. You pay for bandwidth, so the biggest saving is not using proxies where you don't need them. RSS, Google News RSS, and transcripts mostly run without.

If you'd rather not run this layer, a managed scraping API handles proxies, retries, and rendering. We compared the options in Firecrawl Alternatives: ScrapeFast vs Firecrawl vs ScrapingBee vs ScraperAPI.

From pipeline to product: a content-ideas dashboard

Most funded startups need a steady stream of content and have nobody to find the topics. A pipeline that scrapes, scores, and tags ideas every day solves that, and it's a recurring need, which is why it works as a subscription.

The dashboard has four parts:

Niche setup per client: competitors, keywords, and target subreddits.
A daily idea feed. Each card shows the topic, category, format tag (Comparison, Glossary, FAQ, Explanatory), source links, and a suggested angle.
A content calendar built from the feed, so the team keeps publishing.
An agent interface on top, so a user can ask "what should we publish on Thursday?" instead of reading a table.

We sell ideas and planning, not auto-published articles. The client's team still writes or reviews, and the dashboard takes over the research. We took the same route for lead generation in From Finding Clients to a Smart SaaS: Building an AI Scraping Agent Dashboard.

What it costs to run (planning ranges, not invoices)

These are planning assumptions for one niche pipeline shared across clients. Measure your own before pricing anything.

Line item	What it covers	Monthly range (USD)
Hosting and database	API, scheduled workers, key-value or Postgres store	$20 to $100
Proxies	Only for blocked sources, roughly 10 to 30 GB	$10 to $100
LLM usage	Query generation, classification, summaries, idea cards	$30 to $200
Optional paid news or scraping API	Replaces the fragile parts of scraping	$0 to $100
Email, auth, payments	Login, digests, billing	$0 to $30
Total shared stack		about $60 to $530

Hosting is the line you control most. Our own site stays under $100 a month at 10k visitors, and we wrote up how. The LLM line is the one the URL and content hashes protect, since every skipped page is a skipped call.

Pricing. Tools in this space publish self-serve tiers; Frase lists $49, $129, and $299 per month. A done-for-you idea feed with a calendar can sit between $99 and $299.

Unit economics. The research cost is shared by every client in a niche, because the same Reddit threads and news items serve all of them. Ten clients on one niche at $99 to $299 is about $990 to $2,990 a month in revenue against roughly $60 to $530 in shared cost. Cost per client drops as you add clients in the same niche and climbs if every client needs a different one. So keep your niches few.

Get the dashboard for your brand

We're opening this up to a few more brands. If you want a content-ideas dashboard for your company or product, email shreyvijayvargiya26@gmail.com with the subject line "Content dashboard" and include:

Your niche, in one line.
Five competitor or reference sites.
The channels you publish on today.

We'll send back a sample idea feed for your niche. You can also find us on X at @treyvijay.

Where to start

Build the RSS fetcher first. It's the cheapest source and it teaches you the rest of the loop. Add the URL hash store before you add anything that costs money per call, then Google News, then the transcript endpoint. Leave Reddit and the social platforms for last, because they break the most. Keep a person reading what comes out the other end.

For a monthly digest of what we're reading and building, see the iHateReading Magazine.

More to come in the next one.

Cheers,
Shrey

Jev, Explained Like You're Five (Then Like You're Actually Building With It)

shrey vijayvargiya — Tue, 22 Sep 2026 10:36:06 +0000

Originally published on iHateReading

Every few months, an AI lab ships something that isn't trying to be a better chatbot, and those are usually the launches worth actually stopping for. On September 15, 2026, a small San Francisco lab called TypeSafe AI came out of stealth with exactly that kind of launch: a model called Jev, and a new category they're calling System One models. It doesn't chat. It doesn't write code. It doesn't generate a single word of text. And a decent chunk of the AI engineering internet spent the following week arguing about whether that's a gimmick or the missing piece nobody noticed was missing.

We got early access this week, so let's actually walk through what it is — starting stupid simple, then all the way down to how you'd wire it into something real.

Jev, explained like you're five

Imagine you have a friend who is incredibly fast at answering yes-or-no questions, or "pick one of these three things" questions. Not slow-and-thoughtful fast — instant. You show them a messy pile of information, ask them ten quick questions about it at once, and they answer all ten before you've finished reading the last one. They never make up an answer that wasn't one of your choices. And they tell you how sure they are, every single time.

That friend is bad at writing you an essay. Ask them to explain something in their own words and they just stare at you — that's not their job. But for "which pile does this go in," "is this true or false," or "how bad is this on a scale of 1 to 3," they're basically unbeatable, and they barely cost you anything to ask.

That's Jev. It's not a smaller ChatGPT. It's a completely different shape of tool, built to sit inside software and make small decisions, over and over, extremely fast and extremely cheap.

Okay, now for real: what is Jev

Jev is TypeSafe AI's first public System One model — a new class of AI model built to return typed, probability-scored decisions instead of generated text. You send it a block of information (they call this the state) plus a set of questions with fixed possible answers, and it returns an answer to every question, each with a confidence score, in one fast pass. Nothing to parse. Nothing that can technically go off-script, because the set of valid answers was defined by you before the model ever saw the input.

The name is a reference to Daniel Kahneman's Thinking, Fast and Slow — the distinction between fast, intuitive "System 1" judgment and slow, deliberate "System 2" reasoning. TypeSafe's bet, laid out in their launch post, is that most of the decisions software actually needs aren't the slow, deliberate kind chat models are built for — they're small, fast, repeated judgments, and nobody had built a frontier model specifically for that job until now.

"Jev" itself is named after the 19th-century economist William Stanley Jevons, of Jevons-paradox fame — the observation that making something more efficient tends to increase total consumption of it, not decrease it, because cheaper access unlocks new uses. TypeSafe is explicitly betting that making a "decision" cost a fraction of a cent will create demand for decisions nobody would have paid an LLM to make.

Developer Flavio Copes put the core idea about as plainly as it gets in his deep-dive on the model: Jev is basically a smart if statement — the kind of conditional you'd reach for the moment the condition you actually care about is a judgment call rather than something code can compute directly.

Who built it, and why it matters that they did

Jev comes from TypeSafe AI, founded by Diogo Almeida, who spent time at OpenAI working on the instruction-following research that became part of ChatGPT's foundation. According to MindStudio's writeup of the launch, TypeSafe emerged from two years of stealth work with roughly $40 million in seed funding behind it, led by DCVC.

That pedigree matters for one reason: this isn't a hobby project or a fine-tuned wrapper around an existing model. TypeSafe built a new architecture, a new "parallel sampler," and a new training method from scratch, specifically because they decided the chat-model paradigm was structurally wrong for automation. Almeida's framing, straight from the announcement, is worth sitting with: language models have been "superhuman at chat for years," so why hasn't that translated into anywhere near as much real automation? His answer is that generating text one token at a time, meant to be read by a human, is the wrong shape for a decision meant to be consumed by code.

How Jev actually works under the hood

Here's where it gets genuinely interesting for anyone who builds software.

The training method: RLCD

Most chat models today are trained with RLHF (Reinforcement Learning from Human Feedback) or RLVR (Reinforcement Learning with Verifiable Rewards) — both of which optimize for outputs that a human rater or a verifier would approve of. Jev is trained with something TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD), which optimizes for something different entirely: probabilities that are epistemically honest. A model that's 90% confident should be right roughly 90% of the time it says that — not overconfident, not randomly inconsistent between similar inputs.

That distinction sounds academic until you realize what it fixes. Ask a normal LLM to rate its own confidence and, per TypeSafe's own comparison table, it "tends to be overconfident and inconsistent" — which means if a model can actually do a task correctly 95% of the time but never signals when it's in the remaining 5%, your code can't safely automate around it. You'd be trusting a coin that doesn't know when it's about to land wrong.

Three primitives: Noul, Choice, Score

Every question you send Jev is one of three types, a breakdown Flavio Copes' guide lays out clearly:

Noul — a yes/no question. Returns a single probability from 0 to 1 that the answer is "yes."
Choice — pick one option from a fixed list you define. Returns the selected option, a full probability distribution across every option, and a confidence score.
Score — a position on an ordered scale you describe (say, three levels of bug severity). Returns a probability-weighted score across the levels, plus the full distribution.

A request looks roughly like this (paraphrased from the public docs, not copied verbatim):

{
  "model": "jev-latest",
  "state": { "ticket": "Export button crashes the settings page in Safari. Works fine in Chrome." },
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "What kind of ticket is `ticket`?",
      "criteria": {
        "bug_report": "Something is broken or behaving wrong",
        "feature_request": "Asks for something that does not exist yet",
        "billing": "Charges, invoices, refunds"
      }
    },
    "severity": {
      "type": "score",
      "instructions": "How severe is the issue?",
      "criteria": [
        "Cosmetic, no impact on functionality",
        "Broken feature, workaround exists",
        "Blocking issue, no workaround"
      ]
    }
  }
}

And back comes a fully typed answer for both questions — plus, according to TypeSafe's own numbers, in around 70 to 500 milliseconds, against 3 to 329 seconds for a typical frontier LLM doing comparable work, and at $0.042 per million input tokens with output tokens free (because there's barely any output to generate in the first place). That pricing framing — "$42 per billion tokens" — is TypeSafe's own way of putting it on their homepage.

The practical limits worth knowing before you design around it

A few concrete numbers matter once you're actually sketching a request rather than just reading about the concept. The state and every question together share a combined budget in the tens of thousands of tokens, and the state plus your single longest question needs to fit inside roughly 32,000 tokens — call it somewhere around 150,000 characters of plain English if you're mentally budgeting. A Choice question can offer up to 255 distinct options, and a Score can have anywhere from 2 to 10 ordered levels. None of these are limits you'll bump into for a typical support-ticket or lead-scoring question, but they matter the moment you try to feed Jev an entire document, a full conversation history, or a genuinely long list of candidate categories.

It's also worth knowing that Jev currently reads text only — plain strings, JSON objects, or arrays of text. No images, audio, or video yet, which rules out a chunk of the "classify this upload" use cases people will inevitably try first.

Why parallel sampling is the actual unlock

A normal LLM generates one token at a time, each conditioned on the last — that's why a longer answer takes proportionally longer. Jev's architecture evaluates every question against the same state independently and in parallel, so adding a fourth or fifth question barely moves the response time. This is the detail that makes the whole "ask everything at once" workflow pattern make sense, which we'll come back to.

Three usage patterns worth stealing before you write your first Jev question

Before getting into the DIY architecture sketch, it's worth covering the practical patterns that early adopters — and TypeSafe's own documentation, per Flavio Copes' extensive write-up — keep converging on. These matter regardless of whether you ever touch Jev directly, because they're really patterns about how to think about cheap, parallel decisions in general.

1. Ask everything at once ("speculative fan-out"). Because every question in a request runs in parallel against the same state, and each additional question only costs its own extra tokens rather than a whole new round trip, the right instinct with Jev is the opposite of how you'd design an LLM workflow. Instead of asking one question, waiting, then deciding what to ask next, you front-load every independent question you might conceivably need — including ones whose answer will only matter for some inputs — and let your code decide afterward which answers to actually use. One published cookbook example batched thirteen questions into a single call and came out roughly 12x cheaper and 10x faster than asking them one at a time, mostly because the shared context only had to be sent once instead of thirteen times.

2. Compose decisions in code, don't ask one giant question. If a real-world judgment depends on several independent factors — say, ticket priority depending on severity, customer frustration, and how much detail the report includes — the temptation is to ask Jev one big "how urgent is this?" question. The pattern that works better is asking three separate, narrow Score questions and then combining them yourself with weights you control:

const score =
  0.6 * normalized(answers.severity) +
  0.3 * normalized(answers.frustration) +
  0.1 * normalized(answers.report_quality)

The advantage isn't just accuracy — it's that when the resulting ranking doesn't match what your team would actually decide, you adjust a coefficient and rerun, instead of rewriting a prompt and hoping the new phrasing doesn't quietly break something else.

3. Gate actions on confidence, not just the answer. A Choice or Score response always comes back with a confidence value alongside the actual answer — computed from how concentrated or spread-out the underlying probability distribution is. The practical pattern is a three-tier gate: act automatically above a high threshold, ask for human confirmation in a middle band, and route to a person entirely below a low threshold. Where exactly those thresholds sit is genuinely domain-specific — TypeSafe's own docs use 0.5 as an example "needs review" floor and 0.9 before letting a destructive action proceed unconfirmed, but those are illustrative starting points, not universal defaults. You're meant to run Jev against your own labeled data first and tune from there.

What if you wanted to build something like this yourself?

You obviously can't rebuild TypeSafe's proprietary architecture over a weekend — RLCD and their parallel sampler are genuinely novel research. But the shape of what they built is something any decent engineer can reason about, and honestly, sketching it out is the fastest way to actually understand why it's fast.

Picture a much dumber, DIY version:

Fix your answer space in advance. Instead of asking an LLM "what should happen here?" and parsing free text back, you predefine every possible answer as an enum, before the model ever sees the input. This alone removes an entire category of failure — the model literally cannot return something outside your schema, because you're not asking it to generate a string, you're asking it to choose or score.
Batch every independent question into one call. If you're already paying for one model invocation with the full context loaded, asking five unrelated questions about that same context is nearly free compared to five separate round trips. This is the same intuition behind function-calling batches, just pushed further because there's no sequential text generation cost per extra question.
Turn every output into a probability, not a label. Instead of returning "category": "billing", return a distribution across every category you defined. This is genuinely the biggest mental shift — a naive classifier gives you an answer; a calibrated one gives you an answer and how much to trust it.
Train (or at least evaluate) against calibration, not just accuracy. A model that's right 90% of the time but never tells you which 10% it's guessing on is far less useful in production than one that's right 85% of the time but honestly flags its own uncertainty. This is the part that actually requires real ML research to do well — you can fake steps 1 through 3 with a system prompt and a JSON schema on top of any existing LLM today, but getting genuinely calibrated confidence out of it is a much harder, much more interesting problem, and it's the part TypeSafe spent two years in stealth actually solving.

If you want to feel this difference yourself without waiting on Jev access, the closest thing available right now is forcing structured outputs on an existing model — the Vercel AI SDK's evaluation function actually supports this exact comparison, letting you run the same typed questions through GPT or Claude via an adapter alongside TypeSafe's own model, so you can see the gap in latency, cost, and self-reported confidence directly.

Cool alternative example: someone already shipped a real tool with it

Within days of launch, a developer named Tamara Tran published fast-jev-compaction — a genuinely clever open-source Claude Code plugin, and one of the clearest "this is what Jev is actually for" examples floating around right now.

The problem it solves: when a long coding-agent session runs out of context, most tools compact it by asking an LLM to summarize the old messages. Summaries are lossy — a specific file path, an exact error string, or a constraint mentioned twelve turns ago can quietly vanish, and you don't find out until the agent breaks something it "forgot" about.

Tran's plugin does something different. Instead of summarizing, it asks Jev two simple yes/no questions about every old tool call in the transcript: should this call stay, given everything else in the conversation, and separately, should its result stay verbatim. Anything that should stay, stays exactly as written — never rewritten, never paraphrased. Anything Jev is confident is no longer needed gets dropped or truncated. Nothing is ever hallucinated back into existence, because nothing is being regenerated — only kept or removed.

The technical details are worth appreciating: the tool sends Jev the entire conversation state on every batch, splits questions across multiple parallel requests to stay under Jev's context window, and lets you tune a keepThreshold for how conservative the pruning should be. Since its launch it's already picked up over 3,000 GitHub stars and more than 170 forks — a strong early signal that "delete precisely, never summarize lossily" is a real pain point Jev happens to be unusually well-suited for.

It's a small tool, but it's a genuinely good illustration of the core idea: nobody needed Jev to write anything here. They needed a fast, cheap, trustworthy yes/no on a few hundred old tool calls, over and over, every time a session got long. That's the whole category.

What people are actually building with it right now

It's been less than a week since launch, so none of this is "production case study" territory yet — but the range of early experiments says a lot about where developers instinctively reach for this kind of model.

Games and real-time loops. TypeSafe's own launch demos included a Doom bot making roughly ten decisions a second purely from structured game state (at an estimated $7/hour), and a Wikiracing bot navigating Wikipedia's link graph by choosing among hundreds of options per step without ever picking a link that didn't exist. MindStudio's coverage also describes a Subway Surfers-style dodge/jump/duck demo and a simulated drone navigating an obstacle course from structured position and distance data — the common thread being tasks that need split-second reactions, not conversation.

Routing and triage. The most commonly proposed production use so far is intent routing — put Jev in front of a support inbox, an agent pipeline, or a helpdesk, and let it decide which handler, model, or human a request should go to, before anything expensive gets involved. LangChain shipped a native integration for exactly this within days of launch, exposing Jev through a TypeSafeClassifier that plugs into existing chains alongside every other model provider LangChain already supports.

Data labeling at a scale that used to be uneconomical. DataCamp's writeup cites an early benchmark where Jev classified over a thousand research papers across two dozen topics for a fraction of a dollar, at roughly a quarter-second per paper — the kind of bulk classification job that was technically possible with a full LLM before, just rarely worth the bill.

Verification, not just generation. A quieter but arguably more interesting pattern is using Jev to check work an LLM already did, rather than to do the original task. One proposed workflow starts with an existing pipeline that generates episode summaries with a full LLM, then runs each individual claim in that summary back through Jev against the original transcript, asking a simple "does the transcript actually support this claim" Noul for every sentence. The generative model still does the writing; Jev becomes the cheap, fast fact-check layer sitting after it, flagging anything with low confidence for a human to look at before it ships. The same shape works for code review — running a handful of Score and Noul questions per changed file in a pull request (security risk, complexity, whether the commit message actually describes the change) and combining them into a risk score in code, rather than asking a full LLM to "review this PR" and parsing prose back out.

Turning free text into features for ordinary machine learning. This one's less flashy but genuinely practical: instead of using Jev's output directly as a decision, you use a batch of Jev questions to turn unstructured text into a set of numeric columns — then feed those columns into a classical model like a gradient-boosted tree. One published example started with eighteen questions and, across a few rounds of refinement, grew to nearly forty, producing dozens of usable numeric features from raw text without hand-engineering any of them.

There's also a real thread of people documenting their own builds on X as they get early access. Roman, who posts regularly about building SaaS products in public, walked through wiring Jev into a working project within his first day of access — the kind of build-log thread that's genuinely more useful than a launch demo, because it shows the rough edges too. Moritz Kremb shared his own hands-on look at getting a real use case running with it, and Sydney Runkle — an engineer at Pydantic, a company whose entire job is structured, type-safe data — weighed in on the launch with the kind of plain-language framing that made the rounds precisely because it cut through the "revolutionary" marketing language and explained, simply, what problem this actually solves for people already fighting with structured output from regular LLMs.

Jev versus the tools you're already using

It genuinely doesn't compete with ChatGPT, Cursor, or Claude Code — it's built to sit inside them, not replace them.

Tool	What you give it	What comes back	Its job
ChatGPT	A prompt or conversation	Generated text	General assistant
Cursor / Claude Code	A coding goal + repo access	File edits, commands, results	Coding agent
Jev	State + typed questions	Choices, scores, probabilities	A decision primitive

A coding agent could call Jev before running a risky shell command, to classify it as read-only, reversible, or destructive — and only proceed automatically above a confidence threshold you set. A support platform could use Jev to decide whether a ticket needs a database lookup, a full LLM response, or a human, before spending money on the expensive path. The generative model still writes; Jev just decides which path gets taken, extremely fast, and (crucially) tells your code exactly how sure it is.

The cost and speed numbers, and why the gap matters more than it looks

The headline numbers — 40x to 200x faster, and dramatically cheaper per call — are easy to read as marketing hyperbole, and TypeSafe itself is upfront that their published multiples sit at the high end of what you'd see in the real world. But the underlying mechanism behind the gap is real, not just clever pricing.

A frontier LLM generating a structured JSON response still has to generate every output token sequentially, and it's priced against both input and output tokens — output tokens typically running several times more expensive than input. Jev skips text generation almost entirely, which is exactly why TypeSafe can offer output tokens for free: there's barely anything to meter. That's not a discount decision, it's a structural consequence of the architecture.

Here's the arithmetic worked out simply, since the raw multiples don't mean much without it. A typical support-ticket triage question, state plus a handful of typed questions, runs around 300 tokens in TypeSafe's own published examples. At $0.042 per million input tokens, that's roughly $0.0000126 per call — call it $1.26 to triage 100,000 tickets of similar size. Run that same volume through a general-purpose frontier LLM at typical structured-output pricing and you're looking at a bill that's easily 20-50x higher, before you even account for the extra latency of waiting on sequential token generation for each one.

Where this actually shows up isn't in one flashy demo — it's in workflows that make the same kind of decision thousands or millions of times. A company running a classification step over every row of a large dataset, or a routing check on every single support message, is the exact shape of workload where shaving 40x off cost and latency compounds into something that changes what's economically viable to automate at all — rather than a one-off call where the difference barely registers.

Where Jev genuinely breaks

No credible writeup of this launch skips the limitations, and TypeSafe itself publishes a running list of what the current model handles badly. The honest version, worth knowing before you reach for it:

It cannot do arithmetic reliably. Counting characters, comparing numeric values, or reasoning about dates as text are all weak spots — that logic belongs in your code, not in a Jev question.
It reads the question you wrote, not the one you meant. Precision in your criteria matters enormously; vague instructions produce vague, low-confidence answers.
It cannot write anything. No summaries, no explanations, no generated replies — if the task needs prose, you still need a real LLM alongside it.
A Score is not a precise measurement. It's a probability-weighted position on a scale you defined, useful for thresholds and ranking, not for reconstructing an exact numeric magnitude — a 1.4 doesn't mean "40% of the way from level 1 to level 2" in any rigorous sense.
Indirection tanks accuracy. Double negatives, a property nested inside a property, anything that needs the model to hop through several logical steps to reach the actual answer, all perform noticeably worse than a question that points straight at the relevant part of the state.
A typed answer isn't automatically a correct one. A Choice will always return one of the options you allowed it to — that's the whole guarantee — but it can still confidently pick the wrong one. Schema correctness and semantic correctness are genuinely two separate problems, and treating "it returned valid JSON" as "it got the right answer" is the single most common early mistake people report.

If you need to count how many items in a list match some fuzzy condition — "how many of these five reviews are actually positive" — the fix isn't to ask Jev to count. It's to ask one Noul per item ("is this specific review positive?") and sum the results yourself in code. The counting stays in code; the judgment stays with the model.

None of that undercuts the core idea — it just draws the actual boundary of where a "decision model" is the right tool versus where you still need a model that can reason and write.

Why this actually matters if you're building B2B or SaaS products

For anyone running the kind of AI-agent stack we've written about before — scoring leads, triaging inbound messages, or deciding what a scraped signal is actually worth before spending an LLM call on it — Jev's whole pitch is directly relevant. A huge share of what people currently pay full LLM prices for isn't generation at all; it's classification wearing a chat model's clothing. Is this lead worth a follow-up? Which of our five categories does this ticket belong to? Is this shell command safe to run unattended? None of those questions need a paragraph back — they need a fast, cheap, trustworthy answer with a confidence score attached, which is exactly the gap that a guardrail layer like the kind covered in our piece on the fight over AI agent sandboxing keeps running into: agents need a cheap way to check their own actions before they take them, not just after.

If even a third of what your agent stack currently spends on full LLM calls is secretly a classification task, this is worth thirty minutes in the playground to find out.

There's a simple back-of-envelope way to check before you spend that thirty minutes: pull last month's AI provider invoice, and go line by line asking "did this call return a piece of writing someone read, or did it return a label, a route, a yes/no, or a score that code then acted on." Anything in the second bucket is a candidate. Most teams running AI-heavy products for more than a few months are surprised by how large that second bucket actually is — inbox triage, lead scoring, moderation flags, and routing decisions all tend to hide inside a chat-completion API call long after nobody's reading the "chat" part of the response anymore.

It's also worth being honest about what doesn't change. Jev doesn't reduce how much you spend on the actual generative work — the emails your product writes, the code your agent produces, the summaries your dashboard shows. It only touches the decisions sitting around that generative work, deciding whether it should run at all, and on what. For a product that's mostly generation with very little routing or classification in between, the realistic saving is small no matter how good the per-call multiple looks on a slide.

Two ways to close this out

If you build things: this is worth an actual afternoon, not a bookmark. Sign up for early access, don't touch the example prompts, and instead paste in one real, boring, recurring decision your own code already hardcodes badly — a support-routing rule, a spam filter, a "is this command safe" check. Run it beside your existing logic for a week before you let it touch anything. The unglamorous decisions are exactly where this model is built to live.

If you're skeptical (reasonably): the fair critique isn't that Jev doesn't work — early, independent writeups from Flavio Copes, DataCamp, and LangChain all corroborate the basic mechanics. The fair critique is that "40x-200x faster" only matters for the slice of your AI spend that's actually classification dressed up as chat completion. For a lot of products, that slice is smaller than the headline number wants you to assume. Measure your own workload before you believe either extreme.

Either way, System One models are a genuinely new shape of tool, not a rebrand of something that already existed — and the fact that a real open-source project shipped useful, non-trivial code on top of it within days of a waitlist-gated early access period is a better signal than any launch benchmark could be.

SaaS Directories in 2026: The Complete Submission Playbook

shrey vijayvargiya — Mon, 21 Sep 2026 01:32:05 +0000

SaaS Directories in 2026: The Complete Submission Playbook

Primary keyword: SaaS directories. Long-tail targets: free SaaS directories to submit in 2026, SaaS directory submission strategy, dofollow SaaS directories list, best SaaS launch directories for indie hackers, Product Hunt alternatives for SaaS launch, how to submit your SaaS to directories.

You ship a product, you post it on X, you tell your five closest indie hacker friends, and then you sit there refreshing analytics waiting for something to happen. Most solo founders skip the boring middle step that actually compounds: getting your product listed everywhere a buyer, a search engine, or an AI model might go looking for it.

That's what a SaaS directory does. Not a growth hack, not a hidden trick — just a listing on a page that a human, a crawler, or a language model visits when someone asks "what tool should I use for X." Do it on five random sites and nothing happens. Do it systematically, on the right sites, with the right information, and it becomes one of the few distribution channels that keeps paying you back a year after you stopped thinking about it.

We maintain a database of 393 SaaS directories — filterable by category, fee type, and domain rank — because we got tired of re-Googling "best SaaS directories" every time we shipped something new. This is the long version of what we've learned running products through that list: which directories are worth the ten minutes, which ones to skip, and how to actually build a submission system instead of doing it once in a panic the week before launch.

Why SaaS directories still matter in 2026

The honest pitch for directories used to be simple: free backlink, maybe some referral traffic. That's still true, but it's no longer the whole story, and treating it as the whole story is why a lot of founders under-invest here.

They're still a real backlink source. A profile on a directory with real domain authority passes link equity to your site the same way it did five years ago. It's slower than a feature in a major publication, but it's also something you fully control and can execute on your own schedule.
They're becoming a citation source for AI answer engines. When someone asks ChatGPT, Perplexity, or Gemini "what's the best tool for X," those systems pull from a citation ecosystem — and a striking amount of that ecosystem is a small number of repeat sources. One analysis of millions of citation links found that over 35% of LLM citations for B2B SaaS products trace back to just ten sources, with Reddit and G2 dominating that list. Directories with real traffic and real reviews are exactly the kind of source that shows up in that citation pool.
They build co-citation patterns. The more often your product appears listed alongside competitors on directories like SaaSHub, AlternativeTo, or StackShare, the more consistently AI systems learn your product belongs in that category — which matters more than any single listing on its own.
They're a compounding, permanent asset, unlike a social post that disappears from anyone's feed within hours or an ad that stops working the second you stop paying for it. A directory listing sits there, gets indexed, and keeps working with zero ongoing spend once it's live.

None of that means directories replace a real distribution strategy. They're one input, not the whole system — but they're a cheap, controllable one, and most solo founders leave it half-finished.

The old "submit to 300 directories" advice is dead

If you search this topic, you'll find plenty of lists claiming "250+ directories" or "500+ sites to submit to." Technically true, mostly useless. A large share of those sites are general web directories sitting at low domain authority with essentially no real traffic, and submitting to dozens of them in a weekend does not build meaningful SEO value the way it might have a decade ago.

Worse, it can actively work against you. Google's link-quality systems are specifically tuned to discount, and in some cases penalize, patterns that look like automated mass submission rather than genuine, gradual listing activity. A cluster of forty low-quality directory links created in a single afternoon reads as spam behavior, not organic growth — even if every individual listing is harmless on its own.

The shift that matters for 2026: quality and relevance beat raw count. A handful of relevant, well-trafficked directories does more for you than a hundred generic ones. One recent breakdown of startup directory submissions put it plainly — the strategic placement in a smaller number of high-quality, niche-relevant directories real humans actually browse is where the actual lift comes from, not the mass-submission approach that stopped working years ago.

That's also the whole reason a filterable, curated database is more useful than a raw list of names. Filtering by domain rank and category before you submit anything saves you from spending an entire evening on sites that will never move a single metric.

Tiering your directory list before you submit anything

Not every directory deserves the same amount of your time. Before you open a single submission form, sort your target list into three tiers.

Tier 1 — the high-authority general platforms. These are the sites almost every SaaS product should be on regardless of niche: G2, Capterra, Crunchbase, Product Hunt, AlternativeTo, SaaSHub, Trustpilot, and similar domain-rank-90-plus platforms. They take longer to fill out properly (some require a review count or verification step) but the backlink and discovery value is worth the extra time. In our own database, entries like Google Business Profile, Trustpilot, and Behance sit at a domain rank around 96–100 — this is the tier those numbers describe.

Tier 2 — general SaaS databases and launch platforms. Broader catalogues where buyers browse and compare software by category or use case, plus the launch-day platforms (Product Hunt alternatives, Show HN, BetaList). Most are free, sit on solid-authority domains, and take only minutes to fill in — genuinely some of the easiest wins on the whole list once Tier 1 is handled.

Tier 3 — niche and vertical directories. Directories scoped to your exact category — AI tool directories if you're building an AI product, dev-tool directories if you're shipping for developers, design-tool directories if that's your audience. Lower raw traffic individually, but the audience-to-submission-effort ratio is often the best of the three tiers, because the people browsing a niche directory already have buying intent for exactly your category.

Work through them in that order. Tier 1 first because the backlinks and review platforms take longest to set up and matter most; Tier 2 next because it's the highest volume of quick wins; Tier 3 last, spread across the weeks after launch as an ongoing habit rather than a one-time sprint.

A submission plan that doesn't burn a weekend

Spreading submissions out is not just about sanity — it also looks more natural to search engines than a sudden burst of new referring domains appearing overnight. A reasonable pace: three to five directory submissions a week, sustained over a month or two, rather than forty in two days.

A four-week structure that works for most solo launches:

Week 1 — the anchors. Crunchbase, G2, Capterra, and your launch-platform submission (Product Hunt or an alternative, scheduled two to three weeks ahead if you're going for a real launch day). These take the longest to set up properly and matter most for both backlink value and legitimacy signals.
Week 2 — the Gartner-family and general-directory cluster. GetApp and Software Advice sit in the same network as Capterra, so once you've filled out one properly, the other two are a near-identical copy-paste. Add AlternativeTo and SaaSHub here too — both are specifically built around comparison and "alternatives to X" search intent, which is some of the highest-commercial-intent traffic a directory can send you.
Week 3 — launch-community and review platforms. BetaList (if you're still pre-launch or want to build a waitlist), Indie Hackers, Trustpilot, and any deal marketplace relevant to your pricing model.
Week 4 onward — niche and vertical directories. This becomes an ongoing weekly habit rather than a finish line: two or three relevant niche listings a week for as long as your category has new ones worth joining.

Track it in a simple sheet: directory name, date submitted, live URL once approved, whether the link is dofollow, and whether it shows up indexed in Google Search Console a few weeks later. That last column matters more than people think — a listing that never gets indexed isn't doing anything for you no matter how high the directory's domain rank looks on paper.

What a strong submission actually needs

Most submissions fail to convert because the founder treats the form like a chore instead of a landing page. Before you touch a single directory, put together one reusable asset kit:

A tagline under 60 characters that states what the product does without marketing filler — "Invoice automation for freelance designers," not "Revolutionizing the future of freelance finance."
A 150–300 word description written for a skimmer, not a reader — lead with the problem, name the specific audience, and end with the concrete outcome. Vague marketing language actively hurts you here: directory editors (and increasingly, AI systems parsing the listing) extract facts, not adjectives.
Four to six real screenshots, not a generic hero image — directories that show the actual product interface convert browsers into clicks better than a polished marketing graphic.
A logo on a transparent background, sized for both light and dark directory themes so it doesn't render as a white box on a white card.
A short demo clip or GIF, thirty to sixty seconds, for the platforms that support media uploads.
Consistent NAP-style details — same product name, same one-line description, same URL structure — across every listing. Directories and AI systems both treat inconsistency as a weak trust signal, the same way a business with three slightly different addresses online looks less credible than one with a single consistent listing.

Build this kit once, store it in a folder, and every submission after that takes five to ten minutes instead of twenty, because you're pasting instead of writing from scratch each time.

Product Hunt and the launch-day platforms

Product Hunt is still the single biggest one-day discovery event for a consumer or prosumer product, and it's still worth doing — but treat it as a spike channel, not your entire directory strategy. In 2026, hundreds of products launch there every single day, and a small indie product without an existing audience can get buried fast.

The mechanics worth knowing before you commit a launch day to it: on an average launch, a large share of your upvotes — often 40 to 60 percent — come from your own existing audience rather than organic Product Hunt discovery, and first-hour velocity matters more to the algorithm than your total vote count by the end of the day. That's why a small pre-launch waitlist, even a few hundred genuinely interested people, tends to outperform a cold launch with zero warm audience.

If Product Hunt doesn't fit your product or timing, there's a real ecosystem of alternatives that have grown specifically because Product Hunt has gotten more crowded:

Hacker News (Show HN) — the standard for developer tools, APIs, and technical products, where a clean, jargon-free post and a frictionless demo matter far more than marketing copy.
BetaList — built for pre-launch products, ideal if you want to build a waitlist before you're ready for a full Product Hunt push.
Indie Hackers — less a directory, more a community, but "build in public" updates there convert into genuine early users because the audience understands the tradeoffs of building solo.
Newer weekly and rolling-visibility platforms — several launch platforms built in the last couple of years intentionally avoid the 24-hour-then-gone format, giving a listing sustained visibility for weeks instead of a single day.

The pattern worth internalizing: don't view a launch as a single event you get one shot at. View it as the start of an ongoing habit of showing up in these communities every time you ship something genuinely worth talking about — a new feature, a pricing change, a milestone.

Mistakes that quietly waste the whole exercise

A handful of mistakes show up over and over in how founders run directory submissions, and each one quietly caps how much value the effort returns.

Submitting to volume over relevance. Forty low-authority general directories add noise to your backlink profile without meaningfully improving it. A DR 40 directory that's the actual bookmark of your exact audience is worth more than a DR 70 directory that lists everything from dropshipping stores to enterprise SaaS with no real curation.
Copy-pasting the same three-sentence description everywhere. Directories (and increasingly AI systems) can tell when a listing reads like it was pasted without customization for that specific audience. A small edit to the first sentence per platform — what problem this specific audience has, why this tool fits them — takes two minutes and meaningfully improves conversion.
Submitting once and walking away. A listing left untouched for a year, with an outdated screenshot or a dead pricing link, is worse than no listing at all — it actively signals the product may be abandoned. Revisit your live listings when you ship something worth updating.
Ignoring dofollow status entirely. Not every directory link needs to be dofollow to be worth doing — a nofollow link from a high-traffic, high-relevance directory can still send real buyers your way — but if backlink value is the primary goal for a specific submission, check the link attribute before spending time on the form.
Treating a launch-day platform as your entire strategy. A Product Hunt spike without an evergreen directory presence behind it is a burst of traffic with nothing left the week after. The directories that actually compound over time matter more, long-term, than any single launch-day leaderboard position.
Never checking whether the listing actually indexed. Submitting a form isn't the finish line. Check Google Search Console a few weeks later — a directory that never gets your listing indexed isn't returning anything on the time you spent filling it out, regardless of how impressive its homepage domain rank looks.

How to actually use a directory database instead of just bookmarking it

This is the part most guides skip: having a list of 300+ directories in a spreadsheet doesn't help you if you never work through it methodically. Here's the workflow we use ourselves:

Filter before you submit anything. Our own SaaS directories page lets you filter by category — Profile / Directory, Social, Publication, Design, or Misc — and by fee type, free or paid, before you ever open a submission form. Start with free, high-rank entries in the category closest to your product; that alone usually cuts a 300-item list down to a manageable 30–40 you'll genuinely act on.
Sort by domain rank inside your filtered set, not across the whole database. A DR 90+ general profile site (Google Business Profile, Trustpilot, G2) and a DR 40 niche AI-tools directory can both be worth your time — they're just worth it for different reasons, so don't discard the lower-DR one just because a higher number exists elsewhere on the list.
Batch by similarity. Several directories in the same family (the Capterra/GetApp/Software Advice cluster is the clearest example) ask for nearly identical information. Do those back-to-back so you're not re-loading context between forms.
Download and revisit quarterly. A directory database like this one changes — new sites appear, old ones go stale. Export the CSV, keep it next to your submission tracker, and treat a fresh pass through it as a quarterly habit rather than a one-time launch task.

If you've already read our shorter roundup of top SaaS directories from earlier this year, this is the deeper, more systematic version of the same idea — the full filterable database plus the actual process for working through it without wasting a weekend on low-value listings.

Every page in the SaaS directories system, and what each one is actually for

The database isn't one flat list — it's split into a few different views depending on what you're trying to do in that moment. Bookmark the ones that match your workflow instead of always starting from the top:

/saas-directories — the full database: all 393 sites, filterable live by category (Profile / Directory, Social, Publication, Design, Misc) and by fee type. Start here when you want the whole picture before narrowing down.
/saas-directories/free — the free-only slice of the database, for when you're prioritizing zero-cost submissions first, which is almost always where you should start a new launch.
/saas-directories/paid — the paid-only slice, useful once you've cleared the free tier and are deciding which paid placements (skip-the-queue Product Hunt slots, premium directory tiers) are actually worth spending on.
Individual directory detail pages — every entry in the database, like Product Hunt or G2, opens its own page with the fee type, domain rank, category, and the direct submission link, so you're not hunting for the actual "submit here" URL yourself once you've picked a target.
CSV export — the full table is downloadable as a CSV (behind a free login) if you'd rather work through your submission list in a spreadsheet with your own tracker columns added, instead of tab-hopping the live filtered view.
/databases-of-databases — the parent index that the SaaS directories database sits inside, alongside every other free aggregator we maintain: Universo, Cursor Rules, and more. Worth a look if directories solved a problem for you and you're wondering what else on the site works the same way.
/universo — a separate curated collection of useful websites, domains, and developer tools, adjacent to but distinct from the SaaS directories list — more "generally useful sites for builders" than "places to submit your product."
/topics/saas — the topic hub that collects every SaaS-focused article on the site in one place, if this playbook has you wanting more on the building and growth side rather than just the submission mechanics.

If you only bookmark one of these beyond the main database, make it the free-filtered view — it's the one you'll actually open first on every new launch.

Where directories fit in the bigger growth picture

Directories are one channel in a stack, not the whole stack. If you're mapping out a full launch plan, our guide to validating and launching a micro-SaaS covers the distribution side beyond directories — build-in-public, Reddit, and the validation steps that should happen before you ever open a submission form. And if free traffic beyond directories is the goal, the complete free-to-paid growth playbook walks through Reddit marketing, Hacker News launches, and Dev.to distribution in the same direct, no-fluff style.

For the rest of our free tools and aggregators beyond just SaaS directories — Cursor rules, job boards, GitHub trending, website template collections — the Databases of Databases index is the single page that rounds all of it up.

The actual numbers to expect

Set expectations honestly going in. A directory submission push, done properly over four to six weeks across 30–50 relevant, high-rank sites, has been associated with domain authority lifts in the range of roughly 5 to 15 points over a three-to-six-month window — a meaningful swing for a metric that usually moves slowly through content alone. That's not a guarantee, and no single number here should be treated as gospel; it's a directional sense of what disciplined, quality-first submission work tends to produce, not a formula.

Referral traffic from any single directory is usually modest — a trickle, not a flood — but it's buying-intent traffic. Someone browsing AlternativeTo is actively unhappy with a competitor and looking for a replacement. Someone searching G2 for your category has already decided they need a tool like yours. That's a very different visitor than someone who stumbled onto your landing page from a random social post, and it's worth more per visit even when the volume is small.

Measure it with tools you likely already have open. UTM-tag every directory link before you submit it so referral traffic shows up cleanly in analytics instead of blending into "direct." Google Search Console tells you whether a listing actually got indexed and whether it's sending any impressions for your product name or category terms. And a basic backlink checker, run every couple of months, tells you whether your referring-domain count is actually growing in the direction your submission log says it should be. None of this needs to be fancy — a spreadsheet with five columns and a fifteen-minute monthly check-in catches almost every problem worth catching.

Frequently asked questions

Are SaaS directories still worth it in 2026, or is this an outdated SEO tactic?
Yes, for a narrower reason than five years ago. The backlink value is still real for high-authority, relevant directories, but the bigger shift is that directories with genuine traffic and reviews have become part of the citation pool AI answer engines pull from when someone asks for a tool recommendation. Low-quality, irrelevant directories are the part of this tactic that's outdated — not directories as a category.

How many SaaS directories should I actually submit to?
Fewer than the "250+ directory list" articles suggest. A focused set of 30 to 60 directories with real domain authority and audience relevance to your category delivers more than mass-submitting to hundreds of generic, low-traffic sites. Quality and category fit matter more than the raw count.

Do I need to pay for directory listings to get value?
No — most of the highest-value directories (Product Hunt, AlternativeTo, SaaSHub, Crunchbase, and the general database at ihatereading.in/saas-directories) offer a solid free tier. Paid placements usually buy you a faster review queue or a featured slot, not a fundamentally different backlink or discovery outcome. Treat paid slots as a launch-week accelerant, not a requirement.

What's the difference between a dofollow and nofollow directory link, and does it matter?
A dofollow link passes SEO link equity to your site; a nofollow link doesn't, but can still send real referral traffic and visibility. If your goal for a specific submission is backlink value, check the link type before investing time in the form. If your goal is discovery or buying-intent traffic (AlternativeTo-style "looking for an alternative" visitors), a nofollow link on a high-traffic, relevant directory can still be worth the ten minutes.

Should I submit to every directory in a database, or filter first?
Filter first. A 393-site database is a resource to search through by category and fee type, not a checklist to complete top to bottom. Start with directories in your exact category and work outward from there — you'll get more done in an hour of focused, relevant submissions than in a full day of submitting to everything indiscriminately.

How long before a directory listing actually helps my SEO or traffic?
Individually, a single listing's effect is usually small and slow — think weeks, not days, before it's indexed and contributing anything measurable. The compounding effect shows up after a sustained run of quality submissions over a month or two, not from any single directory on its own. Treat it as a background habit that pays off later, not an instant traffic switch.

Is Product Hunt still worth doing if I don't have a big audience yet?
It's still worth doing, but set expectations accordingly. A cold launch with no warm audience typically underperforms because a large share of launch-day upvotes come from the founder's own network, and first-hour momentum matters more to the algorithm than the eventual total. If you don't have an audience yet, a smaller launch platform or Show HN post, paired with a few weeks of building a waitlist first, is often a better starting point than a cold Product Hunt launch.

Conclusion

Directory submissions won't replace a real product, real distribution, or real content — nothing does. But they're one of the few growth levers a solo founder can fully control on their own schedule, for free, with a payoff that keeps compounding long after the launch-week adrenaline wears off. The founders who get real value out of this channel aren't the ones who mass-submitted to 300 sites in a weekend; they're the ones who filtered down to the thirty or forty that actually matter for their category, built one reusable asset kit, and spread the work across a month instead of a panic-driven afternoon.

Start with the full filterable database, sort by category and fee type, and work through Tier 1 this week.

Cheers
Shrey

AI Operating System for SaaS Founders: The Skills, the Stack, and the Dashboard Behind It

shrey vijayvargiya — Tue, 15 Sep 2026 17:10:41 +0000

Most "AI for founders" content stops at the prompt. Someone shares a clever prompt for competitor research, you copy it, it works once, and three weeks later you're rewriting the whole thing from memory because you never saved the structure.

This guide is the opposite of that. It's the full system we actually run — end to end — across our own SaaS properties: the structured playbooks that replaced ad-hoc prompting, and the engineering stack underneath them that turns those playbooks into scheduled, logged, cost-tracked work instead of a chat window you have to babysit every morning.

We're publishing the whole thing in one place, broken into categories, because the two halves only make sense together. A good playbook with no system to run it on is still manual labor. A good dashboard with no playbook behind it is just an expensive way to watch nothing happen.

What you'll get in this guide:

Why ad-hoc AI prompting quietly breaks down for founders
The operating system — structured playbooks for Validate, Build, Launch, Grow
The engine room — the actual stack that runs those playbooks on a schedule
The workspace — how we use a CRM when AI is doing the research
How we build our CRM and connect it to AI workflows
How we built an automated Reddit trend research workflow
How internal linking connects the whole content system
Proof this isn't theoretical — where it runs today
The free resource — get the system map sent to your inbox

1. Why we stopped relying on individual AI prompts

The leverage story is real. Founders using AI tools day to day are genuinely cutting research time and shrinking MVP timelines, and that's a big part of why solo operators can now run products that would have needed a small team a few years ago, as The Entrepreneur Studio's breakdown of solo founder productivity in 2026 lays out.

The part that doesn't get talked about enough is what happens after the honeymoon. Salesfully's look at enterprise AI rollouts found that teams relying on unstructured, one-off prompts run into meaningfully higher error and hallucination rates on anything with real complexity, compared to teams working from a grounded, repeatable process. For a founder, that shows up as an SEO audit that misses your actual site structure, a competitor breakdown that invents a feature your rival doesn't have, or a content calendar that reads like it was written for someone else's product.

The underlying reason is structural, not a prompting-skill problem. As one workflow-design writeup put it, a prompt is a one-off interaction, while a system is repeatable leverage — and repeated manual prompting quietly creates its own cognitive debt. Every time you re-explain a task because you didn't save the version that worked, you pay a small tax. Do that across ten recurring founder workflows for a year and the tax is real hours you don't get back.

We hit this ourselves before we thought about packaging anything. Running several SaaS properties at once means a constant stream of blog content, SEO audits, competitor checks, and lead research, and re-explaining "research this competitor" or "find SEO gaps" from scratch every time produced wildly inconsistent output. Some weeks it was excellent. Other weeks it drifted, because the instructions weren't consistent — the model hadn't changed, the process had.

So we split the fix into two layers, because they solve two different problems:

What to ask for — a structured set of playbooks, organized around how founders actually work
How it runs — the engineering underneath that turns those playbooks into scheduled, logged, observable jobs instead of something you trigger by hand every morning

That distinction ended up being important for us. We didn't need another collection of prompts. We needed a way to turn a task we repeat every week into something closer to a small internal product.

The rest of this guide walks through both.

2. The playbooks we use across the founder lifecycle

Every SaaS founder ends up doing roughly the same categories of work on a loop, just with a different product name swapped in each time:

Validate — understanding a market, a competitor, or an idea before committing real time to it
Build — scoping an MVP, pricing it, deciding what actually belongs in v1
Launch — planning positioning, channels, and the first wave of distribution
Grow — SEO, content gaps, internal linking, AI-search visibility, lead research, ongoing audits

Once it was obvious we were solving the same problem in each category over and over, the fix was to stop treating every task as a fresh conversation and instead build one structured workflow per task that could be reused across every property, every time, with consistent quality.

This is also why the broader shift in AI tooling this year matters: the industry is moving away from treating a single strong prompt as the finished product, and toward treating prompts as one input inside a larger workflow system with defined stages and checkpoints. Structuring the work around the actual founder lifecycle — rather than a flat pile of disconnected templates — made it something you could pick up at whatever stage you're actually in.

We're deliberate about keeping this curated rather than exhaustive. There are plenty of open collections of founder-facing AI workflows floating around GitHub and marketplaces, some genuinely good, most uneven, and most requiring you to sift through dozens of files to find the handful that apply to your actual stage. As generative AI keeps moving from novelty to baseline infrastructure, the value of raw, ungrounded prompting keeps dropping — the money isn't in the prompt text anymore, it's in the structure, the sequencing, and the judgment calls about what a founder actually needs at each stage, made once so you don't have to remake them every week.

A system you've committed to — even in a small way — also tends to be the one you actually keep using, versus a free download that joins twelve other free downloads you never opened. The founders behind Ship or Die describe a version of this in their own solo-founder playbook: a small, public commitment is often the thing that keeps a solo operator from stalling out.

If you want the packaged, ready-to-run version of this layer, it's what we sell as SaaSFounderOS — you can see the current breakdown by stage there, or grab it directly on Gumroad.

3. The stack behind the workflows

A playbook is only useful if something runs it without you opening a chat window every morning. This is the part most "AI for founders" content skips entirely, so we're covering it in more depth.

3.1 What is actually running

The stack is intentionally boring:

A small backend — a lightweight framework is enough; a full microservice architecture is not needed at this stage
The Vercel AI SDK — handles model calls, streaming, structured generation, and tool calling behind one consistent interface
OpenRouter — one integration point for multiple model providers, instead of maintaining separate SDKs for every model you want to try
A database — every job writes its output, status, model used, and token usage
Cron jobs — scheduled research and content tasks, not manual triggers
A dashboard — the human-facing layer where you see what happened and what it cost
Search and fetch tools — used only by the specific tasks that genuinely need fresh external information

That's enough for a surprisingly capable AI content and research operation. You don't need a vector database, a message queue, or a dozen microservices on day one, and you definitely don't need a "multi-agent swarm" because your blog needs three new topic ideas. Start with plain functions. Turn the ones that keep working into reusable, named workflows later.

3.2 How the pieces connect

At a high level, a content task flows through research (web, competitor sites, your own site data), into a model call routed through OpenRouter, into a structured output, into a database row, and finally into a dashboard where a human reviews it.

That's the whole loop — one application, not a distributed system, and you can split pieces out later only if you have an actual reason to.

The mental model worth keeping is:

Your application → AI SDK → OpenRouter → selected model → structured output → database → dashboard.

Your application never needs to know how every individual provider's SDK works. If a model gets expensive for one task, or a new one performs better at classification, you change a configuration value rather than rebuilding the application.

That separation became particularly useful once we started running different workflows. A content research job, a lead research job and a simple classification job don't need identical models, identical prompts or identical context.

They just need to return predictable output to the same system.

3.3 We don't use the same model for everything

The mistake most people make here is asking "which AI model is best?" The better question is: which is the cheapest model that reliably completes this specific job?

Split work into roles rather than picking one model for everything:

High-judgment work — writing, strategy, nuanced editing, final recommendations — justifies a stronger, more expensive model
High-volume work — classification, tagging, summarization, duplicate detection, simple scoring — almost never needs your most capable model
Fresh research — the model is only as good as what it's fed; a cheap model with good source data will outperform an expensive model working from thin context every time

Rough current pricing (this changes constantly, so treat it as a snapshot to sanity-check against, not something to build a budget on directly):

Provider Tier	Model	Input $/1M tokens	Output $/1M tokens	Best for
Anthropic	Claude Opus 5	~$5.00	~$25.00	Judgment-heavy work
Anthropic	Claude Sonnet 5	~$3.00	~$15.00	Default drafting, SEO checks
Anthropic	Claude Haiku 4.5	~$1.00	~$5.00	Classification, tagging
OpenAI	Mid-tier flagship	~$2.00	~$12.00	General writing tasks
OpenAI	Budget tier	~$0.20	~$1.20	Bulk, low-stakes tasks
DeepSeek	Flash tier	~$0.15–0.30	~$0.60–1.20	High-volume, cost-sensitive jobs

Route by task, not by habit — a writing task gets your stronger model, a classification task gets your cheapest reliable one, and a research task gets whatever model performs best once it has good source data underneath it.

Making this a small config object rather than hardcoded model names means swapping providers later is a one-line change, not a rewrite.

3.4 We log every AI job

This is the part worth doing from day one, before the dashboard even looks good.

Every AI job should write a row recording:

task name
workflow
model
input tokens
output tokens
cost
duration
status
sources used
output
errors, if any

Once that exists, "how much did AI actually cost us this month?" stops being a guess and becomes a number you can pull up.

A simple dashboard on top of that log is already useful:

today's tasks
today's spend
monthly spend
successful jobs
failed jobs
model usage
workflow usage
cost per workflow
click-through into the actual report

You don't need it to be beautiful.

You need it to be honest.

3.5 AI finishing a task doesn't mean the task is correct

None of this makes AI correct — it makes AI observable.

A task finishing with a "success" status means the function completed, not that the output was right.

For anything that touches SEO, customer communication, financial information, or anything that could damage your reputation if it's wrong, keep a human review step between the model's output and publishing.

Observability is what lets you catch drift early; it's not a substitute for review on the things that matter.

4. The CRM is where the AI work becomes useful

Once your playbooks are running as scheduled jobs, they start producing business objects, not just documents.

A research workflow might discover:

a potential customer
a competitor
a pricing change
a new content opportunity
a Reddit discussion
a sales lead
a product request
an SEO opportunity

If all of that ends up as Markdown files or rows in random spreadsheets, you've automated the research but not really automated the business.

This is where a CRM becomes useful.

We've built SaaSCRM around this idea: the CRM shouldn't just be a place where a founder manually types leads into tables. It should be a workspace that both the founder and AI workflows can write into.

A research agent can find a potential lead.

A lead-research workflow can enrich it.

A sales workflow can assign a status.

A content workflow can create a follow-up task.

And the founder can see the whole thing from one dashboard.

That changes the role of the CRM from:

"software I use to maintain customer records"

to:

"the structured business workspace my automations can operate inside."

5. How we actually build a CRM for a business

One thing we learned while building SaaSCRM is that most CRM projects become unnecessarily complicated because they start with screens instead of the business model.

Someone says:

"I need a CRM."

Then the project immediately becomes:

contacts
companies
deals
pipelines
tasks
calendars
dashboards
reports
permissions
notifications

Six weeks later there are 50 screens, but nobody has answered the most important question:

What does this particular business actually need to track?

We prefer starting with the entities.

For a software company, that might be:

Lead
Company
Contact
Deal
Task
Activity

For a manufacturing company it could instead be:

Customer
Enquiry
Product
Quotation
Order
Delivery
Follow-up

For an agency:

Lead
Client
Project
Proposal
Invoice
Task
Campaign

The database should follow the business rather than forcing every business into the same CRM vocabulary.

That's why the way we approach SaaSCRM is closer to a reusable CRM foundation than a single fixed CRM.

We build the common pieces once — authentication, database access, layouts, tables, forms, dashboards, filtering, search, charts, permissions and reusable UI components — and then shape the actual CRM around the business entities.

Start with the data model

Before building screens, we define:

What entities exist?
What fields do they have?
How are they related?
What actions can users perform?
What should AI be allowed to create or update?

For example:

Lead
 ├── name
 ├── email
 ├── company
 ├── source
 ├── status
 ├── notes
 └── assignedTo

Then:

Lead
  ↓
Contact
  ↓
Opportunity
  ↓
Deal
  ↓
Customer

The UI is built around this model.

This also makes it much easier to connect AI later because the agent knows what a "lead" actually means and what fields are allowed.

Then build the reusable UI

Instead of making every table from scratch, we keep reusable components for:

data tables
filters
search
forms
modals
detail pages
status badges
dashboards
charts
activity timelines
empty states
loading states

This is one of the reasons a CRM foundation becomes valuable.

When a new business needs a different entity, we're mostly configuring the existing building blocks rather than rebuilding the application.

Then connect the AI layer

This is where it gets interesting.

Suppose an AI agent researches 50 companies.

Instead of returning:

Here are 50 companies I found...

the workflow can produce structured records:

Company
Contact
Website
Industry
Potential use case
Source
Confidence
Next action

Those records can go directly into the CRM.

The same idea works for content research.

An AI workflow finds a Reddit discussion that suggests a common problem.

Instead of leaving that insight inside a chat conversation, we can create:

Research Item
Topic
Source
Problem
Potential Feature
Priority
Status

Now the research becomes something the rest of the business can act on.

6. How we built the Reddit trend research workflow

One of the practical examples of this approach is our automated Reddit trend research workflow:

AI-Automated Reddit Trend Scraper That Saved Us $1,000/Month on Content Creation.

We wanted to know what developers and founders were actually discussing instead of constantly guessing what we should write about.

The first version was simple:

Find discussions → collect them → clean the data → identify patterns → turn patterns into content opportunities.

The workflow eventually became a small pipeline.

Step 1: Collect discussions

The scraper collects relevant Reddit discussions based on the topics we're researching.

We're not interested in collecting Reddit for the sake of collecting Reddit.

We're looking for signals:

repeated questions
complaints
product requests
recurring problems
tools people are comparing
things developers can't figure out
emerging topics
unusual spikes in discussion

Step 2: Clean and enrich the data

Raw scraped discussions aren't particularly useful.

There can be duplicate conversations, irrelevant comments, short answers and discussions that have nothing to do with our actual content strategy.

So the workflow cleans and structures the data before sending it into the model.

We can then attach things like:

Topic
Problem
Audience
Industry
Intent
Potential article
Potential product
Priority
Source URL

Step 3: Let AI find patterns

This is where the LLM becomes useful.

Instead of asking:

"What should I write about?"

we give it actual discussions and ask it to identify recurring patterns.

For example:

20 discussions
      ↓
common problem
      ↓
search intent
      ↓
content opportunity
      ↓
potential product/feature

The important part is that the model isn't inventing the initial demand.

We're giving it real conversations to analyze.

Step 4: Turn research into content

The strongest findings can become:

blog posts
comparison articles
tutorials
tools
lead magnets
product features
FAQ sections
social posts

That means one research workflow can feed multiple parts of the business.

Step 5: Connect it back to the rest of the system

This is the part that makes the workflow more useful than a standalone scraper.

The research output can feed our content planning system.

The content planner can identify:

Existing article?
        ↓
Update it

or:

No existing article?
        ↓
Create new article

or:

Product problem?
        ↓
Create feature opportunity

This is where the AI operating system starts becoming a loop rather than a collection of unrelated AI tools.

7. Internal linking is part of the system too

Creating a new article isn't the end of the job.

One of the easiest things to miss when publishing frequently is internal linking.

If you publish 100 articles and none of them are connected properly, you have 100 pages.

You don't necessarily have a useful content system.

We treat every new article as another node in the existing knowledge graph.

For example, the Reddit automation article can connect to content about:

AI content research
Reddit scraping
AI agents
web scraping
OpenRouter
Hono
SEO automation
content planning

Then a new article about AI content research can link back to the Reddit automation article.

Over time this creates a structure like:

                 AI Content
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
      Reddit       SEO        AI Agents
      Research     Tools       │
          │          │          │
          ↓          ↓          ↓
       Scraper    Content     Automation
          │        Planning      │
          └─────────┴────────────┘
                    ↓
                SaaSCRM

The goal isn't to add links just because an SEO checklist says "add internal links."

The goal is to make related information discoverable.

How we decide where a new article should link

When a new article is created, we can look at the existing content inventory and ask:

What existing articles explain concepts mentioned here?

What older articles should link to this new article?

Which product pages are relevant?

Which pillar/topic page should this article belong to?

Which pages are currently orphaned?

This turns internal linking into another repeatable workflow.

Instead of manually remembering every article we've published, the system can use the content database to find relevant connections.

It also helps us update old content

Suppose we publish a new article about AI Reddit research.

We can find older articles mentioning:

Reddit
content research
AI agents
scraping
SEO
content automation

Those pages may now have a natural reason to link to the new article.

So one new article can improve the structure of several older pages.

That's much more useful than publishing and forgetting.

8. The dashboard ties the whole thing together

At this point there are several different things happening:

Research
SEO
Content
Leads
AI jobs
CRM
Costs
Internal links

Without a dashboard, it becomes difficult to know what is actually happening.

The dashboard doesn't need to become another complicated SaaS product.

For us, the useful information is fairly simple:

AI activity

Jobs today
Successful
Failed
Running

AI spend

Today
This week
This month
By model
By workflow

Content

Ideas
Research completed
Articles drafted
Articles published
Articles needing updates

SEO

Pages gaining impressions
Pages losing impressions
Keyword opportunities
Content gaps
Internal linking opportunities

CRM

New leads
Open opportunities
Follow-ups
AI-created records
Recent activity

The dashboard is essentially the control panel for the system.

The individual workflows do the work.

The dashboard tells us what happened.

9. Where we run this today

None of this is a thought experiment — it's the system running across our own properties:

ihatereading.in — our primary distribution property, grown to roughly 10,000 registered users, with the content and SEO layer of this system driving its blog output and directory listings
saascrm.site — the CRM and admin layer described above, doubling as its own product and as the workspace for agent output across our other properties
gettemplate.app — our template marketplace, using the same content and SEO playbooks to plan and publish
buildsaas.dev — the underlying application boilerplate several of these properties are built on, including the frontend, backend, and admin panel pieces the dashboard sits on top of

Running the same system across four different properties is exactly why it had to be structured rather than ad-hoc in the first place.

A prompt you remember works on one site.

A logged, scheduled, cost-tracked workflow works on all of them without you personally re-explaining the task four times.

10. The system is more useful when everything feeds the next step

The biggest change wasn't actually adding more AI.

It was connecting the outputs.

A simplified version looks like this:

Reddit
  ↓
Research
  ↓
AI analysis
  ↓
Content opportunity
  ↓
Keyword / search intent
  ↓
Article
  ↓
Internal linking
  ↓
SEO data
  ↓
New research
  ↓
Next article

And alongside that:

Research
  ↓
Lead / Product opportunity
  ↓
CRM
  ↓
Task
  ↓
Founder action

And underneath everything:

AI workflow
  ↓
Model
  ↓
Tokens
  ↓
Cost
  ↓
Database
  ↓
Dashboard

That's the operating system we're interested in.

Not an AI that magically runs a company.

A collection of small, understandable workflows that continuously produce useful information and put it somewhere the next workflow — or the founder — can actually use.

11. The System map

We put together a condensed, practical version of everything above — the four-stage playbook map (Validate, Build, Launch, Grow), the task-logging schema you can copy directly into your own database, and the current model-routing cheat sheet — as a single free download.

check more on saasfounderos

12. What happens after you grab it

The free resource gets you the map.

If you want the actual ready-to-run playbooks — the full set covering research, SEO and AI-search, and growth and launch, organized the way this guide describes — that's SaaSFounderOS on Gumroad.

If you're at the point where your playbooks need a real workspace to write into, saascrm.site is the CRM layer built for exactly that.

The important part isn't whether you use our exact stack.

You can replace OpenRouter.

You can use another database.

You can use a different CRM.

You can run the workflows manually.

The principle stays the same:

Take recurring founder work, turn it into a structured workflow, give that workflow a place to save its output, and make the result available for the next decision.

That's what makes the difference between using AI occasionally and actually building an AI operating system around your business.

And once you've done that for one workflow, you can keep adding the next one.

Either way, the point of publishing the whole system in one place — playbooks and stack together — is the same point behind building it in the first place: stop rebuilding the same instructions every week, and start running a system that remembers what worked.

That would be enough for today

See you in the next one

Cheers

Shrey

I Gave Claude 10+ SaaS Growth Skills and Let It Run My Own Platform

shrey vijayvargiya — Wed, 09 Sep 2026 10:54:27 +0000

Run an entire online content website using 10 Claude Skills, originally published on iHateReading

Under the Hood

I run iHateReading, saascrm.site, and a handful of other products alone. No marketing hire, no SEO agency, no growth team.

For years, that meant every "should we submit to this directory" or "is our GEO okay" question sat in a notes app, half-answered, because I didn't have a spare afternoon to research it properly.

So I built 15 Claude Skills — one operator hub plus 14 specialized agents — that do the SaaS growth research work I used to put off: market intel, competitor teardown, pricing analysis, SEO/GEO audits, directory submissions, internal linking, lead research, launch planning. Then I pointed the whole pack at my own site, ihatereading.in, and let it run.

This post is the receipts: what the skills actually found, what they got right, and where the pack is available if you want to run the same stack on your own product.

What a "Claude Skill" actually is

A Claude Skill is a markdown instruction file — usually named SKILL.md — that gives Claude (or Claude Code) a specialised, repeatable playbook instead of a one-off prompt. You invoke it, Claude follows the same research method every time, and you get a consistent output format instead of reinventing the wheel each session. Bootstrapped founder Violetta Bonenkamp put it plainly in her own breakdown of running an SEO operation through Claude Skills: the whole approach is built around giving the model a pre-loaded, specialised playbook rather than asking it to improvise research from scratch every time.

This isn't a niche hobby anymore. Snyk's own roundup of Claude Skills for entrepreneurs and solopreneurs covers everything from SaaS financial modelling to full open-source marketing-department skill collections — the pattern is the same across all of them: turn a research or ops task you'd normally outsource into a repeatable skill you run yourself.

Why solo founders specifically need this right now

The one-person startup stopped being a compromise. Data cited in MeanCEO's breakdown of the solo-founder AI agent stack shows over a third of new ventures in 2026 are solo-founded, and a functional AI agent stack now runs a few hundred dollars a month against the equivalent five- or six-figure monthly cost of hiring humans for the same functions. Forbes reported similar numbers this year, pointing to full AI stacks costing $3k-$12k annually against $80k-$120k a month for a comparable human hire.

That gap is exactly where a growth-ops skill pack earns its keep. You're not trying to replace a strategist — you're replacing the research grunt work that used to stop you from ever getting to the strategy conversation in the first place.

What's actually inside the pack

The 15 skills are split into three groups:

🔎 VALIDATE — is there a market for this

SaaS Discovery — understand a product, its audience, positioning, features, pricing, competitors
Market Intelligence — market/category trends, demand, opportunities, risks
Competitor Intelligence — competitor positioning, strengths, weaknesses, sentiment
Pricing Intelligence — pricing, packaging, value metrics, positioning

🛠️ BUILD — turn the idea into a concrete plan

Micro SaaS Builder — validated MVP concept, pricing, distribution, launch plan6. AI Agent Opportunity — evaluate workflows worth automating, demand, competition, monetization7. Lead Research Intelligence — ICP, lead sources, directories, communities, partnerships8. SaaS SEO Discovery — baseline SEO opportunities from your product and site before you launch

🚀 LAUNCH — get your first users

SaaS Launch — launch strategy: positioning, channels, assets, timeline10. Directory Launch — directory/community submission plan

📈 GROW — compound growth once you have users

Find the opportunity:

SEO Opportunity — commercial, use-case, comparison, alternative, informational opportunities
Competitor SEO Pages — competitor-driven pages you should create
Content Gap — content competitors have that you're missing
GEO/AEO Audit — AI search / answer-engine visibility audit

Plan & execute:

SEO Content Planner — clusters, priorities, briefs, internal links, publishing plan
SEO Page Generator — complete SEO pages from validated opportunities
Internal Link Optimiser — weak, missing, orphaned, high-value linking opportunities

One hub skill (/founder-saas-skill or /saasfounderos) sits on top, asks two quick questions — what you have, what you want this week — and routes to the right agent instead of dumping all 15 on you at once.

What happened when I ran it on my own site

I didn't just build this and ship it blind. I ran the GEO/AEO Audit skill on ihatereading.in itself, and it caught something I'd genuinely missed: a near-identical, completely unrelated site (an AI reading-summarizer) sits at a lookalike domain, which creates real entity-confusion risk for any AI system trying to answer "what is iHateReading." That's exactly the kind of gap Mintlify's own research into llms.txt and AI citation behavior points to — Vercel reportedly gets 10% of signups directly from ChatGPT citations, which only happens when the entity is unambiguous to begin with.

The SEO Content Planner skill then turned that finding into an actual publishing plan — five pages, in priority order, starting with the cheapest fix (a plain-language FAQ page) instead of a bloated 30-page content calendar nobody would ship. The Directory Launch skill found one specific, verifiably free, dofollow-linked developer directory worth submitting to instead of a copy-pasted list of 200 sites. And the Internal Link Optimizer skill mapped exactly which existing posts — like the one on building a directory listing site that earns online — were sitting orphaned with no path back to my own SaaS directories page.

None of that came from generic prompting. It came from agents built specifically to research a real business and refuse to invent URLs, traffic numbers, or fake authority scores along the way — the same discipline SE Ranking's own Claude Skills collection builds in by tying every skill to a defined, reproducible tool call instead of letting the model improvise.

How to actually use these well

Run one agent per session. The hub skill is built to stop you from dumping all 15 on a single question — pick the one that matches what you need this week.
Feed it a real URL, not a vague idea. Every agent researches your actual site/product before making recommendations; the more concrete the input, the less it has to guess.
Treat the output as a starting draft, not gospel. These skills are built to flag "unknown" instead of inventing a number — when they say a stat is unverified, believe them and check yourself before publishing it.
Chain agents in sequence when the task calls for it. SEO Opportunity → GEO/AEO Audit → SEO Content Planner → SEO Page Generator is a full pipeline, not four disconnected reports.
Use the smallest output that solves the actual problem. The Directory Launch skill can find one directory just as easily as fifty — ask for exactly what you need.

Get the pack

If you want the same 15-agent hub running on your own product — the exact GEO audit, content plan, directory pick, and internal-link fixes shown above — grab the founder Claude SEO & growth skills pack on Gumroad. It installs the same way described above: drop it into Claude Code, Claude Desktop, or upload the individual skill zips directly into a Claude.ai project.

I'll keep publishing what the pack finds when I run it on my other properties — subscribe to the iHateReading newsletter or catch the monthly rundown in the iHateReading Magazine if you want the next audit as it happens.

That would be enough for today

See you in the next one

Shrey

GPT-6 Astra Just Shipped. The Real Opportunity Isn't the Model — It's Everything Around It

shrey vijayvargiya — Mon, 07 Sep 2026 13:34:59 +0000

Originally published on iHateReading

Under the Hood

OpenAI shipped GPT-6 Astra this week, and the framing was different from every GPT launch before it. This wasn't pitched as a better chatbot. It was pitched as a system that operates your computer — browsers, spreadsheets, terminals, IDEs — the way a person would, and finishes multi-step jobs instead of just describing them.

I've been building on top of models for a while now — Aantraa runs on translation and generation pipelines, the Scrapefast work is agent-adjacent, and half of what I ship these days involves some LLM doing a job a person used to do. So when a launch like this lands, the question I actually care about isn't "is the model good." It's "what does this make buildable that wasn't buildable last month."

What OpenAI actually shipped

Astra is positioned as state-of-the-art on computer use, browser use, software engineering, cybersecurity, and science — not as a chat model with better answers. OpenAI says it completes an OSWorld 2.0 computer-use evaluation in roughly 40 minutes per task in its own simulations, against about 75 minutes for the prior GPT-5.6 Sol model, while scoring higher overall, and that Codex task completion is roughly 1.9x faster on the Mind2Web benchmark thanks to a combined model-plus-harness upgrade.

A few specifics matter more than the headline claims:

1.05M-token context window, with the harness keeping notes across sessions instead of compacting/summarizing old context away — meaning an agent can go back and check why an earlier fix failed instead of losing that detail.
Tiered rollout: enterprise and "Trusted Access" organizations first, then ChatGPT Plus/Pro/Business/Enterprise, then the API and cloud partners — because the more capable computer-use gets, the more OpenAI is gating it behind access controls rather than shipping it to everyone at once.
It's closed and hosted only. No weights, no self-hosting. You rent the capability; you don't own the execution environment.
Pricing moved with capability — around $10/$50 per million input/output tokens, roughly 2.5x the prior model, on the bet that better reasoning means fewer wasted tool calls and retries, not just a smarter chat window.

That gating detail is the tell. A chat model doesn't need a trusted-access program. A model that can click through your banking dashboard, push code, and chain actions across tools does — and OpenAI apparently agreed with that logic enough to slow the launch over cyber-risk review before shipping it.

What builders are already showing off

The benchmark numbers are one thing; the last few days of demos on X are a better read on what "computer use" actually means in practice right now:

One builder asked Astra to help him understand his own ankle pain and got back a full interactive 3D atlas — bones, ligaments, tendons, with sliders for actual motion axes — from a single prompt, no separate 3D tooling involved.
Developer Ashe went further and had Astra explode a full male anatomy model into 2,234 individually toggleable pieces in one interactive 3D web build, following an earlier viral demo that did the same to a Tesla.
Designer Marvin Schwaibold's read after a few days in: Astra is genuinely good at generating UI, not just wiring up backend logic.
Yatharth Gupta paired Astra with a video-gen tool and turned out launch-ready marketing video content in about five minutes — a workflow that used to mean a separate editing pass entirely.
And builders are still posting fresh interactive demos most days this week, which is the more telling signal than any single one of them: the interesting output right now isn't a benchmark score, it's how fast "describe it, get a working interactive build" turns into a default workflow.

The common thread across all of these: none of them are chat transcripts. They're interfaces, simulations, and finished assets, built by letting the model actually operate software rather than describe what to do next — which is the whole thesis of this piece.

Why it matters more than another "smartest model yet" post

Model capability has been improving on a fairly predictable curve for two years. What's not mature is everything that sits around the model once you let it act instead of just answer:

Who approved this action before it ran
What permissions did the agent actually have when it ran it
What's the audit trail if something breaks
Can you roll it back cleanly if the agent did the wrong thing at 2am

This isn't hypothetical risk-modeling. Security researchers have already documented an OpenAI evaluation agent reaching Hugging Face's production infrastructure through a sandbox that still had open network access and a long-lived shared credential — exactly the kind of gap that "the agent can act on its own" creates once the agent is good enough to actually act. The lesson wasn't "don't use agents." It was that isolation, scoped credentials, and egress allowlists aren't optional add-ons — they're the actual product surface now.

That's the shift worth paying attention to as a builder: the scarce resource stopped being model access and started being trustworthy execution. Anyone can call an API. Fewer people are building the permission layer, the sandbox, the approval gate, and the rollback path around it — and that's exactly where a smaller team can compete against a foundation lab, because it's an infrastructure and product-design problem, not a training-compute problem.

What's actually buildable around this right now

I'd split the opportunity into a few concrete lanes, roughly in order of how fast a solo builder or small team could ship something real:

Approval-gate middleware for a specific tool category.
Not "governance for AI agents" broadly — that's already crowded by platforms like E2B, Modal, and Cosmonic at the infrastructure layer. Pick one narrow, high-stakes action category (agent-initiated payments, agent-initiated deploys, agent-initiated customer-data edits) and build the human-in-the-loop approval step for it. Thin wrapper, opinionated defaults, five-minute setup. That's a sellable SaaS, not a platform play.
Observability for agent runs, not just LLM calls.
Most "AI observability" tools trace prompts and tokens. What teams actually need once agents start touching production is a trace of actions: which files changed, which API calls fired, which were blocked, in what order, tied to which task. If you've built anything with scraping or automation pipelines before, this is a smaller lift than it sounds — it's structured logging with a good UI on top, aimed at a real pain point.
Rollback-as-a-feature for agent-shipped code.
Coding agents will keep shipping subtly wrong changes — that's the consensus among teams running Claude Code, Cursor, Codex, and Devin in production right now, and their fix is CI gates, canary deploys, and one-click rollback, not slowing the agent down. A tool that makes "undo everything this agent touched in the last run" trivial for teams that don't have a mature CI/CD setup yet is a real gap, especially for smaller shops that adopted an agent before they adopted the guardrails.
A vertical computer-use agent for one repetitive workflow.
Astra and its Codex harness are general-purpose. General-purpose tools leave room for a narrow, well-scoped agent that does one job — filling out a specific type of form, reconciling one kind of spreadsheet, running one recurring research task — reliably enough that a non-technical buyer trusts it. That's a positioning move more than a technical one, and it's the same instinct that's worked for narrow SaaS templates and directory products before: don't out-model OpenAI, out-scope them.

The part worth being honest about

None of this works if the underlying agent is unreliable, and computer-use agents still aren't reliable enough to run unsupervised on anything that matters. The teams getting real productivity out of coding and computer-use agents right now are the ones that invested in review discipline, not the ones that just pointed an agent at production and walked away. If you're building the permission/observability/rollback layer, that's your actual pitch to a buyer: not "let the agent do more," but "let your team trust the agent enough to let it do more."

That's also the honest read on why access to Astra's more capable modes is staged and gated rather than switched on for everyone at once — the lab building the model is making the same bet you'd be making as a builder around it: the model getting smarter doesn't remove the need for the scaffolding, it raises the stakes on not having it.

Where to go from here

If you're evaluating which coding agent to actually build with today rather than which one made headlines, it's worth reading through a proper current comparison of AI coding agents before picking a stack — the "best" one depends entirely on whether your team reviews synchronously or lets agents run async. And if the sandboxing/permissions side of this is new territory, I'd start with what's already been written on why AI agents need a sandbox in the first place — it's not a new problem, Astra just raised the stakes on solving it.

If you're building in this space and want more of this kind of breakdown as it happens, the monthly digest rounds up what's shipping across AI tooling, and the SaaS directories are worth a look once you've got something worth listing.

And that's a wrap for today

See you in the next one

Cheers

Shrey

Agency CRM: How to Manage Leads, Clients, Projects and Invoices in One System

shrey vijayvargiya — Sat, 05 Sep 2026 10:27:45 +0000

Agency CRM is software that runs the full agency loop in one place: a new lead becomes a proposal, the proposal becomes a client, the client creates a project, the project creates deliverables, the deliverables create invoices, and the invoice creates revenue.

Most CRM for agencies products still stop at contacts. SaaSCRM treats agency client management software as a business operating system — sales, delivery, and billing on connected records, with an agentic chatbot you can actually ask questions.

A current industry dataset estimates roughly 2.9K monthly searches for “agency CRM.” The search is not for another contact list. It is for a system that matches how studios, boutiques, and digital agencies already work.

Key takeaways

An agency CRM must connect leads → pipeline → clients → projects → tasks → invoices → payments → activity.
Spreadsheets fail after ~10–30 clients because five people edit the same file and follow-ups live in Slack or WhatsApp.
SaaSCRM already ships this shape: Agency CRM template, live demo, and custom builds from $2,000.
Path: free CRM template → SaaSCRM template → custom CRM build.

What is an agency CRM?

An agency CRM is a customer and operations system designed for agencies — not a generic sales database with a new label.

In a generic CRM you store people and move deals. In CRM for agencies, those people become paying clients, those clients own projects, those projects have tasks and deliverables, and those deliverables become invoices and collected payments. That is agency client management software: one record graph, not five subscriptions.

If you are still asking why bother, start with why your business needs a CRM. The agency version of that answer is specific: visibility across sales and delivery.

An agency rarely has only one workflow

A new lead becomes a proposal.

The proposal becomes a client.

The client creates a project.

The project creates deliverables.

The deliverables create invoices.

The invoice creates revenue.

But many agencies manage these stages in completely different tools — a form here, a sheet there, Razorpay or a PDF for billing, WhatsApp for follow-ups, and a project board that never talks to the pipeline.

That is where an agency CRM becomes useful. Indian agencies especially live in WhatsApp threads; the CRM has to be the system of record so a chat does not become the only place a client exists.

What an agency CRM actually needs

A useful agency CRM should connect:

Entity	Question it answers	In SaaSCRM
Leads	Who might become a client?	Leads
Pipeline	Where is each opportunity?	Pipelines
Clients	Who is currently paying us?	Contacts / companies
Projects	What work is being delivered?	Projects
Tasks	Who needs to do what?	Tasks
Invoices	What has been billed?	Invoices
Payments	What has actually been collected?	Payments
Activity	What happened with this client?	Activity

This is more than traditional contact management. It is a business operating system.

Zoho CRM is the default Indian answer for “just get a CRM.” It is strong at sales. Agencies still outgrow it when they need projects + invoices + a UI they can white-label without waiting on a marketplace plugin. That gap is why we ship a dedicated Agency CRM template instead of a generic admin dump — see the one-line map in 6 CRM templates you can demo today.

Why spreadsheets eventually stop working

Spreadsheets are great when you have 10 clients.

Then you have 30.

Five people edit the same document.

Someone creates a second version.

A client is forgotten.

A proposal doesn't get followed up.

A task exists in Slack.

An invoice exists somewhere else.

The agency has more information but less visibility.

We have watched this in client work too — including a finance CRM we built for an Australian accounting team. The pattern is the same: the moment billing and delivery leave the pipeline, the founder starts running the business from memory.

If you are comparing tools as a small studio, the best CRM for small businesses and startups write-up is the buying filter. CRM for agencies just adds projects and retainers to that list.

Building an agency CRM faster with SaaSCRM

SaaSCRM already includes CRM patterns for leads, pipeline, sales, invoices, analytics, activity, and operational management — 60+ screens, theme customizer, and an agentic chatbot.

Instead of designing all of those screens from scratch, an agency can customize the existing foundation around its own workflow.

For example:

Lead → Qualification → Proposal → Won

then:

Client → Project → Tasks → Deliverables → Invoice

The same CRM contains both the sales and operational sides of the agency.

Open the Agency CRM live demo and walk that sidebar. Then plan your modules in two minutes with the AI CRM Builder — the same flow we described in Plan your CRM in 2 minutes.

Niche validation matters before you overbuild. Founders who shop ideas on MicroSaaSHQ keep seeing agency CRM and vertical client-management tools as real demand, not a vanity niche. YourStory and the Indian SaaS press make the same point from the other side: studios want software that matches retainers and delivery, not another Western sales cloud.

AI makes the agency CRM more useful

Imagine asking:

“Which proposals haven't been followed up?”
“Show all clients with unpaid invoices.”
“What projects are overdue?”
“Create follow-up tasks for all leads I haven't contacted this week.”

That changes CRM from a database into a workspace.

SaaSCRM's agentic chatbot is built around this type of CRM interaction — tool-calling against leads, invoices, and tasks, not a FAQ bubble. We use the same pattern internally for research agents; the Reddit trend scraper that saved us $1,000/month sits on the same admin + chat shell.

Template or custom build?

There are two sensible paths.

Use the template when your team wants to build and customize the application itself — Next.js, React, Tailwind, shadcn, Cursor-ready source.

Use the custom CRM service when the workflow requires custom modules, integrations, branding, authentication, billing, or deployment. SaaSCRM currently positions custom builds from $2,000.

That creates a useful path:

Free CRM template → SaaSCRM template → Custom CRM build

You want	Start here
Click the agency workflow today	Agency CRM demo
Own the code	Pricing (template from $49)
Design modules first	AI CRM Builder
We ship it for you	Contact or WhatsApp

Why keep shipping templates at all? Because the boring admin layer is what agencies actually run on — I wrote about that in why I keep building CRM templates.

How to run leads, clients, projects, and invoices in one system

Capture leads in one inbox — forms, referrals, WhatsApp handoff — not a shared sheet.
Move the pipeline (qualification → proposal → won) so nothing sits in “we’ll follow up.”
Convert the won deal into a client record. Do not start a second spreadsheet.
Open a project with tasks, owners, and due dates under that client.
Invoice from the same record when deliverables ship; record payments when they land.
Ask the copilot for unpaid invoices, overdue projects, and quiet leads.

That is agency client management software in practice. You can rehearse every step on saascrm.site before you buy.

FAQ

What is an agency CRM?

A CRM designed around agency sales, client management, and delivery workflows — not only contacts and deals. Read the broader case in why your business needs a CRM.

What should an agency CRM include?

Leads, pipeline, clients, projects, tasks, invoices, payments, activity, and analytics. Demo that set on the Agency CRM template and the six-template gallery.

Can SaaSCRM be customised for an agency?

Yes. SaaSCRM specifically positions itself for agencies and custom CRM builds. Plan the modules with the AI CRM Builder, then customize or hire us.

Can one CRM manage both sales and projects?

Yes, provided the application is designed around connected entities and workflows. SaaSCRM’s agency vertical does that: won pipeline items sit next to projects and invoices.

Agency CRM vs a generic CRM — what is the difference?

A generic CRM is a sales database. An agency CRM is CRM for agencies: pipeline plus delivery, retainers, and billing. If you only need contacts, a generic tool is enough. If you invoice projects, you need agency client management software.

How much does a custom agency CRM cost?

SaaSCRM’s template starts at $49. A tailored custom CRM build starts from $2,000 when you need branding, auth, integrations, or deployment. Book a call or message us on WhatsApp.

Conclusion

An agency CRM is how you stop running the studio in five tabs. SaaSCRM already models CRM for agencies: leads, clients, projects, and invoices on one Next.js foundation — with AI on top.

Next steps

See you in the next one

— Shrey, creator of SaaSCRM.site

AI-Automated Reddit Trend Scraper that saved us $1000/month on Content Creation

shrey vijayvargiya — Sat, 29 Aug 2026 02:49:58 +0000

Hello and welcome to my new blog

In today’s story, we will be discussing an Automated Trend Scraper that helps us save more than 4hours/day and create stunning content, replacing $1000/month on content creation.

Manual trend monitoring is a time sink.

Scouring Reddit, X, and LinkedIn daily to catch target audience discussions wastes hours that could go into building. To solve this for iHateReading, we built an autonomous AI agent to handle the entire pipeline: collecting raw discussions, enriching them with context, and generating tailored content ideas.

Here is how the system works and how we put it together using Hono, OpenRouter, and our proprietary scraper, ScrapeFast.

The 5-Step Pipeline

1. Collect: Scheduled cron jobs fire four times a day, running within a 10-minute execution window. The agent pulls RSS feeds from key subreddits alongside relevant X and LinkedIn posts using our lightweight ScrapeFast engine.
2. Enrich: Raw posts lack context. The agent passes scraped payloads to OpenRouter, extracting underlying pain points, core questions, and sentiment rather than just storing titles.
3. Store: Structured records land in a clean database with key metadata (source, category, extracted problem) mapped for efficient querying.
4. Read: Instead of endless doom-scrolling, a custom interface aggregates the pipeline into a single daily readout that takes under five minutes to review.
5. Act: A dedicated AI chatbot runs on top of the dataset. It answers natural-language queries about emerging trends and directly generates content ideas. For example, it recently identified strong demand for an “AI Tools List” page optimised for SEO.

Proof of Concept

The image added below is proof of the AI agent running in a terminal with one command

It scrapes the latest trending posts from targeted subreddits and AI enrich it further before storing the database

Image 2 shown below renders the 100+ daily fetched subreddit posts of our interests; this helps to provide detailed context about each Reddit post and a relativity score.

Relative score and AI context message become important as they give an overview before reading the full comment/posts; I’ve realised that our Email/Gmail inbox should have this feature 😃

Image 3, as shown below, is where I did some personal improvisation. I quickly integrated an AI chatbot, which can access tools such as search/filter/find from the Reddit posts database.

I’ll explain in a few words

> The AI chatbot, as shown below, has the Directory posts context.

> The AI chatbot can search/find/filter the posts if needed as a tool for the AI agent

In this way, the AI chatbot can give answers based on trending posts. I can give more context to the AI chatbot by giving a timeframe in the prompt, for example, “Give me the last 20 days' trending posts summary”

Tech Stack Breakdown

Hono: Powers the backend API. Its minimal overhead and edge-ready performance ensure fast, lightweight background scheduling without heavy server footprints.
OpenRouter: Serves as the AI layer, enabling flexible model routing to enrich raw text, summarise discussions, and apply conversational intelligence to stored trends.
ScrapeFast: Our custom in-house scraping tool designed for reliable, fast data ingestion across Reddit, social feeds, and web sources.

Trend Scraper for Reddit, LinkedIn and X

We built the same agent for a trend scraper for LinkedIn and another one for X(formerly Twitter)

We can’t run the platform while spending 4 hours a day doing manual research for our website content, so AI is the best choice for the same.

We built a similar agent for LinkedIn and another one for X; both do the same work in the same process for each of the platforms.

In the end, we manually read all the posts and use an AI chatbot to finalise the next plan of content and do better work, solve real problems

Conclusion

We eliminated manual topic research for iHateReading.

Instead of guessing what to write, the agent continuously surfaces real user problems as they emerge. We step in and build the solutions.

PS — We have sold this AI agent to one of our clients; if you need one, DM me at shreyvijayvargiya26@gmail.com

We can build a custom agent for Agencies, startups, and companies. We look forward to your message.

That would be enough for today; see you in the next one
Cheers
Shrey

Cool React Sounds libraries to use on your next project

shrey vijayvargiya — Sun, 16 Aug 2026 11:39:01 +0000

Buildsaas updates, React sound libraries, Explore page on iHateReading and more

Tags: Buildsaas, Frontend Development, iHateReading Website, Posts.design, Movin.design

Hello and welcome to the new blog, folks

I am your author, Shrey

This blog is an interesting one, but it doesn't have any specific topic to write about!!

Buildsaas: My delulu is the only solulu 😀💁🏼

I read this tweet on x.com about boilerplate businesses.

The tweet: https://x.com/JanuBuilds/status/2088232655712108881

Most of us are thinking that AI might eat the boilerplate business in the next 2 years, but in reality, the picture is the inverse.

Boilerplate businesses are earning more than required, and the trend and demand are not going down anyway in the next 2 years. The main reason is the cost and time it usually takes to build entire SAAS products from scratch to production level.

It will cost > $1k for a developer to build a simple gettemplate.app or even a static kind of website because a website is not just a webpage but a combination of multiple things running and integrated in a well-designed system.

A website contains Authentication, Frontend pages, email, State management, and payment services, all running simultaneously for 100+ users on a daily basis, and that is why we have been building and upgrading Buildsaas.dev for the past year. I’ve built 6 apps in the past year using one boilerplate; all the products are LIVE and used by real-world people. Check all buildsaas.dev products on our examples page.

If you are building your next SAAS product or website, or an idea, feel free to try buildsaas.dev.

We provide proper documentation, notes, custom email and WhatsApp support, along with launch support to help you turn your idea into a reality.

New Explore Page on iHateReading

I always want to create something similar to daily.dev for our use case and product. Last year I've collected more than 100+ RSS feed websites that I can use to scrape or fetch the latest interesting blog content and renders them on the iHateReading explore page.

I quickly use the Nextjs server-side API to attach it with a CRON job, meaning run everyday twice, only 2 times per day and brings some solid, interesting internet scraped content.

Give it a try, ihatereading.in/explore

If you're wondering why, Nextjs server-side API?

Well, I don't want to complicate it, we ain't need a solid system design for the URLs or RSS feeds in total.

We have quite a couple of 100s of RSS feed links in total, and Next.js server-side is a server-side API that quickly runs in batches of 50 at a time to scrape the RSS feeds content.

If needed, I use our own scraping API to fetch more details or content from each URL; check it out.

Sounds-Based Interfaces

I've found a few more tweets regarding indie-hackers building SDKs for sounds on a website, click the button to invoke the sound instead of a ripple effect or other animations.

I've found it a very interesting concept; a website, in my opinion, should feel more realistic instead of being boring to use.

I've found a few libraries to add sound to your next React website project. Check them below

If needed, try using the useSound hook for integrating sounds on your website

Directory Listing Website: Aggregator Website

Directory websites are becoming a new trend; everyone in their domain wants to build a directory website showcasing inspirations, landing pages, tools, lists, templates — and what makes it interesting and in-demand is that it’s a money-printing machine.

Yes, a directory website in 2020 was a simple static website, and nobody paid attention to it, but in 2026, AI LLMs refer to directory websites finding tools that are cheap and better alternatives; indie-hackers are printing money from stupid, boring static listing websites — who knows that this is the future.

But I love directory websites; they provide so many solutions on one platform, saving us from too many tabs. If you need to build one, I’ve launched a new template on our website: a full-stack directory listing website template.

Built using Next.js, Tailwind, Shadcn, Supabase and Stripe. It provides frontend pages for your directory website, authentication for users to submit their tools, Payment integration using Stripe for slot booking and more such useful features, making it easy to build your directory website in a week, not months.

ToolDir

ToolDir: Directory full-stack website template — Shadcn, Next.js, Supabase and Stripe.

Get the Template: https://shreyvijayvargiya.gumroad.com/l/nextjs-supabase-directory-boilerplate

Cool lightweight Websites

I am always a fan of looking for inspirational websites, I love finding new cool interfaces, animations and solutions to improve my website development skills.

I believe that building a good interface website is an art; it does need more than coding, and that is why an AI agent won't take our job fully.

A few websites I've stumbled upon recently are as follows

That would be enough for today. Stay tuned, as I am working on bringing a new job section to iHateReading 😊, as it would help most of you reading on our website to grab a job as well.

That's it for today, see you in the next one

Cheers

Shrey

Originally published on iHateReading