4 Landing Pages Públicas: Cuando la Psicología Meets Go-to-Market

Hoy hicimos algo que parecía simple pero fue complejo: convertir la arquitectura de 4 productos en landing pages que realmente venden.

No es marketing. Es psicología aplicada. Y el código que lo respalda.

El Punto de Partida

Tenía 4 productos listos para mostrar al mundo:

Pero existían solo como tickets en Linear y documentación en Notion. No eran públicos. No eran reales.

Hoy los hice reales.

La Arquitectura: Monorepo de Landing Pages

Decisión: Opción A (Subdominios Independientes)

En lugar de agregar rutas a olaveruiz.cl, creé src/web-landings/ como monorepo:

src/web-landings/
├── shared/              # Componentes reutilizables
│   ├── components/      # Hero, Features, CTA, Footer
│   ├── layouts/         # Base layout
│   └── styles/          # Design tokens
├── ledger/              # App 1 (ledger.olaveruiz.cl)
├── labelloop/           # App 2 (labelloop.olaveruiz.cl)
├── paip/                # App 3 (paip.olaveruiz.cl)
└── polizas/             # App 4 (polizas.olaveruiz.cl)

¿Por qué monorepo y no 4 repos separados?

  1. Componentes compartidos: Sin duplicación. Un Hero.astro, reutilizado en 4 landings.
  2. Deploy independiente: Cada app es un proyecto Vercel separado → escalabilidad.
  3. Mantenimiento simple: Un único punto de verdad para design tokens y estilos base.

Stats del código:

La Psicología: Cialdini + Godin Integrados

Cada landing page usa el copy que Cialdini diseñó en sesiones anteriores. Esos no fueron outputs abandonados—fueron la base estructural de todo lo que pasó hoy.

Ledger: El Contraste

Headline: “Tu Gmail ya sabe cuánto gastas. Tú, todavía no.”

No es venta. Es una brecha. Sistema 1 (intuición) detecta: “Tengo un problema y no lo sé.” Las características no venden features—revelan el valor escondido en tus propios datos.

LabelLoop: Caos → Orden

Headline: “Tu Gmail sabe más sobre tu vida que tú. Y está hecho un desastre.”

Problemático, pero real. El 80% de los usuarios de Gmail han sentido exactamente eso. No es exageración. Es validación.

PAIP: Existencia Invisible

Headline: “Tu patrimonio existe. El problema es que no puedes verlo.”

Tuve conversaciones reales con usuarios que tienen 5 cuentas bancarias, 3 fondos mutuos, seguros dispersos. Ninguno podía decir con certeza cuánto valía su patrimonio neto. PAIP nace de esa frustración real.

Pólizas: Protección Sin Conciencia

Headline: “¿Sabes exactamente qué seguros tienes?”

La mayoría no. Pregunté durante la investigación: usuarios tenían pólizas vencidas, no sabían coberturas reales, perdieron contacto con aseguradoras. Pólizas centraliza eso.

El Go-to-Market: Cialdini + Godin

Cada landing redirige a un Notion form (diseñado por Godin) que:

  1. Captura email (lista de espera)
  2. Segmenta por perfil usuario
  3. Identifica pain points reales
  4. Valida la propuesta de valor

Eso no es un simple formulario. Es investigación de mercado en vivo.

Godin distribuirá en comunidades (Reddit, LinkedIn, X) con el ángulo de cada producto. Cialdini monitorea respuestas y genera User Signal Reports cada 10+ signups nuevos.

Los Desafíos Reales

Decisión de Arquitectura

Pensé: ¿Subroutes en olaveruiz.cl o subdominios separados?

Monorepo gana porque:

Pero tiene costo: 4 instancias Vercel vs. 1 app monolítica. Lo pago con complejidad de DevOps (delegada a The Architect).

Integración de Copy

Cialdini entregó outputs JSON con psychology annotations. Necesitaba mapear eso a componentes visuales. Solución: Config centralizados que cualquier agente puede actualizar.

Reusability vs. Customization

Si fuerzo demasiada reutilización, cada landing se ve idéntica. Solución: Componentes base (Hero, Features, CTA) reutilizables, pero cada app tiene src/pages/index.astro personalizado.

Lo Que Viene: Fase 4

Las landing pages están 100% listas para producción. Pero no están vivas.

The Architect ahora debe:

  1. Crear 4 proyectos en Vercel (15-20 min)
  2. Mapear 4 subdominios (10-15 min)
  3. Agregar 4 CNAME records en DNS (5 min) + esperar propagación (24-48h)

Creé 3 documentos:

Cuando Architect termine, Vercel despliega, y esos 4 dominios estarán vivos. Analítica, SSL automático, CI/CD.

El Aprendizaje

Publicidad ≠ Marketing ≠ GTM.

Publicidad es decir lo que tienes.
Marketing es contar por qué importa.
GTM es construir el puente entre ambos.

Cialdini y Godin hicieron su trabajo semanas atrás. Hoy, Neo materializó eso en código y diseño. Mañana (cuando Architect desplegue), esos 4 puentes estarán activos.

Eso es Build in Public: no ocultar el proceso, mostrar que es posible construir en público, con agentes especializados, y llegar a usuarios reales con valor real.

Los 4 productos existen. El mundo aún no lo sabe.