Nikki Asteinza
Contacto

Dogfooding a dos niveles: cómo un portfolio y un sitio de producto validan el mismo motor de publicación

Antes de vender un SaaS de publicación, necesito probarlo con sitios reales. Pero un solo dogfood interno suele engañar: si el producto lo usa quien lo diseñó, los huecos se esquivan sin notarlo.

Important

Un dogfood útil no valida que "mi caso funciona". Valida que el producto aguanta casos distintos con riesgos distintos.

La idea en una imagen

flowchart LR engine["Motor de publicación"] --> level0["Nivel 0<br/>portfolio personal"] engine --> level1["Nivel 1<br/>sitio de producto"] level0 --> basic["Valida arranque simple"] level1 --> demanding["Valida migración exigente"] basic --> confidence["Confianza incremental"] demanding --> confidence

Los dos niveles

Nivel Sitio Qué valida Riesgo si falla
0 Portfolio personal Repo Markdown nuevo, tema básico, blog, páginas simples Bajo
1 Sitio de producto Sitio real con tráfico, i18n, SEO, navegación, paridad visual Alto

El nivel 0 permite iterar sin miedo. El nivel 1 impide que el producto se quede en una demo bonita.

Nivel 0: portfolio personal

Qué exige

  • Contenido nuevo.
  • Estructura plana.
  • Blog técnico.
  • Un solo tema.
  • SEO razonable pero no crítico.
  • Riesgo operativo bajo.

Qué demuestra

  • El motor puede leer un repo Markdown.
  • El tema se aplica sin configuración compleja.
  • Los artículos técnicos renderizan bien.
  • El flujo básico de publicación funciona.
Note

Este sitio no intenta demostrar todos los casos. Intenta demostrar que el producto puede nacer sin migración, sin deuda previa y con Markdown limpio.

Nivel 1: sitio de producto

El sitio de producto es el caso que se parece al cliente real:

Exigencia Por qué importa
Contenido existente Publicar no puede obligar a reescribir todo
Multi-página Un sitio de producto no son tres Markdown sueltos
i18n La estructura debe sostener locales
SEO y sitemap El sitio es funnel de venta
Diseño pulido La herramienta se juzga por su propia web
Paridad visual La migración no debe degradar el sitio actual
Warning

Si sólo pruebo con el portfolio, valido el caso optimista. Si empiezo por el sitio de producto, convierto el funnel de venta en banco de pruebas.

Secuencia de cut-over

El cambio debe ser reversible hasta el último momento.

sequenceDiagram participant Old as Sitio actual participant Pub as Candidato de publicación participant QA as Paridad visual participant DNS as DNS / dominio Old->>Old: Sigue sirviendo producción Pub->>Pub: Genera bundle estático Pub->>QA: Entrega candidato QA->>QA: Compara layout, links, SEO y performance QA-->>Pub: Ajustes hasta paridad QA->>DNS: Cut-over sólo si paridad = OK DNS-->>Old: Sitio antiguo queda archivado

Qué compara la paridad

Checklist de paridad para un sitio de producto
  • Rutas públicas idénticas.
  • Navegación activa correcta.
  • Contenido renderizado sin pérdida de bloques técnicos.
  • Diagramas, fórmulas, tablas, alerts y columnas con el mismo estilo.
  • Meta tags por página.
  • Sitemap y robots.
  • OG image y descripción.
  • Links internos sin rutas rotas.
  • Performance aceptable en móvil y desktop.
  • Fallback o rollback documentado.

El checklist evita una trampa común: declarar éxito porque "la home se ve bien".

Por qué dos niveles funcionan mejor

flowchart TD portfolio["Portfolio<br/>riesgo bajo, exigencia media"] --> iterate["Iterar motor y tema"] iterate --> candidate["Candidato estable"] candidate --> product["Sitio de producto<br/>riesgo alto, exigencia alta"] product --> proof["Prueba comercial real"]

El portfolio cae en riesgo bajo y exigencia media: sirve para iterar. El sitio de producto cae en riesgo alto y exigencia alta: sirve para validar cuando el motor ya está preparado.

Qué aprende el producto

Pregunta Nivel 0 Nivel 1
¿Arranca desde cero? Sí No es el foco
¿Migra contenido real? No Sí
¿Aguanta blog técnico? Sí Sí
¿Aguanta sitio comercial? Parcial Sí
¿Puede romperse sin coste alto? Sí No
¿Sirve como argumento de venta? Apoya Demuestra

La trampa que evita

La trampa es lanzar el SaaS y "validar con clientes". El primer cliente que descubre que tu sistema no soporta i18n, SEO o navegación real no te abre un issue: se va.

Tip

El mejor dogfood reproduce problemas de cliente antes de que el cliente los pague con su paciencia.

La regla que me llevo

Un dogfood de un solo nivel valida la versión optimista del producto. Dos niveles con exigencias contrastadas validan que el producto es real.

Este artículo forma parte de mis notas de producto. Si te interesa el tema, sigue el blog o escríbeme.