El code fue la parte fácil de lanzar Prova

Prova empezó a sentirse real para mí en el momento en que el producto dejó de permitirme mentirme a mí mismo.

Una homepage puede quedarse aspirational durante mucho tiempo.

Un producto live no.

En cuanto la gente puede registrarse, confirmar su email, caer en el lugar equivocado, tocar billing state, enviar trabajo y esperar que el sistema recuerde lo que pasó, el bottleneck cambia.

El producto empieza a hacer promesas reales. Y el trabajo invisible se vuelve muy visible.

Si viste los tres posts que escribí en marzo y a principios de abril sobre mi cambio de Claude Max a Codex, ese experimento sigue en marcha. Ya prometí un follow-up de verdad para el May 2, 2026, y pienso cumplir esa promesa. Este no es ese post.

Pero Prova me obligó a ver antes de lo esperado una realización más útil:

En cuanto algo deja de ser una idea con nombre y empieza a convertirse en un producto real, el bottleneck cambia.

Al menos así se sintió en este build.

La parte difícil no fue conseguir que un LLM generara code.

La parte difícil, al menos en este push para mí, fue todo lo que rodea al code.

Si ahora mismo estás construyendo con AI, sobre todo algo que involucra usuarios reales, dinero real o product state real, creo que esta es justo la parte sobre la que casi nadie te advierte.

La lección más útil es otra: qué empieza a importar cuando un producto deja de ser solo una demo.

Ponerle nombre fue la parte fácil

Tengo que admitirlo: ponerle nombre a Prova fue una de las decisiones más fáciles de todo el proceso.

El nombre encajó porque de verdad encajaba con el producto.

Prova significa algo como prueba o test. Y ese es, básicamente, el trabajo del producto. No está para halagar a nadie ni para hacerle sentir builder antes de tiempo. Está para obligarlo a demostrar el trabajo. Es un nombre bonito, útil, searchable. En otras palabras, esa era la parte fácil.

La parte más dura empezó justo después. Porque, en el momento en que Prova dejó de ser solo un nombre y una landing page, empezó a exigir todas esas cosas poco glamorosas que los productos reales siempre exigen:

• assessment logic
• onboarding state
• authored progression
• review visibility
• billing flows
• auth hardening
• content publishing
• release gates

Eso cambió cómo pienso tanto sobre las AI tools como sobre product building.

En qué tuvo que convertirse realmente Prova

Prova es ahora un programa estructurado para builders con AI dirigido a marketers y profesionales de publicidad que quieren pasar de usar AI tools a construir workflows, pilots y operating systems reales. En la práctica, eso significó assessment y onboarding, un producto sprint-first en lugar de chat-first, progression guiada por review, un product state durable y una capa de mentor que se comporta más como office hours alrededor del sprint actual que como una caja de chat genérica.

Para dejarlo claro: no estoy diciendo que Prova esté "terminada". Ojalá pudiera decir eso y seguir, pero sería demasiado conveniente, y probablemente tampoco sería verdad. La forma honesta de describirlo hoy es soft launch: el core production system está live y funcionando, pero todavía hay trabajo intencional de launch-readiness en la lista, incluyendo cleanup del return path del billing portal y una cobertura más completa para la automatización de MFA. De hecho, creo que eso hace la lección más útil, no menos. Así es como se ve product building en el mundo real. No está terminado. No es fake. Solo es lo bastante real como para que el siguiente error cueste algo.

El trabajo que yo no podía simplemente generar

La versión más fácil de un AI product casi siempre es la versión demo.

Puedes hacer que parezca viva bastante rápido:

• una homepage
• una chat box
• algunas screenshots elegantes
• una frase de producto convincente

Eso sirve para un teaser de lanzamiento.

No sirve mucho para entender dónde está el trabajo de verdad.

Para mí, ese trabajo empezó a aparecer en seis lugares.

1. El sistema de sprints tenía que dejar de fingir

Yo no quería que Prova fuera otro producto que se ve estructurado en la landing page y se vuelve genérico en cuanto alguien entra.

Los fixed authored sprints fueron útiles hasta que dejaron de serlo.

El problema real apareció cuando un learner pasaba un sprint, pero su siguiente gap real no era el siguiente sprint authored del catálogo.

La respuesta perezosa habría sido:

"Que el modelo invente el siguiente sprint: title, rubric, review criteria, todo."

Yo no confiaba en eso.

Así que el sistema tuvo que volverse más estricto.

Ahora el reviewer todavía puede recomendar el canonical next sprint cuando el authored path es el correcto. Puede asignar un adaptive detour, es decir, un sprint temporal que ayuda al learner a corregir una foundation gap antes de volver al camino principal. Y cuando el siguiente gap real cae fuera del authored catalog, puede pedir un composed sprint.

Eso suena pequeño en un blog post.

No lo es dentro de un producto.

Porque un composed sprint no es solo "texto dinámico".

Tiene que crear un sprint placeholder, persistir la asignación, conservar el return path hacia la roadmap canónica, rellenar el sprint packet y luego permitir que el resto del sistema trate ese sprint como product state real.

La constraint que hizo esto confiable era bastante simple:

el modelo no puede inventarse el estándar.

El composed sprint solo rellena el packet: title, summary, context, assignment, example.

El submission schema y la review rubric siguen viniendo de un authored template sprint.

Esa fue una de las lecciones más importantes de todo este build.

Si quieres que algo dinámico siga siendo confiable, mantén fijo el contrato y deja que el modelo opere dentro de ese contrato.

Aquí también fue donde Codex me ayudó bastante. No de una forma flashy tipo "mira lo que generó". Sino de una forma mucho más útil: migrations, router logic, placeholder lifecycle, request state, integration tests y todo ese trabajo aburrido de contratos que hace que un producto dinámico se sienta menos fake.

También tengo que admitir que la versión perezosa me tentó, al menos por un momento. Dejar que el modelo sea clever. Dejar que el sistema se vea magical. Limpiar después. Suena muy bien hasta que te imaginas explicándole una mala asignación de sprint a un usuario que está pagando.

2. Retrieval tenía que volverse curricular, no solo semantic

En cuanto dejé que el sistema compusiera sprints, la calidad de retrieval dejó de ser un detalle de backend.

Pasó a ser calidad de curriculum.

Si el producto iba a componer un sprint sobre tooling, measurement o competitive intelligence, no podía limitarse a sacar chunks "más o menos relacionados" de la knowledge base y esperar que el packet saliera coherent.

La knowledge base tenía que volverse más inteligente.

La reconstruimos a partir del corpus real: blog posts, course modules, transcripts, companions, templates y recursos más profundos.

Luego chunked esas fuentes de forma distinta según lo que eran.

Los blog posts narrativos podían quedarse en chunks más grandes.

Los instructional modules necesitaban chunks guiados por headings.

Los templates y assets de referencia necesitaban un chunking más estructurado para preservar tablas, checklists, referencias de slides y quick-reference sections en lugar de aplastarlo todo en párrafos genéricos.

Y después vino el tagging.

No solo "de qué trata esto", sino también:

• qué tipo de chunk es
• qué topic tags le encajan
• para qué audience sirve
• en qué difficulty level cae

Eso hizo que retrieval dejara de ser "nearest vector wins" y pasara a parecerse más a un curricular matching.

El producto ya podía preguntar algo como:

"Dame material grounded para este topic, para esta audience, alrededor de este nivel."

Eso es un sistema bastante más serio que pegarle RAG a una demo.

3. Los evals tenían que probar la pipeline, no solo el modelo

Esta tal vez fue la lección más importante de todas.

No quería declarar victoria solo porque un composed sprint se veía decente en la UI.

Así que el sistema de evals tuvo que crecer junto con el producto.

Primero estuvo el sprint review eval harness.

Luego composition añadió un retrieval gate, básicamente un pass/fail check para ver si el tagged retrieval realmente estaba mejorando el grounded material frente a la baseline sin tags.

Y después composition añadió un harness completo end to end:

• componer el sprint packet
• generar synthetic submissions que sigan siendo válidas para el schema
• correr el reviewer real sobre esas submissions
• juzgar los resultados por grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality y comparación con authored work

Ese fue el learning loop real.

Dicho en lenguaje más simple, el objetivo era impedir que la "personalized progression" se convirtiera en fake personalization. Si el sistema iba a decir "este siguiente sprint es realmente para ti", necesitaba algo más que un packet que se viera bien. Necesitaba evidencia de que el sprint estaba grounded, que era apropiado para el nivel y que seguía pudiendo revisarse con los mismos estándares que el curriculum authored.

No era "¿el modelo devuelve JSON o no?"

Era más bien:

• ¿el packet seguía grounded?
• ¿el track framing realmente cambiaba el work product?
• ¿level 2 y level 5 se sentían materialmente diferentes?
• ¿el reviewer seguía acertando al decidir pass o revise?
• ¿el composed sprint seguía sintiéndose parte del curriculum en vez de flotar a un lado?

Ese loop sacó problemas reales a la luz.

Revise submissions débiles que aun así seguían siendo demasiado fuertes.

Audience framing que se colapsaba entre tracks.

Packets de measurement que sonaban bien pero no respondían a preguntas de confianza distintas para learners distintos.

Uno de los momentos más humillantes para mí fue darme cuenta de cuántas veces algo podía verse "bastante bien" en la UI y aun así romperse en cuanto le hacía una pregunta más estricta. Un packet podía leerse fluido y seguir siendo demasiado genérico. Un revise case podía parecer plausible y seguir siendo demasiado fácil. Para mi ego, la verdad, eso fue bastante útil.

Y por eso creo que esta parte importó tanto.

El sistema no mejoró porque yo tuviera un buen prompt.

Mejoró porque el producto podía fallar delante de mí, dentro de un eval harness, antes de fallar delante de los usuarios.

Gran parte del aprendizaje real ocurrió en un loop bastante apretado entre el 8 y el 10 de abril:

• schema groundwork
• composed sprint lifecycle
• tagged knowledge rebuild
• retrieval gate
• composition calibration
• full eval pass
• integration coverage
• browser QA sobre el flujo live

Esa secuencia importa.

No fue un milagro. Fue un loop controlado.

4. Los puntos donde se juega la confianza tenían que ser reales

Aquí también es donde los productos reales se separan de las demos.

A nadie le importa lo elegante que se vea tu capa de AI si:

• email confirmation falla
• Google sign-in es inestable
• el usuario queda atrapado en un auth loop
• faltan abuse controls
• el account hardening parece un detalle de último minuto

En Prova, esa capa de credibilidad terminó incluyendo:

• email confirmation que devuelve a la gente al flujo correcto del producto
• Google SSO
• optional app-based two-factor auth (TOTP MFA)
• protección con Turnstile en auth y assessment

Ese es el tipo de trabajo del que casi nadie presume porque suena operacional y aburrido.

Creo que eso es un error.

Es precisamente en lo operacional y aburrido donde los productos se ganan la confianza o la pierden en silencio.

5. Billing tenía que ser testeable, no solo imaginable

Cada vez soy más escéptico con los builders que hablan de monetization como si estuviera a un screenshot de Stripe de quedar resuelta.

Billing se vuelve real muy rápido.

No se trata solo de:

"¿Puede alguien pagar, técnicamente?"

Sino de:

• qué pasa durante el trial state
• qué pasa cuando el webhook state llega tarde
• cómo testear con seguridad sin hacer teatro sobre tu propia superficie de revenue
• cómo verificar todo el flow sin inventarte excepciones puntuales que luego vuelvan menos fiable el sistema

Prova ahora tiene un subscription flow real y, además, un internal QA checkout path precisamente para verificar billing de forma más segura. Puede sonar menor. No lo es. Cuanto más serio se vuelve un producto, más necesitas formas de testear la lógica comercial sin mentirte sobre lo que está y lo que no está verificado.

6. Operations tenía que volverse parte del producto

Una de las cosas que hizo que Prova se sintiera real para mí fue tener que tratarlo como un sistema operativo aparte, no como un feature metido dentro de mi sitio actual.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Esa frase no es sexy. También es, probablemente, la frase que más importa.

Porque los productos no se rompen solo en la UI. Se rompen donde los sistemas se tocan, donde se filtran las suposiciones, donde los entornos se desalinean, donde alguien dice "eso lo arreglamos después del launch" y luego ese después nunca termina de llegar.

Cuanto más trabajaba en Prova, más respeto me daban las frases operativas y aburridas.

Si quieres una prueba de presión rápida para tu propio AI product, pregúntate:

• qué estándar se mantiene fijo cuando el modelo se vuelve dinámico
• qué retrieval mantiene grounded el output
• qué eval detecta fake personalization antes que un usuario
• qué edge de auth, billing o state te avergonzaría mañana

Si esas respuestas siguen borrosas, probablemente el producto todavía es más demo que sistema.

La prueba que de verdad importa

No quiero hablar de productization solo en abstracto, porque así suena más filosófico de lo que en realidad es.

La prueba que más importa no es "¿cuántas migrations escribí?"

La pregunta es: ¿qué funciona ya para un usuario real?

En esta fase de soft launch, el producto ya puede decir de forma creíble:

• email signup y confirmation funcionan
• Google SSO funciona
• optional TOTP MFA funciona
• downloadable resources y signed downloads funcionan
• sprint submission y AI review funcionan en production
• Stripe checkout handoff funciona

Esa es la capa de prueba que mira el comprador.

Debajo de eso también hay prueba de sistema en el repo y en el rollout:

• 17 Supabase migrations aplicadas a través del schema bootstrap actual de production
• 4,390 knowledge-base rows en production publicadas y etiquetadas para composition retrieval
• 38 downloadable resources publicados
• un tagged retrieval gate que supera la baseline sin tags
• una 18-case composition eval suite completa pasando su gate
• un internal QA checkout path más seguro para verificar billing

No estoy listando estos números para sonar ocupado.

Lo que todavía no tengo es prueba externa amplia, de una cantidad significativa de usuarios, diciendo: "esto me cambió resultados." Es demasiado pronto para eso, y no quiero fingirlo.

Los listo porque es muy fácil subestimar lo que realmente significa "convertir una idea en un producto" cuando solo hablas en lenguaje de launch.

Lo importante no son las cuentas en sí.

Es lo que esas cuentas representan:

• el sistema de sprints dejó de ser decorativo
• retrieval dejó de ser difuso
• evaluation dejó de ser performativa
• el product state se volvió lo bastante durable como para apoyarse en él

El trabajo invisible sigue siendo trabajo.

Y casi siempre es el trabajo más duro.

Lo que esto me cambió en la cabeza

Sigo pensando que las AI tools importan. Claro que importan.

Codex fue útil en este empuje porque se sentía competente, cuidadoso y metódico. Me ayudó a moverme por trabajo de engineering sin demasiado teatro emocional. Claude sigue pareciéndome mejor cuando el trabajo se vuelve más de gusto, más creativo.

Pero Prova me empujó hacia una conclusión más importante:

Creo que la AI puede acelerar la implementación, pero no elimina la necesidad de criterio sobre boundaries del producto, sequencing, credibilidad y verdad operativa.

Ese criterio sigue siendo el trabajo.

Una landing page no es un producto.

Un concepto con nombre no es un producto.

Una interfaz de chat no es un producto.

Un componente generado, desde luego, no es un producto.

Para mí, lo que hace que algo empiece a sentirse como producto es la arquitectura invisible alrededor de la experiencia visible. En el momento en que usuarios reales pueden entrar, pagar, progresar, bloquearse, recuperarse, enviar trabajo y confiar en el state que ven, ya no estás jugando con una demo. Estás haciendo promesas.

Y creo que es en las promesas donde product building se vuelve serio.

Esta es la lección de abril que más me sirve

Todavía debo el veredicto completo de 30 días con Codex el May 2, 2026, y pienso publicarlo entonces.

Ese post será el lugar correcto para la cronología de costes, la historia de los limits, lo que eché de menos de Claude y lo que cambió en mi forma de trabajar día a día.

Pero Prova ya me enseñó algo más duradero que una comparación entre tools:

La parte interesante de AI product building rara vez es la demo.

Es el punto en el que tu sistema empieza a hacer promesas reales a usuarios y te das cuenta de cuántas de esas promesas viven fuera del code generado.

A esa parte le tengo mucho más respeto ahora.

Y, sinceramente, creo que es la parte de la que más builders deberían hablar.

Preguntas frecuentes

¿Qué es Prova?

Prova es un programa estructurado para AI builders dirigido a marketers y profesionales de publicidad que quieren pasar de usar AI tools a construir workflows, pilots y operating systems reales. En términos de producto, eso significa assessment, onboarding, sprint progression, review logic, resources, billing, auth y product state trabajando juntos, en lugar de una sola chat box de AI fingiendo ser todo el sistema.

¿Qué es un composed sprint en Prova?

Un composed sprint es un sprint packet generado para una brecha real de un learner que queda fuera del authored catalog actual. La constraint importante es que el modelo no se inventa el estándar por su cuenta. El packet es dinámico, pero el submission schema y la review rubric siguen viniendo de un authored template sprint.

¿Por qué AI product building se vuelve más difícil después de la demo?

Porque en el momento en que usuarios reales pueden registrarse, pagar, recuperarse de errores, enviar trabajo y confiar en el state que ven, el producto empieza a hacer promesas. En ese punto, los sistemas invisibles que rodean la capa de AI, como auth, retrieval quality, evals, billing y operations, importan más que el primer output impresionante de una demo.

Si ahora mismo estás construyendo con AI, de verdad me daría curiosidad saber:

¿cuál fue el primer momento en que tu proyecto empezó a sentirse incómodamente real, el momento en que una demo se convirtió en una promesa?

Eso es todo de mi parte.

Cheers, Chandler