Qué hice
Lancé /experimentos: una sección pública donde cada test corre bajo método científico (pregunta, hipótesis, variables, metodología, resultados en vivo, conclusión). El detonante fue un breakdown del "sistema que agendó 12 demos en 5 días" de Gojiberry AI. En vez de creerle o descartarlo a priori, decidí convertirlo en experimento formal con nuestro pipeline real.
La sección vive separada de /laboratorio a propósito: laboratorio es el catálogo de proyectos activos; experimentos es la bitácora científica de tests con resultados medibles y actualizables.
Stack del primer experimento
La regla que me puse: siempre sustituir las herramientas recomendadas por las de nuestro stack, salvo que la herramienta sea justamente la variable que queremos medir. En este caso:
- Input (detección de señales en LinkedIn): Gojiberry nativo. No hay equivalente en el stack y es precisamente lo que queremos validar.
- Outreach (mensajes de LinkedIn): Gojiberry nativo también. Se queda igual — es parte del sistema que evaluamos.
- CRM: CRM propio (
lib/crm.tsen MongoDB). Sin Airtable ni staging intermedio — directo al CRM. - Email marketing: ActiveCampaign (ya en stack).
- Notificaciones: Slack (ya en stack).
La primera versión tenía Make + n8n + Airtable metidos al medio y la corregí: sobreingeniería clásica. Si la herramienta hace el trabajo end-to-end, no hay que partirla en pedazos solo para usar más cosas del stack.
Lo que aprendí armando esto
1. El método científico filtra hacks antes de ejecutarlos.
Escribir la hipótesis medible (“tasa de respuesta ≥20% y ≥5 demos agendadas en 14 días con ≤50 mensajes”) ya te obliga a bajar el hype. Muchos hacks que suenan brillantes no sobreviven a tener que ponerles un número.
2. Aislar variables es el 80% del valor.
Grupo A (cold list) vs. Grupo B (high-intent) con el mismo ICP, el mismo canal, la misma secuencia de mensajes. Si cambias tres cosas y mejora, no aprendiste qué causó la mejora.
3. El stack correcto es el mínimo viable.
Mi primer impulso fue: “Gojiberry detecta señal → n8n webhook → Make enrichment → Airtable staging → aprobación → CRM → ActiveCampaign”. Tres herramientas intermedias que no aportan al experimento. La versión final: Gojiberry → webhook → CRM → ActiveCampaign. Menos puntos de falla, más rápido de ejecutar, más fácil de medir.
4. Build in public obliga a resultados reales.
Publicar el experimento en estado planeando con resultados vacíos es más honesto que esperar 14 días y contar solo la versión bonita. Si el hack falla, el log lo documenta. Si funciona, también.
Cómo funciona técnicamente
Cada experimento es un markdown en content/experimentos/ con frontmatter estructurado:
estado: planeando | corriendo | completado | abortado
pregunta: "..."
hipotesis: "Si X entonces Y"
variable_independiente: "..."
variable_dependiente: "..."
variable_control: "..."
stack: [herramientas]
resultados: [] # se va llenando en vivo con fecha, nota y métricas
conclusion: null # se escribe al cerrar
El parser (lib/experimentos.ts) sigue el mismo patrón que lib/diario.ts y lib/blog.ts. Nada nuevo bajo el sol — solo un nuevo tipo de documento.
Por qué importa
El sitio ya tiene blog (SEO long-form), diario (log operativo) y laboratorio (catálogo de proyectos). Faltaba el espacio para el pensamiento-como-sistema: qué estoy probando, con qué hipótesis, con qué resultados. Esta sección cierra ese hueco.
Siguiente paso: correr el experimento de Gojiberry y actualizar el log cada 3-4 días hasta cerrar al día 14.