Construí este producto completamente solo, sobre todo por las noches, los fines de semana y a costa de más días festivos de los que me gustaría admitir. Durante mucho tiempo siguió sintiéndose como un proyecto personal que, por casualidad, estaba disponible en la web.
Activar los pagos cambió esa sensación de inmediato. El código no se volvió de repente más sofisticado, pero mi responsabilidad sobre el producto sí cambió. En cuanto alguien puede pagar, un flujo roto ya no es simplemente un edge case pendiente. El onboarding, la moderación, la retención, la confianza y la fiabilidad dejan de ser asuntos para el futuro. Pasan a formar parte de lo que el producto promete ahora mismo.
Esa es la principal lección que me dejó el lanzamiento: construir en solitario un proyecto lleno de funcionalidades y operar un producto real son trabajos distintos.
En el desarrollo en solitario, la atención se convirtió en el cuello de botella
Mientras construía el producto, casi desaparecí de las redes sociales. No fue una estrategia de lanzamiento. Las decisiones de producto, la implementación, los edge cases, las pruebas de flujos y la preparación de la release competían por las mismas horas limitadas.
Ahora entiendo mucho mejor esa parte del trabajo en solitario. El cuello de botella no siempre es la velocidad a la que puedo escribir código. Es cuánta atención puedo dedicar a un número cada vez mayor de estados, transiciones y modos de fallo dentro del producto.
Un build exitoso no responde esas preguntas. Un pago exitoso tampoco.
Los pagos cambiaron lo que significa un bug para mí
Antes de los pagos todavía podía ver ciertas asperezas como cosas que arreglaría más adelante. Una vez que los pagos estuvieron activos, ese modelo mental dejó de servirme. Un producto de pago no tiene que estar libre de bugs; eso no sería realista. Pero el coste de dejar sin resolver un problema conocido cambia cuando otra persona ya ha confiado dinero al producto.
Lo mismo ocurre con el onboarding y la moderación. Durante el desarrollo pueden parecer sistemas auxiliares alrededor de la función “real”. En producción forman parte de esa función porque el usuario los experimenta directamente. La retención se parece mucho: una buena primera sesión no demuestra que el producto dé una razón para volver.
Los pagos no demostraron que estuviera terminado. Mostraron cuánto trabajo se escondía detrás de la palabra “terminado”.
El lanzamiento me dio otro tipo de información
Después del release llegó el trabajo menos fotogénico: bugs que solo se hacen visibles después de publicar, flujos rotos, problemas de moderación que se vuelven reales cuando aparecen usuarios y preguntas de retención mucho más difíciles que causar una buena primera impresión.
Intento no sobreinterpretar esas señales. Un bug después del release no significa automáticamente que la arquitectura sea mala. Un problema de retención no es, por sí solo, un diagnóstico de product-market fit. Un problema de moderación no demuestra que todo el sistema sea inseguro. Un síntoma me indica dónde investigar; no me dice automáticamente cuál es la causa.
Lo que cambia es la calidad de la evidencia. Antes del lanzamiento puedo probar lo que espero que hagan los usuarios. Después tengo que lidiar con lo que hacen de verdad. Un release no es el momento en que desaparece la incertidumbre. Es el momento en que una parte de la incertidumbre más importante por fin se vuelve observable.
El ciclo post-lanzamiento que uso ahora
Ahora me interesa más el trabajo posterior al lanzamiento que pulir la historia del propio lanzamiento: lecciones sobre pagos, flujos rotos, retos de moderación, comportamiento de usuarios, sorpresas de retención y pequeñas correcciones que hacen el producto cada vez más fiable.
- Observar el flujo real. No asumir que el camino que diseñé es el mismo que siguen los usuarios.
- Separar síntomas y causas. Un paso que falla muestra dónde ocurrió algo, no necesariamente por qué.
- Priorizar los fallos que afectan a la confianza. Pagos, acceso, onboarding y moderación merecen más urgencia que los defectos cosméticos porque el coste del fallo es mayor.
- Arreglar primero el problema verificado más pequeño. Prefiero eliminar una fuente de fricción confirmada que rediseñar un sistema alrededor de una suposición.
- Volver a comprobar la experiencia después del arreglo. Un cambio de código puede ser correcto y aun así no resolver el problema del usuario.
No es un framework universal. Es simplemente la disciplina que más sentido tiene para mí después de pasar de construir a operarlo.
El lanzamiento cambió mi fuente de verdad
La distinción que más me importa ahora es entre haber construido el producto y estar preparado para operarlo. Construir pregunta si el sistema puede hacer lo que diseñé. Operar pregunta qué ocurre cuando personas reales lo usan, lo entienden mal, lo abandonan, vuelven, pagan o llegan a un recorrido que no había previsto.
Por eso ya no veo el lanzamiento como una meta. Antes del lanzamiento, la mayor parte de la evidencia viene de mis propias suposiciones y pruebas. Después, el producto empieza a responder mediante comportamiento real, fallos y uso repetido.