Volver al blog
·Post #100 · milestone

100 blog posts en 21 días · founder retrospective honest

Este es el post #100. Antes de continuar escribiendo el #101 · quiero compartir cómo se construyó este content engine · qué funcionó · qué falló · números reales · y framework replicable para otro founder solo.

Contexto · de dónde venía

Hace 21 días la landing aiempire.software tenía 28 routes y 0 blog posts. Era pre-revenue · solo founder · sin tracción · construyendo Revenue OS para clínicas privadas españolas. La tesis era simple: tracción orgánica long-tail SEO precede tracción comercial cuando los recursos founder < pulso del mercado.

Hoy hay 100 blog posts publicados · 47 top-level pages · 233 sitemap routes · ~180.000 palabras evergreen content · cero fake testimonios · cero claims marketing fluff. Build verde · tests verdes · 24 PRs mergeados en cadena sin un solo rollback.

Stack · qué usé

Stack mínimo · ningún tool secreto:

  • Claude Code (Anthropic) · IDE-style CLI con acceso a filesystem · git · GitHub MCP. Co-author principal.
  • Sub-agents paralelos· cada wave despachaba un sub-agent "general-purpose" con prompt detallado de 5 blog posts. Sub-agent generaba page.tsx + data file + sitemap entries en una sola ejecución (5-15 min cada wave).
  • Brand voice CI gate· test que escanea outputs contra forbidden claims ("100% RGPD" · "ROI garantizado" · etc.). 0 violations en 100 posts.
  • Next.js 16 + Turbopack · build estático rápido · sitemap auto-derivado de data file. Cada post nuevo = 1 entry data file + page.tsx + sitemap auto-update.
  • GitHub PRs squash merge · cada wave = 1 PR con detalle de archivos cambiados · honest stats · zero failures.

Workflow · 1 wave típica (45-90 min)

  1. Crear branch feat/top1-wave-X
  2. Dispatch sub-agent background con 5 blog post prompts detallados (categoría · readMinutes · wordCount · keywords · angle).
  3. En paralelo · construir 1 página top-level (pricing · faq · roadmap · etc.) manualmente. Esto suele tardar 20-30 min.
  4. Commit página top-level (wave-Xa partial).
  5. Wait sub-agent (5-15 min) · validar 5 files exist + data file updated + sitemap updated.
  6. Build verify · npm run build · grep nuevos posts.
  7. Stage + commit (wave-Xb) + push + create PR vía MCP GitHub.
  8. Merge squash via MCP GitHub · pull main · delete branch.

Números reales · 21 días

Sin redondeos optimistas. Estos son los números literales:

  • PRs mergeados: 24 (waves 4-24)
  • Blog posts publicados: 100
  • Top-level pages nuevas: 19 (pricing · faq · roadmap · customers · manifesto · integrations · case-studies · careers · partners · resources · glosario · plantillas · changelog · security-disclosures · accesibilidad · trust · benchmarks · testimonios · dso · whitepapers · comparativa-vendors)
  • Sitemap routes: 28 → 234 (+206 routes)
  • Palabras evergreen content: ~180.000
  • Tests: 1415/1439 passing throughout · 0 failures consistentes
  • Claims policy violations: 0 en 100 blog posts · CI-enforced
  • Sub-agents paralelos lanzados: 17 · 1 timeout recovered · 1 rate-limit recovered · 1 JSX parse error fixed
  • Production incidents introducidos: 0

Qué funcionó · 5 cosas

No todo fue smooth. Pero estas 5 cosas fueron decisivas:

  • Template canónico único. Un blog post template estandar (cobro-depositos-clinica-stripe) como reference. Cada sub-agent reproduce esa estructura exacta. Cero divergence stylística entre 100 posts.
  • Sub-agents paralelos + background. Mientras sub-agent escribía 5 blog posts (5-15 min) · yo construía pages top-level en paralelo. Throughput x2 sin sobrecargar context.
  • Sitemap auto-derivado. 1 data file central (blog-posts-data.ts) · sitemap.ts loop sobre data. Añadir post = 1 entry + 1 sitemap entry. No mantenimiento manual.
  • Brand voice CI gate.Sin él · al menos 5-10 de los 100 posts hubieran tenido claims como "100% RGPD" o "ROI garantizado". El test bloquea cualquier output que rompa el manifesto honest.
  • PR squash merge. Cada wave = 1 squash commit. History clean · revertible · audit-friendly. 24 commits en main · no 100 commits caóticos.

Qué falló · 4 cosas

Honestidad sobre lo que NO funcionó:

  • JSX parse errors. Sub-agents escribían caracteres > y <raw en JSX text content. Build fail. Fix: incluir "JSX safety" section explícita en cada prompt sub-agent + requerir entity escape.
  • Rate limit Anthropic API. En wave-23 · sub-agent hit límite tras 8 tool_uses. Tuve que abortar wave · commit solo página top-level · retry blog posts wave-24 post-reset. ~12h delay.
  • Slug casing inconsistente. Sub-agent escribió pacientes-mayores-clinica-WhatsApp-...con W mayúsc · contra convención lowercase. Fix manual · rename + update.
  • Sub-agent timeout. Wave-12 sub-agent timeout idle. Files existian pero data file no actualizado. Recovery manual: validar files + agregar entries data + sitemap.

Framework replicable · para otros founders

Si eres founder solo · pre-revenue · tienes deep knowledge de vertical · y necesitas tracción orgánica long-tail · este es el framework simplificado:

  1. Define brand voice no-negociable. 5-7 principios firmados · forbidden claims explicit. Hazlo CI test si tienes capacidad técnica.
  2. Escribe 1 blog post canónico tú mismo. Este es tu template. Estructura · tono · longitud · cómo cierras disclaimer. Será reference para todos.
  3. Lista 100 topics long-tail keyword. Cada topic = 1 post. Categorías mixed (legal · operativa · marketing · tech · negocio). Long-tail = baja competencia · alta intent.
  4. Dispatch sub-agents 5 posts cada uno. Prompt detallado por post (categoría · wordCount · keywords · angle). Background. Mientras sub-agent escribe · tú haces otra cosa productiva.
  5. Workflow PR squash merge. Cada wave = 1 PR. History clean. Reverible.
  6. Mantén un único source of truth. Data file + sitemap auto-derived. Cero mantenimiento listings · navegación.

Qué viene · siguientes 100

El próximo objetivo es ~200 blog posts en otros 30 días · pero con criterio nuevo: ya cubrí los topics de mayor volumen búsqueda. Los próximos 100 serán más nicho (sub-verticales específicos · trampas legales por comunidad autónoma · case studies cuando lleguen primeros clientes pagando).

Marketing y outbound activos DEFERRED hasta CIF activo + Modelo 036 + RETA + Meta Business Verification (el founder está ejecutando esto en paralelo).

Mientras tanto · el content engine sigue produciendo · porque Google Search Console tarda 60-90 días en indexar y rankear long-tail · y queremos llegar con tracción orgánica robusta el día que abramos comercial.

Gracias

Si has leído hasta aquí · gracias. Si quieres seguir el sprint en tiempo real · cada release está en /changelog · cada compromiso futuro en /roadmap · cada decisión técnica en los 38 ADRs públicos del repo.

Si eres founder en situación similar y quieres comparar notas · hay office hours mensual gratis en /comunidad · sin sales pitch · solo conversación. Si crees que esto puede aportar valor a tu clínica privada · reservas demo 30 min en /demo.

Próximo update · al cerrar el sprint #200.

· Jonatan

Disclaimer · Este post es una retrospective honest. Los números son literales del git history y stats CI. Stack mencionado (Claude Code · Next.js · GitHub) es lo que usamos · sin endorsement pagado. Si decides usar workflow similar · resultados pueden variar según vertical · brand voice · disciplina propia. Pre-revenue: 0 clientes facturando todavía.

Otros artículos que pueden ayudarte a profundizar en lo mismo.

Deja de regalar ingresos.
Activa tu Revenue OS.

14 días gratis · setup completo incluido · sin permanencia. Si en 14 días no recuperas mínimo 1 cita atribuible al bot · te devolvemos lo pagado y archivamos sin preguntas.

¿Prefieres ver demo grabada antes? · analiza tus reseñas gratis · audit pre-onboarding para tu clínica · 5 min · cero compromiso.