¿Cuál de tus diez productos está roto ahora mismo?

Lanzaste diez cosas. Juntas pagan el alquiler. Por separado, ninguna gana lo suficiente como para merecer un lunes por la mañana — así que ninguna lo recibe.

Ese es el trato, y es un buen trato. Tiene un agujero.

La cartera solo funciona si cada producto cuesta casi nada de mantener

La cartera de una sola persona es un negocio viable hoy porque casi todos los costes recurrentes por producto se han automatizado. Los despliegues ocurren al hacer push. Los pagos, las facturas y los cobros fallidos son problema de otro. La base de datos está gestionada y el hosting escala solo. El soporte es una página de documentación y una bandeja de entrada que miras los jueves. Los errores aterrizan en una herramienta. Un monitor hace ping a cada URL y se queda callado.

Cada una de esas cosas eliminó un trabajo que antes crecía con el número de productos que tienes. Ese es todo el truco: el décimo producto solo merece la pena lanzarlo porque mantenerlo no te cuesta casi nada.

Queda un coste recurrente, y es el que te saltas: saber que aquello por lo que la gente paga sigue haciendo lo que pagan que haga. Te lo saltas porque saltárselo no tiene consecuencias inmediatas. Eso es exactamente lo que lo hace peligroso.

Los fallos que importan no lanzan errores

Piensa en las formas en que un producto rentable, silencioso y desatendido se muere de verdad.

• Una pasarela de pago deja obsoleta la versión de la API que fijaste. La página de pago se dibuja, el botón gira y no se cobra ninguna tarjeta.
• Un dominio de envío queda suspendido por un cambio en DMARC. El registro se completa. El correo de verificación no llega nunca, así que nadie puede terminar de crear una cuenta. Tu aplicación no ve ningún problema — entregó el mensaje correctamente.
• Una pantalla de consentimiento de OAuth necesita reverificarse. «Iniciar sesión con Google» ahora muestra un aviso de aplicación no verificada. Cada visitante lo lee como una estafa y se va.
• Una actualización de dependencias cambia los valores por defecto de una librería de formularios. Enviar ahora valida un campo que siempre está vacío, así que el formulario no se envía nunca — y nunca da error, porque negarse a enviar es justo para lo que sirve la validación.
• Una base de datos del plan gratuito se pausa por inactividad. La primera petición del día la despierta, agota el tiempo de espera y dibuja un estado vacío que parece un producto sin datos dentro.
• Un cambio de CSS mueve el botón de compra por debajo del pliegue en móvil, detrás del aviso de cookies.

La lista tiene algo en común. En todos los casos el servidor respondió, ningún código lanzó una excepción y ningún cliente se quejó.

Nadie se quejó porque quienes se lo encontraron eran desconocidos. No tenían tu correo y no te debían un informe de error. Los clientes que te lo habrían contado son precisamente los que nunca llegaron a ser clientes.

El uptime es una afirmación sobre tu servidor, no sobre tu producto

Tu monitor no te está mintiendo. Está respondiendo a una pregunta más estrecha que la que creías haber hecho.

Un pinger afirma que una URL devolvió un 200. Una página de pago que no puede cobrar una tarjeta devuelve un 200. Un formulario de registro que no envía ningún correo devuelve un 200. Y también lo hace una página que dibuja un estado vacío desde una base de datos que acaba de despertarse.

Una herramienta de errores afirma que tu código no lanzó ninguna excepción. Nada de la lista anterior lanzó una. Un dominio de envío suspendido es una llamada a la API correcta. Un formulario que se niega a enviarse es la validación funcionando según lo previsto.

Ambos instrumentos merecen la pena y ninguno de los dos observa a un cliente tener éxito. Esa es otra pregunta, y necesita otro instrumento.

Tres frases por producto, no tres suites de tests

El alcance suena imposible y no lo es, porque no necesitas testear diez productos. Necesitas testear el camino del dinero a través de diez productos, y es corto.

En casi cualquier producto hay tres flujos que llevan ingresos:

1. Un desconocido puede convertirse en usuario.
2. Un usuario puede pagarte.
3. Aquello por lo que pagó hace lo que tiene que hacer.

Diez productos, tres flujos cada uno, son treinta comprobaciones. Suena a mucho justo hasta que te das cuenta de que son treinta frases, no treinta repositorios:

Registrarse con una dirección de correo nueva, confirmar la cuenta
desde el correo de verificación y llegar al panel.

Pasar al plan Pro con una tarjeta de prueba y ver que el plan cambia
a Pro en la página de facturación.

Pegar una URL en la caja, ejecutarla y obtener un informe con al
menos una fila.

Escríbelas como le describirías el producto a un amigo. Si no puedes describir el flujo en una frase, eso ya merece la pena saberlo por sí solo.

Por qué no has hecho esto ya, y por qué tenías razón

Merece la pena decirlo claramente: saltarte esto no fue pereza. Fue aritmética, y la aritmética era correcta.

Una suite de Playwright es un artefacto de ingeniería de verdad: selectores, fixtures, cuentas de prueba sembradas, un pipeline de CI donde ejecutarla y una factura de mantenimiento cada vez que mueves un botón. Diez de esas no son una estrategia de testing, son un segundo trabajo. Peor aún: el mantenimiento crece por producto, mientras que los ingresos también son por producto y mucho menores. Para algo que gana doscientos al mes, una tarde arreglando selectores rotos cuesta más que la caída que habría evitado.

Así que hiciste lo sensato y lanzaste el undécimo producto.

Lo que ha cambiado no es tu disciplina. Es que el coste por producto de una comprobación ha bajado lo suficiente como para que treinta de ellas dejen de ser un segundo trabajo.

Lo que esto sigue sin hacer por ti

Dos límites honestos, porque una comprobación que se vende de más es una comprobación en la que dejas de confiar.

No te va a decir que un producto ha dejado de importar. Los tres flujos pueden pasar todos los días mientras el producto se muere en silencio por falta de demanda, de tráfico y de razón de ser. Eso es un fallo real en una cartera y ningún monitor lo detecta.

Tampoco va a cubrir los casos límite. Estás cubriendo el camino del dinero a propósito y dejando el resto sin cubrir, que es la decisión correcta a este tamaño y sigue siendo una renuncia.

Y si un producto gana nueve dólares al mes, la respuesta puede ser cerrarlo en lugar de vigilarlo. Una cartera es un conjunto de decisiones, no un museo.

A dónde lleva esto

El obstáculo nunca fue saber qué comprobar — podrías escribir las treinta frases esta tarde. Fue que convertirlas en algo que se ejecute exigía construir y mantener una suite de tests por producto, que es justo el coste que el modelo de cartera existe para evitar.

Esa brecha es la que Testmode está hecho para cerrar: escribes el flujo como una frase, se ejecuta contra el producto real ya desplegado en un navegador real y con la frecuencia que elijas, y te avisa cuando un cliente habría fallado — sin código de test, sin pipeline y sin instalar nada en ninguno de los diez repositorios. Si quieres la mecánica en lugar del argumento, testing de regresión sin equipo de QA explica cómo elegir los flujos y qué hacer cuando uno falla.