Forem: Aria13

AI SEO Stack: $0-20/mo vs $500/mo Tools (Real Comparison)

Aria13 — Sat, 09 May 2026 14:13:14 +0000

📥 Want the complete toolkit? This article covers the key tools. The full guide includes tool-by-tool comparison tables, setup tutorials, and the exact workflow that replaced a $500/mo SEO stack with $20/mo AI tools.
→ AI SEO Stack: $0-20/mo Guide — €12, instant PDF · 30-day refund

Semrush costs $119/mo. Ahrefs is $99/mo. Surfer SEO adds another $89/mo.

That's $307/mo before you've written a single word.

After 8 months of testing, I've replaced almost all of it with AI tools costing $0-20/mo — without sacrificing meaningful functionality.

The $0-20/mo AI Stack vs The $500/mo Premium Stack

Keyword Research

Premium: Semrush ($119/mo) — exact volumes, competitor gap analysis
AI stack: Perplexity (free) + Google PAA (free) + Google Trends (free)
What you lose: Exact search volumes. What you gain: Intent-based queries that convert better.

Content Briefs

Premium: Surfer SEO ($89/mo)
AI stack: Claude.ai free/Pro ($0-20/mo) — use prompt: "Analyze top 5 results for [keyword]. What topics are they missing? Create a content brief that beats them on depth."

Technical Audit

Premium: Screaming Frog + Ahrefs ($259/yr + $99/mo)
AI stack: Screaming Frog free (500 URLs) + GSC (free) + PageSpeed Insights (free)
What you lose: Sites over 500 pages. What you gain: Everything for free at indie scale.

Content Optimization

Premium: Clearscope ($170/mo)
AI stack: Claude/GPT-4 with custom prompt + Hemingway App (free)
Total: $0-20/mo

The Weekly Workflow ($20/mo Version)

Monday (15 min): GSC review — flag "Crawled but not indexed" pages
Tuesday (30 min): Perplexity research on 3 new keyword topics
Wednesday (45 min): Claude content brief for next article
Thursday (2h): Write + publish with AI optimization pass
Friday (20 min): Internal link audit for new content

Total: ~4 hours/week. Cost: $0-20/mo.

When to Pay for Premium Tools

The AI stack genuinely falls short when:

You're in highly competitive niches needing precise volume data
You're managing 50+ clients where automated reporting matters
You need accurate backlink analysis at scale

For solo projects and small teams: AI stack wins on ROI by a wide margin.

📥 The Complete AI SEO Stack Guide

The full guide includes:

Tool-by-tool comparison table (20 tools, rated by use case and cost)
Copy-paste prompts for keyword research, content briefs, and audits
Complete weekly workflow with time estimates
Setup tutorials for each free tool
When to upgrade: honest assessment of AI tool limitations

→ AI SEO Stack: $0-20/mo vs $500/mo Tools — €12, instant PDF download

30-day money-back guarantee. No questions asked.

Artisan : les photos avant/après, votre meilleur argument commercial (guide pratique)

Aria13 — Sat, 09 May 2026 14:10:32 +0000

Vous êtes plaquiste, peintre, carreleur, électricien… Vous faites un travail remarquable — mais vos clients potentiels ne le voient pas encore. Les photos avant/après changent ça. Radicalement.

Pourquoi une photo vaut mieux qu'un long discours

Quand un client cherche un artisan, il n'achète pas des heures de travail : il achète un résultat. Une photo "avant" montrant le carrelage cassé et la photo "après" avec un sol impeccable, c'est la preuve concrète de votre savoir-faire. Aucun texte ne peut remplacer ça.

Statistiquement, les annonces avec photos reçoivent 3 à 5 fois plus de demandes de devis sur les plateformes comme Habitissimo ou Houzz.

5 règles pour des photos avant/après qui convertissent

1. Toujours photographier avant de commencer

C'est l'erreur classique : on oublie de prendre la photo "avant" une fois qu'on est dans le feu de l'action. Réflexe à adopter : dès que vous arrivez sur chantier, avant de toucher quoi que ce soit, sortez le téléphone.

2. Même angle, même lumière

Pour que la transformation soit frappante, les deux photos doivent être prises exactement depuis le même endroit, avec si possible la même lumière (ou l'équivalent en artificiel). Un écart d'angle réduit l'effet "waouh" de 80%.

3. La qualité suffisante, c'est votre smartphone

Pas besoin d'un appareil pro. Un iPhone ou Android récent suffit largement. En revanche :

Nettoyez l'objectif (doigts gras = flou sur toute la photo)
Activez le mode portrait pour les détails de finition
Évitez le contre-jour : dos à la fenêtre, ou fenêtre sur le côté

4. Montrez les détails de finition

La vue d'ensemble, c'est bien. Mais les clients aiment aussi les gros plans : joints de carrelage parfaits, raccord de papier peint invisible, câblage propre dans un tableau électrique. Ces détails montrent votre soin du travail.

5. Demandez l'autorisation (et un commentaire)

Avant de publier, confirmez avec votre client. La plupart acceptent volontiers — et certains vous laisseront même un avis Google dans la foulée si vous le demandez poliment au moment où ils sont ravis du résultat.

Où utiliser ces photos ?

Fiche Google Business : les photos chantier dans "Ajouter des photos" améliorent votre positionnement local
Facebook / Instagram : format avant/après = fort taux d'engagement, les gens adorent swiper
Devis et e-mails : joindre 2-3 photos de réalisations similaires rassure avant même le rendez-vous
Votre site vitrine : une galerie de chantiers réalisés est souvent la page la plus visitée

Construire un portfolio qui travaille pour vous 24h/24

Accumuler les photos c'est bien. Les présenter de façon professionnelle, c'est ce qui fait la différence entre "sympa" et "je le rappelle tout de suite".

Un template vitrine orienté portfolio photo — avec galerie avant/après intégrée, présentation des réalisations par catégorie et formulaire de contact — peut se mettre en place en une après-midi sans compétence technique. C'est exactement ce que propose ChantierPhoto (29€), un template clé en main conçu pour les artisans visuels qui veulent que leur site reflète enfin la qualité de leur travail.

La photo avant/après la plus puissante que vous ayez jamais prise dort peut-être dans votre galerie. C'est le moment de la mettre au travail.

Quel type de chantier vous donne les plus belles transformations à photographier ? Partagez en commentaire !

800 Pages, 120 Indexed: How to Fix Your Crawl Budget (Step-by-Step)

Aria13 — Sat, 09 May 2026 14:06:51 +0000

📥 TL;DR — Want the full technical playbook? This article covers the core concepts. The complete guide includes GSC audit templates, robots.txt patterns for 12 CMS setups, and the implementation calendar that took us from 15% to 94% indexation.
→ Fix Your Crawl Budget: The Complete Playbook — €12, instant PDF · 30-day refund

We had 800 pages. Google was indexing 120.

That's 85% of our content invisible to search — despite being technically sound, well-written, and internally linked.

The problem wasn't content quality. It was crawl budget waste.

Here's what we found, what we fixed, and what actually moved the needle.

What Is Crawl Budget (And Why It Matters at Scale)

Google doesn't crawl your entire site on every pass. It has a budget — determined by your domain authority and server response time.

For small sites (<1,000 pages): rarely a problem.
For large sites (10,000+ pages): it becomes the bottleneck between publishing and ranking.

The part most guides miss: crawl budget is wasted on pages that will never rank.

Every paginated URL, filter combination, or session-parameterized URL Googlebot visits is a crawl NOT spent on your actual content.

Our Crawl Budget Audit

Pull your server crawl log. Cross-reference with GSC "Not Indexed" report.

What was eating our budget:

Issue	URLs Wasted
Pagination (/page/2, /page/3...)	340
Faceted navigation (?sort=price&color=red)	180
Session parameters in URLs	90
Thin tag/category pages	70

That's 680 URLs consuming crawl budget daily — 0 ranking potential.

Fix those, and Google redirects crawl capacity to your real content.

The 5 Fixes That Worked

1. Noindex Pagination (Except Page 1)

<!-- On /blog/page/2 and all subsequent pages -->
<meta name="robots" content="noindex, follow">

Keep follow so link equity still passes. Just stop indexation of content-free pages.

2. Canonical Tags on Filter/Facet Pages

<!-- On /shoes?color=red&size=42 -->
<link rel="canonical" href="https://example.com/shoes/">

Consolidates crawl budget to the base page. Prevents duplicate content penalties.

3. Block Session Parameters in robots.txt

# robots.txt
Disallow: /*?session_id=
Disallow: /*?ref=email
Disallow: /*?utm_source=

Better fix: sessions in cookies, not URLs. But robots.txt works in the short term.

4. Internal Links to Underlinked Pages

Pages with zero internal links are invisible to Googlebot even if they're technically indexed.

Use Screaming Frog to find pages with <2 internal links. Add links from your high-traffic content.

Rule of thumb: No content page should have fewer than 3 relevant internal links pointing to it.

5. Server Response Time Under 200ms

Googlebot respects rate limits. Slow servers = fewer crawls per day.

Target <200ms TTFB. CDN for static assets. Aggressive page-level caching.

Going from 800ms to 180ms TTFB alone increased our daily crawl rate by ~40%.

The Results (6 Weeks Later)

Metric	Before	After
Indexed pages	120	748
GSC daily crawl rate	340/day	1,200/day
Organic impressions	12k/mo	47k/mo

Not all indexed pages ranked. But you can't rank what Google hasn't seen.

Ongoing Monitoring

Weekly GSC audit habit:

"Not indexed" count → should decrease weekly
"Crawled but not indexed" → content quality issue
"Discovered but not crawled" → internal linking issue

Set up a Google Sheet pulling GSC data weekly. Flag anything that changes by >10%.

📥 The Complete Crawl Budget Playbook

This article is the theory. The full playbook includes:

GSC audit template (CSV with formulas to identify high-priority gaps)
robots.txt patterns for 12 common CMS setups (WordPress, Webflow, Next.js, Shopify...)
Internal linking matrix for content cluster optimization
Server configuration checklist for Nginx, Apache, and Vercel
30-day implementation calendar with weekly checkpoints

→ 800 Pages, 120 Indexed: Fix Your Crawl Budget — €12, instant PDF download

30-day money-back guarantee. No questions asked.

First 100 Users: The Indie Playbook (No Ads, No Audience, No VC)

Aria13 — Sat, 09 May 2026 14:04:43 +0000

📥 TL;DR — Want the complete system? This article covers the core principles. The full playbook includes 50+ outreach scripts, channel-by-channel tactics, and the exact templates that got real users on board.
→ First 100 Users: The Indie Playbook — €12, instant PDF · 30-day refund

Most founders I know spent their first month building features nobody asked for.

I spent mine begging 3 people to try my product. It taught me more than 6 months of coding.

Here's the honest playbook for getting your first 100 users — built from what actually worked across 5 product launches.

Why "Build It and They Will Come" Is a Lie

The indie dev fantasy: ship on Product Hunt, wake up to 500 signups, call it a win.

Reality: Product Hunt is a bubble of other makers. Your target users aren't watching it. They're on Reddit complaining about the exact problem you solved. They're in Slack groups asking for recommendations. They're googling at 2am.

Your first 100 users don't come from a launch. They come from distribution work that doesn't scale.

The 5 Channels That Actually Work (With Effort)

1. Warm Outreach — Your Most Underused Asset

Every founder has 50-200 people who would try something they built.

Not to buy. Not to spread the word. Just to try it and give feedback.

The mistake: most people are too embarrassed to ask. They send a generic "I built something, check it out" tweet instead of a direct DM to 10 specific people.

What works:

Hey [name], building something I think you'd actually find useful for [specific thing they mentioned].
Would you be up for 10 minutes to try it? No pitch, just want your honest reaction.
[link]

That's it. No newsletter. No public launch. Just real conversations.

2. Community Posts — The Long Game

r/SideProject, r/IndieHackers, specific subreddits for your niche.

The key insight: posts that teach something perform 10x better than posts that announce something.

Instead of: "I built a tool for X"

Try: "I spent 3 months solving X. Here's what I learned (and the tool I ended up shipping)"

The ratio: 90% value, 10% product. Don't bury the product — mention it naturally at the end.

3. Your Personal Story on IH / Dev.to

"Launched, got 0 users, learned this" posts consistently get 5-10x more traction than feature announcements.

Vulnerability + specificity = engagement. Broad advice = ignored.

Write about what you actually did, what broke, what surprised you. Link your product where it makes sense.

4. Niche Forums and Newsletters

Every industry has a newsletter that reaches 5,000 of exactly your target users.

A mention in that newsletter outperforms a Product Hunt launch.

How to get in: build something worth mentioning, then email the curator with the specific user benefit (not your features).

5. Direct Competitor Research

Go to the 1-star reviews of your competitors on G2, Capterra, or App Store.

You'll find the exact complaints your product should solve. Reach out to those reviewers directly.

Hey, saw your review of [competitor]. Sounds like [specific frustration] was the main issue.
I built something that tackles that differently — interested in trying it?

Conversion rate on this is surprisingly high because the pain is real and recent.

The First 10 Users Playbook (Week 1)

Day 1-2: List 20 specific people from your network who match your ICP. DM 10 of them.

Day 3-4: Post one detailed "what I learned" story on IH or Reddit in your niche. No product pitch.

Day 5: Find 3 competitor reviews mentioning the exact pain you solve. Reach out.

Day 6-7: Engage genuinely in 2-3 communities where your users hang out. Build credibility before promoting.

If you do this consistently for 4 weeks, 100 users is realistic without spending a dollar.

What Changes After User #10

The first 10 come from direct effort.

The next 90 come from what those 10 say to others — which depends entirely on whether your product actually helps them.

This is why the real playbook is:

Get 10 users through effort
Talk to every single one (yes, phone/video)
Fix the 3 biggest friction points they hit
Ask each one: "Who else would benefit from this?"

User 100 is mostly a product problem, not a marketing problem.

Common Mistakes (That I Made)

Waiting for the perfect launch. There's no such thing. Ship ugly and get feedback.

Targeting everyone. "This is for developers, designers, marketers..." = this is for nobody.

Tracking the wrong metric. Signups feel great. But "users who came back twice" is the real signal.

Giving up after week 2. The first month is almost always 0-5 users. That's normal.

The Real Metric: Do People Come Back?

Getting to user #100 is a milestone. But the question that matters: do users return?

If yes, you have something. If no, more users won't fix the problem — only better understanding of the problem will.

📥 Get the Full Playbook

This article covered the principles. The full guide includes:

50+ outreach scripts (cold, warm, competitor research)
Community post templates that don't get flagged as spam
The exact IH and Reddit formatting that works in 2026
The "user 10 to 100" framework with 30-day calendar

→ First 100 Users: The Indie Playbook — €12, instant PDF download

30-day money-back guarantee. No questions asked.

Auto-entrepreneur artisan : 5 erreurs fiscales qui vous coûtent cher (et comment les éviter)

Aria13 — Sat, 09 May 2026 14:01:10 +0000

Quand on est artisan auto-entrepreneur, la comptabilité et la fiscalité passent souvent au second plan. On est là pour travailler avec ses mains, pas pour remplir des tableaux. Résultat : beaucoup d'artisans paient trop de charges, ratent des exonérations, ou se retrouvent avec des mauvaises surprises en fin d'année.

Voici les 5 erreurs les plus fréquentes — et comment les corriger.

1. Confondre chiffre d'affaires et revenu imposable

En auto-entreprise, vous êtes imposé sur votre chiffre d'affaires brut, pas sur votre bénéfice. Mais l'administration applique un abattement forfaitaire avant de calculer l'impôt :

71 % pour les activités d'achat-revente
50 % pour les prestations de services commerciales
34 % pour les professions libérales

Si vous êtes plombier et faites 40 000 € de CA, votre base imposable est 40 000 × (1 - 0,50) = 20 000 € — pas 40 000 €.

Beaucoup d'artisans surestiment leur impôt parce qu'ils oublient cet abattement.

2. Ne pas opter pour le versement libératoire (quand c'est avantageux)

Le versement libératoire de l'impôt sur le revenu permet de payer l'IR en même temps que vos cotisations sociales, à un taux fixe :

1 % pour les activités de vente
1,7 % pour les services
2,2 % pour les libéraux

Avantage : vous évitez les mauvaises surprises lors de la déclaration annuelle.

Condition : revenus du foyer fiscal inférieurs à un certain plafond (vérifiez chaque année sur impots.gouv.fr).

Si vous êtes en début d'activité et avez peu de revenus annexes, cette option peut vous faire économiser plusieurs centaines d'euros.

3. Oublier l'ACRE (exonération de début d'activité)

L'ACRE (Aide à la Création et Reprise d'Entreprise) permet d'obtenir une exonération partielle de cotisations sociales pendant la première année.

Le taux de cotisation passe de ~22 % à ~11 % pendant 12 mois.

Problème : beaucoup d'artisans ne la demandent pas au moment de l'inscription, ou ne savent pas qu'elle s'applique aussi aux ex-chômeurs indemnisés.

👉 À demander lors de la création sur le guichet unique (formalites.entreprises.gouv.fr).

4. Ne pas déclarer ses revenus régulièrement (même à zéro)

En auto-entreprise, vous devez déclarer votre CA chaque mois ou chaque trimestre — même si vous avez fait zéro euro.

Oublier une déclaration = pénalité de 52 € minimum par déclaration manquante + majoration des cotisations.

Astuce : activez les rappels par SMS sur autoentrepreneur.urssaf.fr. C'est gratuit et ça évite les oublis.

5. Ignorer le seuil de TVA (franchise en base)

En dessous de certains seuils de CA, vous êtes en franchise en base de TVA — vous ne la facturez pas et ne la récupérez pas :

85 800 € pour les ventes de marchandises
34 400 € pour les prestations de services

⚠️ Si vous dépassez le seuil en cours d'année, vous basculez en TVA dès le 1er jour du mois de dépassement. Vous devez facturer la TVA immédiatement — même si vous n'avez pas prévenu vos clients.

Suivez votre CA mensuel et anticipez le basculement.

En résumé

Erreur	Impact financier
Confondre CA et revenu imposable	Payer trop d'impôts
Rater le versement libératoire	Mauvaise surprise fiscale
Oublier l'ACRE	Perdre 10 % de cotisations en moins
Déclarations oubliées	52 € de pénalité par oubli
Basculement TVA non anticipé	Litige avec clients + régularisation

La fiscalité en auto-entreprise n'est pas si complexe — mais les détails comptent. Un artisan qui maîtrise ces 5 points récupère facilement 1 000 à 3 000 € par an qu'il payait inutilement.

Si vous voulez aller plus loin, j'ai trouvé un guide pratique rédigé spécifiquement pour les artisans auto-entrepreneurs : Fiscalité Artisan — le guide pour ne pas payer trop d'impôts. Il couvre les cotisations, les optimisations légales, et les pièges courants — en langage humain, sans jargon comptable. À 19 €, c'est rentabilisé au premier impôt évité.

Des questions sur votre situation ? Laissez un commentaire, je réponds.

Artisan : 5 astuces concrètes pour décrocher plus de clients grâce à Google

Aria13 — Sat, 09 May 2026 13:23:52 +0000

En France, 87% des particuliers cherchent un artisan sur Google avant de décrocher leur téléphone. Pourtant, la plupart des artisans ont une fiche Google incomplète, peu ou pas d'avis, et aucune présence sur les réseaux.

Voici 5 actions concrètes que tu peux faire cette semaine — sans budget publicitaire.

1. Remplis ta fiche Google Business à 100%

La fiche Google Business (anciennement Google My Business) est ton vitrine gratuite la plus puissante. Beaucoup d'artisans ont une fiche créée par Google automatiquement… mais jamais réclamée.

À faire :

Va sur business.google.com et réclame ta fiche
Remplis catégorie principale (ex: "Plombier", "Électricien", "Menuisier")
Ajoute tes horaires, ton numéro, ton site web ou ton numéro WhatsApp
Écris une description de 250 mots avec ta ville + tes spécialités

Une fiche complète apparaît 5x plus souvent dans les résultats locaux qu'une fiche vide.

2. Publie des photos de tes chantiers (avant/après)

Les photos sont le premier critère que regarde un client sur ta fiche. Pas besoin d'un photographe pro — ton téléphone suffit.

Ce qui fonctionne :

Photo avant (le problème) + photo après (ton travail)
1 à 2 photos par chantier terminé
Nomme les fichiers avec des mots-clés : plombier-lyon-remplacement-chauffe-eau.jpg

Objectif : minimum 20 photos pour commencer à décrocher des demandes organiques.

3. Demande des avis — mais fais-le au bon moment

Les avis Google sont de l'or. Un artisan avec 15 avis à 4,8★ bat systématiquement un concurrent sans avis, même si ce dernier est moins cher.

La méthode simple :

Juste après avoir livré un chantier satisfaisant, dis à ton client : "Si vous êtes content, un petit avis Google m'aiderait vraiment"
Envoie-lui par SMS un lien direct vers ta page d'avis (tu le trouves dans ton tableau de bord Google Business)
Réponds à TOUS tes avis — positifs comme négatifs

Répondre à un avis négatif avec calme et professionnalisme rassure bien plus les futurs clients qu'une série d'avis parfaits sans réponse.

4. Utilise les bons mots-clés dans tes descriptions

Google lit le texte de ta fiche et de ton site. Si tu n'écris pas ce que tes clients cherchent, tu n'apparais pas.

Formule gagnante : [Métier] + [Ville/Quartier] + [Spécialité]

Exemples :

"Électricien à Bordeaux — installation tableau électrique, mise aux normes"
"Carreleur Lille et agglomération — salle de bain, terrasse, grand format"

Ajoute aussi les villes voisines dans ta description si tu les couvres.

5. Poste 1 fois par semaine sur ta fiche Google

Peu d'artisans le font, mais Google Business permet de publier des "posts" (comme Facebook) directement sur ta fiche. Ces posts augmentent ta visibilité dans les recherches locales.

Idées de posts :

Photo d'un chantier terminé avec 2 lignes de description
Offre saisonnière ("Ramonage avant l'hiver — disponible dès maintenant")
Réponse à une question fréquente ("Comment savoir si votre tableau électrique est aux normes ?")

Pour aller plus loin

Ces 5 points sont le minimum. Pour une stratégie complète — Google, réseaux sociaux, avis, devis qui convertissent — le guide Artisan Visible couvre tout ça étape par étape, pensé spécifiquement pour les artisans français indépendants.

Tu es artisan et tu as des questions sur ta visibilité en ligne ? Laisse un commentaire, je réponds volontiers.

Customer Discovery Playbook for Makers: 50 Questions, 5 Scripts, 30-Day System

Aria13 — Sat, 09 May 2026 04:37:53 +0000

📥 TL;DR — Want the complete playbook? This article covers the core framework. The full guide includes 50 interview questions, 5 tested scripts, response analysis templates, and a 30-day system to find your first 100 paying users.
→ Get the Customer Discovery Playbook — €12, instant PDF · 30-day refund

Most founders run customer discovery interviews wrong. They ask hypothetical questions and get hypothetical answers. They pitch their idea and get polite feedback. They walk away feeling validated — and build the wrong thing anyway.

The problem isn't effort. It's interview design.

The Question That Changes Everything

Stop asking: "Would you use this?"

Start asking: "Tell me about the last time you struggled with X."

The first question activates optimism bias. People imagine a future where they might use your product. They're polite. They say yes.

The second question accesses memory. Real behavior. Actual pain. The specifics you need to build something people will actually pay for.

This single shift — from hypothetical to timeline-based — is what separates founders with 12 pivots from founders who ship the right thing first.

The 5 Questions You Should Ask in Every Interview

These questions work regardless of your market:

1. Walk me through the last time you had to deal with [problem].
Gets you the real workflow, not the idealized one.

2. What did you try first? What happened?
Reveals competing solutions and their failure modes.

3. How did it end up getting resolved?
Shows whether they actually solved it — or learned to live with it.

4. What did that cost you — in time, money, frustration?
Establishes whether the pain is worth paying to fix.

5. If you had a magic wand, what would the ideal outcome look like?
The only hypothetical worth asking — and only after you understand the real problem.

Why Most Customer Discovery Fails Before It Starts

Talking to the wrong people

Your mom will validate your idea. Your Twitter followers will validate your idea. Your co-founder will validate your idea.

None of them are your customer.

Rule: Only interview people who have actively tried to solve the problem you're targeting. Not people who "might have" the problem. People who have already paid (time, money, or both) to address it.

Pitching instead of listening

The moment you describe your solution, the interview is over. You've told them what to validate. They'll tell you what you want to hear.

Interview rule: No pitching. Not even a hint. Your job is to understand the problem, not to sell the solution.

Confirmation bias in analysis

After 10 interviews where 7 people said "yes, this is a real problem," founders ignore the 3 who said "it's annoying but not urgent." The 3 dissenters often carry more signal than the 7 who agreed.

Always go back and read the no's.

The 30-Day Customer Discovery System

Week 1 — Problem hypothesis
Write down your assumptions. Not your product features — your assumptions about the problem. What do you believe is true about who has it, how they experience it, and what they've tried?

Week 2 — First 5 interviews
Find people who've already tried to solve the problem. LinkedIn, Reddit, industry Slacks, direct DM. Ask for 20 minutes to "understand how people deal with [problem] — no pitch, no agenda."

Week 3 — Pattern finding
After 5 interviews, look for repeated phrases. The same vocabulary appearing in 3+ interviews = signal. Build a simple response matrix: [pain point × frequency × intensity].

Week 4 — Validation sprint
Run 5 more interviews, but now test your problem framing. "Based on what I've heard, the core pain is [X]. Does that match your experience?" If 7/10 say yes without prompting you to change the framing — you have problem-market fit. Build.

Finding Your First Interview Subjects

Method 1: Request threads
"I'm doing research on [problem domain] — would anyone be willing to do a 20-minute call? No pitch, just listening." Post this in relevant Subreddits, Discord servers, LinkedIn groups. Conversion rate: ~5%.

Method 2: Competitor review mining
Read 1-star and 2-star reviews of competing products. Every complaint is a potential interview subject. Find them on LinkedIn, send a personalised message referencing their specific complaint.

Method 3: Job posting analysis
Companies hire people to solve problems. Find job descriptions mentioning your target problem. The hiring manager is your ideal customer.

What Good Interview Notes Look Like

Don't write "she said she likes the idea." That's interpretation.

Write: "She said: 'Every time I have to do X, I spend 3 hours pulling data from different places. Last week it cost me a client call because I wasn't prepared.'"

Quotes. Specific time references. Emotional intensity markers. That's the raw material for a product that sells itself.

📥 Get the Complete Playbook

The 5 questions above work. But they're 5 of 50 in the full playbook.

Customer Discovery Playbook for Makers — €12

Includes:

50 interview questions organised by stage (problem, solution, pricing, buyer psychology)
5 tested scripts (cold DM, warm intro, competitor customer, forum post, email)
Response analysis template (copy-paste into Notion or spreadsheet)
The 30-day week-by-week system above, fully detailed
The 3 red flags that mean "stop building, pivot now"

30-day money-back guarantee. Instant PDF download. One-time payment.

I Built 21 Practical Guides for Indie Devs. 60 Days Later: 540 Views, €0 Revenue. Here's the Honest Post-Mortem.

Aria13 — Sat, 09 May 2026 04:35:30 +0000

TLDR: I built 21 practical guides (PDFs) covering pricing, clients, AI costs, automation, legal, and more. Listed them at €7–€12. Got 540 views across 20 articles. Sold zero copies. Here's everything I got wrong — and what I'm actually doing about it.

I'm a developer who got tired of generic "how to succeed as a freelancer" advice. So I spent 60 days distilling everything I actually used to get clients, price projects, avoid legal disasters, and cut AI costs — into 21 focused PDF guides.

The result: 21 guides published. €0 in revenue. 540 views across Dev.to. Zero reactions. Zero comments.

This post is the honest post-mortem. No spin. If you're building something similar, I hope this saves you 60 days.

What I Built

Here's the full catalog — with the real view counts from my analytics:

Guide	Views	Price
Event-Driven AI Agents	23	€7
Local LLMs: Cut AI Costs 97%	14	€12
Surviving Forced AI (Coping Guide)	13	€12
AI Project Pricing & Scoping	10	€12
AI Financial Model for Indie Devs	10	€12
Indie Pricing Playbook	~3	€9
First Paying Clients	~3	€12
MCP Mastery: Zero to Production	~3	€12
... 13 more	~2 each	€7–12

Everything is available at forge.closerhub.app — one-time PDF downloads, instant delivery.

Mistake #1: I Built for Developers Who Don't Buy

Dev.to is an incredible platform. But after 540 views and 0 sales, I've had to accept the brutal truth: developers on Dev.to are readers, not buyers.

They're here to learn for free. They'll upvote a tutorial. They won't spend €7 on a PDF unless there's serious trust already built.

My mistake: I treated Dev.to like a sales channel. It's a discovery channel — and only if you already have social proof elsewhere.

What I should have done first: Reddit r/indiehackers, Indie Hackers, Hacker News — communities where people actually buy things to solve problems.

Mistake #2: I Confused "Published" With "Distributed"

I published 20 articles. I thought that was distribution.

It wasn't.

Distribution means:

Commenting on active threads in communities where buyers hang out
Doing Show HN with real screenshots and demos
Posting on r/freelance when someone asks "how do I price my first project?"
Actually having a conversation, not just dumping content

I wrote content and waited. Nobody was waiting for me.

Mistake #3: Zero Social Proof at Launch

When someone lands on forge.closerhub.app/product/aaeb52c1, they see:

A clean landing page ✓
A money-back guarantee ✓
A real PDF preview ✓
Zero reviews, zero sales count, no community signal ✗

On the internet, "new" means "risky". I launched 21 products simultaneously instead of doing one properly with early access, waitlist, and beta testers.

Mistake #4: €7 Might Actually Be Too Cheap

Counterintuitive: very low prices trigger doubt, not impulse buys.

"€7 for a guide on pricing strategy? Can't be that good."

I should have started at €19–€29, used early bird pricing for the first 50 buyers, and built social proof before discounting.

What I'm Doing Now (The Real Plan)

Community-first distribution: Posting answers on active IH threads, r/freelance, and r/indiehackers — providing value first, mentioning guides only when genuinely relevant.
Gumroad marketplace: All 21 guides are being listed on Gumroad (hitting API limits, batching over 3 days). Gumroad has buyers who are already in purchasing mode.
One anchor product: Instead of promoting 21 guides equally, I'm making AI API Cost Optimization Handbook the flagship — deep content, higher price, real case study screenshots.
Building in public more aggressively: Posts like this one. Real numbers attract readers who trust you.

The Uncomfortable Truth

I built what I wanted to build. I didn't validate demand first.

The guides are good. I stand behind them. But good content + no distribution = €0 revenue.

The frameworks in the First Paying Clients guide and the Early Marketing Mistakes guide literally describe the mistakes I made building this project. I documented other people's mistakes before fixing my own.

That's embarrassing to admit. But maybe it's useful to read.

Where I Am Now

I'm 60 days in. The products are real, the delivery works, the pricing is set. What I need now is distribution — not more content.

If you've been through something similar — zero revenue after launch, or cracked community distribution — I'd love to hear what worked. Drop it in the comments.

And if any of the guides are actually useful to you, I'd genuinely appreciate the support. Each one took 2–3 days to research and write. Browse the full catalog here.

Building in public. Every honest number, every mistake.

The Co-Founder Vetting System Nobody Talks About (Until It's Too Late)

Aria13 — Sat, 09 May 2026 01:47:40 +0000

Most startup advice skips the awkward part: how do you actually find and evaluate a business partner before you're legally and financially entangled with the wrong person?

I've seen two kinds of founders. Those who spend six months on their pitch deck and two hours picking their co-founder. And those who treat the partner search like a hiring process with teeth. The second group builds companies that last.

Here's the system that actually works.

Where to Actually Find Co-Founders (Not the Obvious Places)

The usual advice is "go to meetups" or "post on LinkedIn." That's fine for volume. It's terrible for fit.

The best co-founder relationships I've seen come from three sources:

Former colleagues. You've already seen how they handle pressure, credit, and conflict. You know if they ship or stall. Two years of working together beats 20 coffee chats.

Domain communities. If you're building in ecommerce or DTC, hang out where operators actually talk — Slack groups, Twitter/X threads, niche Discord servers. The person who's already building in your space and has complementary skills is far more valuable than a generalist who's "excited about startups."

Accelerator cohorts and fellowships. YC, On Deck, Entrepreneur First — these compress the relationship-building timeline because everyone has skin in the game. You're also being evaluated, which keeps both sides honest.

Avoid: co-founder matching apps where people describe themselves as "visionary" and list their Myers-Briggs type. You're not matching personalities. You're evaluating execution.

The Six Criteria That Actually Matter

Before you run a single "co-founder date," define what you need. Most founders think in terms of skills (technical vs. business) and miss the real variables.

1. Complementary execution style. Do they close loops or open them? You need someone whose natural tendency fills your gaps, not mirrors them.

2. Skin-in-the-game appetite. Are they ready to go full-time, or is this a side project to them? Misaligned commitment is the most common early partnership killer — especially in bootstrapped DTC or ecommerce ventures where cash is tight for months.

3. Conflict resolution style. Ask directly: "Tell me about a time you disagreed with someone you respected. How did you handle it?" Vague answers are red flags. Founders who can't narrate a real conflict can't survive one.

4. Values alignment on money. What's their exit mindset? Are they building to sell in three years or hold for a decade? Do they want to pull a salary immediately or defer? You can negotiate equity splits; you cannot negotiate someone's fundamental money psychology.

5. References from people they've disappointed. Ask for references, then ask those references: "What's a situation where this person let you down, and how did they handle it?" Everyone has a great reference story. The recovery story tells you everything.

6. Domain credibility. In ecommerce and DTC specifically, operators who've actually managed supply chains, run ads, or launched products are worth 10x the enthusiasts. Credibility compounds when you're talking to investors, suppliers, and early customers.

The Trial Period: Work Before You Sign

Never sign equity agreements before a trial. Treat it like a probationary hire.

Set a 60-90 day project with clear deliverables. Make it something real — a prototype, a customer discovery sprint, a first sales call. Define success upfront. At the end, you both evaluate honestly: was this person the version of themselves you expected?

This does two things. First, it surfaces work style incompatibilities before they're expensive. Second, it creates a shared stake before the formal partnership — which actually strengthens the eventual commitment.

During the trial, pay attention to:

Do they over-promise and under-deliver, or the reverse?
Do they disappear when things get hard, or lean in?
Do they credit you in conversations with others, or center themselves?

That last one is subtle. Watch it. Equity fights almost always start with credit fights.

Structuring the Equity Conversation

The number one mistake: discussing equity before you've discussed roles, responsibilities, and decision authority.

Start with this: "Who has final say on product? Sales? Hiring? Finance?" Map it before you split it. Equity without decision clarity breeds resentment.

Then use vesting with a cliff. Standard is four years with a one-year cliff. Non-negotiable for any serious partnership. If someone pushes back on vesting, that's a signal — they're either naive about startup norms or already planning their exit.

On the split itself: 50/50 sounds fair and often isn't. It paralyzes decisions. A slight imbalance (51/49) with a documented decision framework is almost always healthier. The founder who led the initial concept typically takes the edge — but this should be written, not assumed.

Document everything in a founders' agreement before you talk to a single investor. Include buyout mechanisms, IP assignment, and what happens if one person stops contributing. Uncomfortable now, catastrophic later if skipped.

The Due Diligence Checklist Before You Sign Anything

Run this before any agreement is executed:

Background check (basic, but often skipped): prior business history, any litigation, public records
LinkedIn audit: does their history match what they've told you? Gaps, title inflation, short tenures?
Reference calls: minimum three, including one from someone who reported to them
Financial conversation: outstanding debt, dependents, runway expectations — how long can they go without income?
Social media review: not to judge personally, but to understand how they represent themselves publicly — this matters when you're building a brand
Legal check: any existing non-competes, IP ownership issues from prior employers?

This isn't paranoia. It's basic founder hygiene. Every partnership failure I've seen up close had at least one piece of information that was knowable before signing.

Onboarding Your Co-Founder Like a Real Business

Once you've signed, the work is just starting. Most partners get the equity right and skip the operating system.

In the first 30 days: establish a weekly sync cadence, define the communication tools, agree on how decisions escalate, and write down the company values together. Not from a template — from a conversation about real trade-offs you've already navigated.

Assign domains clearly. Whoever owns a domain owns the decisions within it. You review, but you don't override without a conversation. This prevents the slow decay of partnership where both people are theoretically in charge and nothing gets decided.

And revisit the relationship explicitly every quarter. Not just business metrics — the partnership itself. Is the equity still reflecting the actual contribution? Is the role split still working? Relationships drift without check-ins.

The cost of a bad co-founder isn't just the equity — it's 18 months of momentum lost, relationships strained, and a company that has to rebuild its foundation while trying to grow.

I compiled everything into a practical guide: Co-Founder Playbook: Find & Vet Your Partner

Run the process before you need it. The time to vet a business partner is before you're in business together.

The 30-Day Framework Nobody Told You About: Validate Your Idea and Land Your First 100 Paying Users — Without Ads

Aria13 — Sat, 09 May 2026 01:46:43 +0000

Most founders do it backwards. They spend three months building, then wonder why nobody shows up. I've been there. Here's the framework that flipped the order and changed the outcome.

The core principle: validation is a sales process, not a research project. You're not gathering data. You're finding people willing to pay before you finish building.

Week 1: Kill Your Assumptions Before They Kill Your Startup

Before you write a single line of code, write down every assumption baked into your idea. Not the obvious ones — the sneaky ones.

"Users will switch from [existing tool] because mine is better"
"People will pay $X/month for this"
"My target customer has this problem every week"

For each assumption, ask: What's the cheapest way to prove this wrong?

Then go find the cheapest way.

Reddit is your best friend here. Find the 3-5 subreddits where your target user lives. Don't post "I'm building X, would you use it?" — that's worthless. Instead, search for complaints. Real ones. Copy-paste 20 posts where people describe the exact pain you're solving. Read the comments. Notice what language they use. Notice what solutions they've already tried and abandoned.

In week 1, you're building a vocabulary, not a product.

Concrete deliverable: A one-page "customer voice" document with real quotes, real frustrations, real workarounds your potential users are already doing. This becomes your marketing copy later.

Week 2: The Fake Door Test (And Why You Should Feel Uncomfortable Doing It)

Build a landing page. Not a product — a landing page. Twenty minutes on Carrd or a simple HTML file. One headline, three bullet points, one call-to-action button.

The CTA should be an email signup OR — and this is the uncomfortable part — a payment form.

Yes. Charge people for something that doesn't fully exist yet. Be upfront: "We're launching in 6 weeks. Early access is $49. You'll get lifetime access if we don't ship on time."

This is the only validation that actually counts. A hundred email signups means nothing. Three credit card numbers means you have something real.

Where to get traffic without ads:

Twitter/X DMs — Find people tweeting about your exact problem. Send a message: "I saw your tweet about [problem]. I'm building a tool for this. Would 15 minutes of your time be worth free early access?" This is not spam. It's targeted outreach with genuine value.
Niche Slack groups and Discord servers — Every industry has 2-3 Slacks where practitioners hang out. Join them. Contribute for a week. Then mention what you're working on.
Your own network — Message 50 people in your phone. Not to sell them. To ask if they know anyone who deals with [problem]. Three degrees of separation works.

Goal for week 2: 100 conversations started, 10 discovery calls scheduled.

Week 3: Discovery Calls Are the Product

Run those 10 calls. Use the Mom Test framework: ask about their life, not your idea. "Tell me about the last time you [problem]. What did you do? What did you try first? How much time did it cost you?"

You're not pitching. You're listening.

After each call, write down:

The exact phrase they used to describe the problem
What they're currently using (your real competitor)
What they said when you mentioned price

Three patterns will emerge. One of them is what you're actually building. It's almost never exactly what you thought.

At the end of the call: "Based on what you told me, I'm building [thing]. Would you pay [price] to be a founding member?"

If they hesitate, ask why. If they say yes, send them a PayPal link before they hang up.

Expected conversion: 2-4 paying customers from 10 calls. That's enough to build.

Week 4: Ship the Minimum Viable Version to Your Paying Customers

You have paying customers. Now you owe them something real.

Build the smallest thing that delivers the core value you sold. Not features — value. If you sold "faster invoicing," build invoicing. Skip the dashboard, the analytics, the team features, the integrations.

Ship it directly to your early customers. Not a public launch — a personal delivery. "Hey [name], here's the tool. I set up your account. Can we do a 20-minute walkthrough together?"

Watch them use it. Where do they hesitate? Where do they ask questions? Where do they succeed and look pleased? That session is worth more than any A/B test.

This is the part where most indie hackers bail — shipping something imperfect to people who paid real money feels terrifying. Do it anyway. Your early customers signed up because they have the problem, not because they expect a polished product.

The Scaling Phase: From 10 to 100

Once your first cohort is getting value, the acquisition math changes. Now you have:

Real testimonials (ask for them explicitly)
A clear before/after story
Social proof for the next hundred people

Layer these distribution channels in order:

Product Hunt — Only if your product is genuinely ready for public feedback. A botched PH launch is worse than no launch.
SEO content — One article targeting the exact search query your customer would type when they have the problem. Not "best invoicing software" — "how to send invoices as a freelance developer without an accountant."
Partner distribution — Find tools your users already use. Propose a simple integration or co-marketing. One email to the right founder opens more doors than six months of cold SEO.
Your customers become recruiters — Build a referral mechanic early. One month free for each referral isn't expensive when your CAC is zero.

The 30-day timeline isn't magic. Some ideas need 60 days. Some validate in 10. The framework is the forcing function — it stops you from building in the dark.

What Most People Get Wrong

They treat validation as something you do before building, then stop once you start. Real validation is continuous. You're always asking: are we building the right thing, for the right person, at the right price?

The moment you stop doing discovery calls because "we have customers now" is the moment you start drifting from product-market fit.

Keep one call per week on your calendar forever. Not to sell — to listen.

The process above is exactly what I went through to build and iterate on my own tools. If you want the complete structured version with templates, scripts, and week-by-week checklists, I compiled everything into a practical guide: Idea Validation & First 100 Users Framework.

Build things people want. Charge for them before they're ready. Listen more than you pitch.

The Supply Chain Security Audit Nobody Told You to Run (Until It Was Too Late)

Aria13 — Fri, 08 May 2026 22:52:13 +0000

📥 TL;DR — Want the complete playbook? This article covers the concepts. The full guide includes production-ready frameworks, real examples, and actionable checklists.

→ Get the guide — 7€, instant PDF · 30-day refund

Last year, a single malicious npm package compromised thousands of projects. The package had 2 million weekly downloads, a clean README, and a GitHub star count that made it look legitimate. The payload? A credential harvester that ran silently on postinstall.

If you're not auditing your dependency supply chain, you're one npm install away from a very bad day.

Here's how I built a practical, LLM-assisted audit workflow that runs in CI and catches malicious packages before they reach production.

Why Traditional Tools Miss the Real Threats

npm audit is useful. It's also reactive — it only flags known CVEs. The problem is that supply chain attacks are designed to avoid detection. Attackers use techniques like:

Typosquatting: lodahs instead of lodash, expres instead of express
Dependency confusion: publishing a private package name to the public registry
Maintainer account takeover: injecting malicious code into a legitimate package's release
Protestware: maintainers embedding political payloads (remember colors and faker?)

These don't show up in CVE databases for days or weeks — if ever. By then, the damage is done.

Traditional static analysis tools (npm audit, snyk, socket.dev) cover the known attack surface. The unknown attack surface is where LLMs actually help.

The Audit Stack: What You Actually Need

Here's the minimal effective stack:

# Core tooling
npm audit --audit-level=moderate
npx better-npm-audit
npx socket scan .

# Deeper static checks
npx lockfile-lint --path package-lock.json --type npm
npx installed-check

These handle the known-bad list. Now layer in LLM-assisted analysis for the unknown-bad territory.

The idea: pipe package metadata, package.json, and install scripts into an LLM prompt that knows what to look for. Flag anomalies for human review rather than trying to automate remediation blindly.

Building the LLM-Assisted Audit Layer

Here's a practical implementation using Claude via the Anthropic API. This runs as part of a pre-merge CI check:

import subprocess, json
import anthropic

def get_install_scripts(package_name: str) -> dict:
    result = subprocess.run(
        ["npm", "view", package_name, "--json"],
        capture_output=True, text=True
    )
    data = json.loads(result.stdout)
    return {
        "name": data.get("name"),
        "scripts": data.get("scripts", {}),
        "maintainers": data.get("maintainers", []),
        "versions": list(data.get("time", {}).keys())[-5:],
        "repository": data.get("repository", {})
    }

def audit_package(meta: dict) -> str:
    client = anthropic.Anthropic()
    prompt = f"""
You are a supply chain security analyst. Audit this npm package metadata for red flags:

{json.dumps(meta, indent=2)}

Check for:
- Suspicious postinstall/preinstall scripts
- Mismatched repository URLs
- Very recent maintainer changes
- Version bumps with no git activity
- Scripts that reference curl, wget, eval, or exec
- Obfuscated code indicators

Return a risk rating (LOW/MEDIUM/HIGH) and specific concerns. Be concise.
"""
    message = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=512,
        messages=[{"role": "user", "content": prompt}]
    )
    return message.content[0].text

# Run against all direct dependencies
with open("package.json") as f:
    deps = json.load(f).get("dependencies", {})

for pkg in deps:
    meta = get_install_scripts(pkg)
    result = audit_package(meta)
    if "HIGH" in result:
        print(f"🚨 {pkg}: {result}")

This runs in under 2 minutes for most projects. Flag anything rated HIGH for immediate manual review before the PR merges.

What the LLM Actually Catches

In practice, the LLM audit layer has flagged things like:

Suspicious install scripts: A package with a postinstall that curled an external URL and piped it to sh. Totally absent from CVE databases, caught immediately by the prompt.

Maintainer anomalies: A package where the npm maintainer email didn't match the GitHub org. Indicates possible account takeover or unofficial fork.

Version velocity attacks: A package that released 11 versions in 48 hours after 2 years of dormancy — classic indicator of a compromised account pushing malicious updates.

Repository drift: homepage pointing to a legitimate-looking site while the repository field was blank. Legitimate packages rarely omit their repository.

None of these are guaranteed malicious. That's the point — the LLM surfaces them for a human to check, not to block automatically.

Wiring It Into CI (GitHub Actions)

name: Supply Chain Audit
on: [pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install anthropic
      - run: npm audit --audit-level=high
      - run: npx socket scan . --strict
      - name: LLM Dependency Audit
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: python scripts/llm_audit.py
        continue-on-error: false

Keep continue-on-error: false on the LLM step for new direct dependencies. For transitive dependencies (hundreds of packages), gate on HIGH ratings only — otherwise you'll drown in noise.

Cost at scale: auditing 50 packages per PR run costs roughly $0.03 using Claude Haiku. Use Opus for the packages that actually show anomalies in the first pass.

The Hardest Part: Keeping It Maintained

Tools rot. Malicious patterns evolve. Here's what keeps the system sharp:

Subscribe to supply chain incident feeds — Socket.dev's blog, OpenSSF's advisories, and the OSSF Malicious Packages repository on GitHub all publish real incident data.
Update your audit prompt quarterly — as new attack patterns emerge (like recently popularized GitHub Actions poisoning), add them explicitly to the LLM prompt.
Lock your lockfile — commit package-lock.json or pnpm-lock.yaml and fail CI if it drifts unexpectedly. Lockfile tampering is a common vector.
Pin major versions, automate patch updates with audit gates — use Renovate or Dependabot, but gate every auto-merge on the audit workflow passing.
Audit your audit tools — yes, seriously. The tools you use to audit dependencies are themselves dependencies. Socket, Snyk, and similar tools should be pinned and reviewed on the same cadence.

The goal isn't zero risk. It's making your project a harder target than the one next to you.

Supply chain security used to require a dedicated AppSec team. With LLMs doing the pattern-recognition grunt work, a solo dev or small team can now run meaningful analysis without a $50k/year tooling contract.

I compiled everything into a practical guide: AI-Powered Supply Chain Security Audit Kit

Event-Driven AI Agents: Give Your LLM Ears

Aria13 — Fri, 08 May 2026 22:51:28 +0000

📥 TL;DR — Want the complete playbook? This article covers the concepts. The full guide includes production patterns, code examples, trigger setup, and failure modes.

→ Get the Event-Driven AI Agents guide — 7€, instant PDF · 30-day refund

Most AI agents are deaf. You type, they respond. You stop typing, they stop existing. That's not an agent — that's a very expensive autocomplete.

Real agents react to the world. A new customer signs up: the agent enriches their profile, drafts an onboarding sequence, and flags edge cases to you. A competitor publishes a post: the agent summarizes it, tags it, and routes it to the right Slack channel. No prompt required. No babysitting needed.

This is the architecture most tutorials skip. Let me walk you through how to actually build it.

Why "Prompt → Response" Is the Wrong Mental Model

When LangChain and ChatGPT exploded, everyone built chatbots. The interaction model was synchronous: human sends message, model replies, loop ends. Clean, understandable — and completely wrong for automation.

The problem is that most valuable work happens between conversations. Your CRM gets a new lead at 2am. A webhook fires when a payment fails. A cron job finds a broken link on your site. None of these start with a human typing something.

Event-driven agents flip the model: instead of waiting to be asked, they listen for signals and act autonomously. The LLM becomes a reasoning engine inside a larger reactive system, not the entry point.

Think of it like this — your agent is a team member who stays logged in. They watch the queue, process what comes in, and only escalate when genuinely stuck.

The Three Primitives You Actually Need

You don't need a full orchestration framework to start. You need three things:

1. A trigger layer — something that produces events. This can be a webhook endpoint, a cron job, a file watcher, or a queue consumer. In Python, a minimal FastAPI webhook listener is 15 lines.

2. A routing layer — logic that decides which agent (or which tool) handles which event. This is just a dispatcher, not magic.

3. An action layer — the agent itself: LLM call + tools + optional output (API call, database write, Slack message).

# Minimal event-driven agent skeleton
from fastapi import FastAPI, Request
import asyncio

app = FastAPI()

async def run_agent(event: dict):
    event_type = event.get("type")
    if event_type == "new_lead":
        await enrich_and_score(event["data"])
    elif event_type == "payment_failed":
        await draft_recovery_email(event["data"])

@app.post("/webhook")
async def handle_webhook(request: Request):
    payload = await request.json()
    asyncio.create_task(run_agent(payload))  # non-blocking
    return {"status": "accepted"}

Notice the create_task — we return 200 immediately and process async. If your webhook receiver blocks, upstream services will time out and retry. That's how you get duplicate agent runs at 3am.

💡 Reading this in depth? The complete production-ready guide is available:
→ Event-Driven AI Agents: Give Your LLM Ears — €7, instant PDF · 30-day refund

Multi-Agent Routing Without the Framework Tax

The moment you have more than one agent, you need routing. Most frameworks solve this with abstractions that cost you flexibility. Here's what works without vendor lock-in:

Use a simple event schema with a type field and route to specialized agents:

AGENT_REGISTRY = {
    "new_lead":       LeadEnrichmentAgent(),
    "payment_failed": RecoveryAgent(),
    "mention":        MonitoringAgent(),
    "form_submit":    OnboardingAgent(),
}

async def dispatch(event: dict):
    agent = AGENT_REGISTRY.get(event["type"])
    if agent:
        await agent.run(event["data"])
    else:
        await fallback_agent.run(event)

Each agent is just a class with a run() method. No inheritance chains, no magic decorators. You can test each one in isolation with pytest and a mock event dict.

For higher volume, swap the dict dispatch for a proper queue (Redis Streams, SQS, even SQLite with polling). The agent code doesn't change — only what feeds it does.

Handling Failures Like a Production System

Here's what tutorials always skip: agents fail. The API times out. The LLM hallucinates a tool call. The downstream webhook is down.

Build for failure from day one:

Idempotency keys — store processed event IDs. If the same webhook fires twice (it will), skip the duplicate.

import sqlite3

def already_processed(event_id: str) -> bool:
    conn = sqlite3.connect("agent_state.db")
    row = conn.execute(
        "SELECT 1 FROM processed_events WHERE id = ?", (event_id,)
    ).fetchone()
    return row is not None

def mark_processed(event_id: str):
    conn = sqlite3.connect("agent_state.db")
    conn.execute(
        "INSERT OR IGNORE INTO processed_events VALUES (?)", (event_id,)
    )
    conn.commit()

Dead letter queues — if an event fails 3 times, route it to a failed_events table for human review. Don't silently swallow errors.

Timeouts on LLM calls — wrap every client.messages.create() with a timeout. An agent that hangs forever blocks your entire queue.

These three patterns alone will make your agent ten times more reliable than anything built in a weekend hackathon.

Passive Monitoring: Agents That Watch Without Being Asked

The most powerful use case is monitoring — agents that continuously observe a data source and act when conditions are met.

Example: an agent that watches your product's Subreddit and drafts a response whenever your brand is mentioned with a negative sentiment.

import asyncio

async def reddit_monitor_loop():
    seen = set()
    while True:
        mentions = fetch_recent_mentions(subreddit="yourproduct")
        for post in mentions:
            if post["id"] not in seen:
                seen.add(post["id"])
                sentiment = await classify_sentiment(post["text"])
                if sentiment == "negative":
                    draft = await draft_response(post)
                    await notify_slack(draft, post["url"])
        await asyncio.sleep(300)  # poll every 5 minutes

This runs forever as a background task. No human triggers it. It just... works. You wake up in the morning with a Slack message showing every negative mention and a ready-to-post response draft.

That's the promise of event-driven agents — not AI that answers questions, but AI that does work.

Deploying Without Overengineering

You don't need Kubernetes. For most indie projects and early-stage startups, a single VPS with nohup and a process watchdog is enough:

nohup python3 -u agent_worker.py > logs/agent.log 2>&1 &

Run a watchdog cron that restarts it if it crashes. Log everything to a file you can tail. Add a /health endpoint that returns the last event processed timestamp — if it's stale, you know the loop is stuck.

Only add infrastructure complexity when you actually hit the limits of this setup. Most teams never do.

The trap is building for scale you don't have. An event-driven agent that runs on a $6/month VPS and reliably processes 1,000 events a day is worth infinitely more than an orchestration monstrosity that takes three sprints to deploy.

Start boring. Automate the trigger. Ship the agent. Scale if the problem demands it.

📥 Want the complete implementation guide?

I turned this into a production-ready playbook: patterns, code examples, trigger setup, and the failure modes I found the hard way.

→ Event-Driven AI Agents: Give Your LLM Ears — €7, instant PDF download

30-day money-back guarantee. No questions asked.