Hay un tipo de frustración particular que no aparece en los tutoriales.

No es el error de compilación que te dice exactamente qué está mal. No es el crash obvio que te da un stack trace. Es el silencio: el sistema funciona, el deploy está en verde, y los datos simplemente no aparecen.

Hoy fue uno de esos días.

El objetivo del día

LabelLoop está casi en producción. La landing page está deployada. El quiz de perfilamiento funciona en el frontend. El backend tiene un endpoint que debería capturar cada respuesta y guardarla en una base de datos de Notion.

El objetivo de hoy era simple: confirmar que ese flujo completo funciona antes de empezar a distribuir el link.

Spoiler: todavía no funciona. Y eso es exactamente lo que hay que publicar.

El primer problema: dos versiones del mismo código

Antes de poder testear, hubo que resolver algo que se había acumulado sin que me diera cuenta.

Tenía dos versiones del código divergiendo en ramas separadas:

Versión local (lo que estaba en mi máquina):

Versión remota (lo que estaba en producción antes):

Ninguna de las dos era completa. Había que fusionarlas de forma quirúrgica.

La solución fue un git merge estratégico: tomar el archivo waitlist.ts de la rama remota (correcto en cuanto a env vars) y el archivo WaitlistQuiz.astro de la rama local (correcto en cuanto a estilos). Cinco archivos resueltos uno por uno. El merge commit fe4dda4 llegó a Vercel y desplegó limpio.

El segundo problema: columnas en español

Mientras esperaba el deploy, abrí la base de datos de Notion donde deberían llegar los registros.

Ahí estaba el segundo problema: las columnas tenían nombres en español.

Producto. Segmento. Fecha. Respuestas.

El código deployado espera inglés: Product, Segment, Submitted At, Answers.

Si el código intenta escribir en una columna Product y la columna se llama Producto, Notion simplemente crea una columna nueva o falla silenciosamente.

Renombré todas las columnas. Renombrar columnas en Notion vía API no es trivial — la operación ALTER COLUMN SET SELECT creó una columna duplicada Segment 1 en lugar de modificar la existente. Hubo que hacer la operación en dos pasos: eliminar la columna original y renombrar la nueva. Pequeño caos, resuelto.

El tercer problema: el deploy está en verde. Nada llega.

Con el merge commit deployado y el schema de Notion corregido, era momento de testear.

Abrí labelloop.olaveruiz.cl, completé el quiz, envié.

Fui a Notion.

Nada.

Este es el punto donde el debugging entra en su fase más incómoda: no hay error visible. No hay nada que decirte qué salió mal. El frontend no muestra error. El deployment dice READY. La base de datos está vacía.

Las hipótesis, en orden de probabilidad:

  1. La integración de Notion no está conectada a la base de datos. Un token de Notion puede ser válido pero si la integración no tiene acceso explícito a esa base de datos específica, todas las escrituras fallan silenciosamente. Hay que verificar en Notion → base de datos → Share → Connections.

  2. El token está mal configurado. El usuario ingresó el token manualmente en Vercel. Si hay un caracter extra, si el token expiró, si es el token equivocado — el resultado es silencio.

  3. Las variables de entorno tienen el valor incorrecto. NOTION_DATABASE_WAITLIST debería tener el ID 1c143b1a6ddc4b8eb2bbcd214c52decf. Si tiene otro valor, ninguna escritura llegará.

  4. El quiz no está completando el POST. Podría ser que el problema sea client-side: el quiz falla antes de hacer el fetch, sin mostrar error al usuario.

Para mañana, hay un test claro que resolverá la ambigüedad:

curl -X POST https://labelloop.olaveruiz.cl/api/waitlist \
  -H "Content-Type: application/json" \
  -d '{"productSlug":"labelloop","email":"test@test.com","segmentName":"Test","answers":{"1":0},"submittedAt":"2026-04-18T00:00:00Z"}'

Si responde {"ok":true} → el servidor funciona, el problema es el quiz en el browser. Si responde con error 503 → las variables de entorno no están o son incorrectas. Si responde con error 502 → Notion rechazó la solicitud (token o permisos).

Una línea de curl. Tres posibles respuestas. Problema resuelto.

Por qué publicar un día sin resolución

Esta es la tensión del Build in Public real.

Cuando el día tiene un desenlace limpio — “resolvimos el bug, todo funciona” — el contenido escribe solo. Cuando el día termina con un problema sin resolver, hay una tentación de esperar. Publicar mañana cuando ya esté arreglado. Dar la historia completa.

Pero eso no es honesto. Y sobre todo, no es útil.

El momento más valioso de un blog técnico no es el tutorial del éxito — es el proceso de aislar un problema. La lista de hipótesis ordenadas por probabilidad. La decisión de parar y retomar con un test claro en lugar de seguir adivinar.

Hoy se avanzó. Git divergence resuelta. Schema corregido. Deploy verificado. El problema de Notion no desapareció — pero está aislado. Mañana hay una respuesta esperando en esa línea de curl.

Eso es progreso real, aunque la base de datos siga vacía.

Qué viene mañana

Primero: el diagnóstico curl. Eso resuelve el 80% de la ambigüedad en menos de un minuto.

Si el problema es el token o la conexión de integración, se corrige en 5 minutos desde el dashboard.

Si el problema es client-side, se revisa el Network tab del browser y se rastrea dónde falla el fetch.

Una vez que los datos lleguen a Notion, LabelLoop está listo para distribución. La landing page funciona. El quiz captura intención. Solo falta confirmar que el pipe de datos es confiable.

Es el último paso antes de empezar a atraer waitlist real.