A principios de 2025 lancé mi primer producto al público. No era un proyecto para un cliente, ni un prototipo que vivía en mi notebook: era un producto nuestro, construido desde cero, con gente real registrándose. A finales del mismo año, lo archivamos.
No fue un producto mal hecho, ni un equipo que se deshizo, ni una idea en la que nadie creía. Teníamos casi todo lo que se supone que importa. Aun así, no avanzó. Este post es un intento de explicar por qué, de la forma más honesta que puedo, desde el punto de vista de quien era responsable de construirlo.
Lo que teníamos
El producto era una plataforma web y mobile para nutricionistas y entrenadores personales: un lugar para prescribir planes de alimentación y entrenamientos, seguir el progreso de cada cliente y gestionar las consultas, todo en una sola app.
Éramos un buen grupo de socios, cada uno con su función bien definida. Yo era el "CTO", entre comillas, porque el título es generoso para una empresa de ese tamaño. Teníamos contactos dentro del mercado al que apuntábamos. Lo construimos desde cero, lo lanzamos e hicimos las reuniones que vienen después de un lanzamiento. Incluso nos sentamos con inversores: conversaciones y negociación, nada de dinero al final, pero interés real en lo que habíamos construido.
Si me hubieras mostrado esa lista antes de empezar, habría dicho que era una buena posición. Producto, equipo, red de contactos, lanzamiento, interés de inversores. La mayoría de los proyectos que yo había visto morir no tenían ni la mitad de eso.
Dónde creía que estaba el riesgo
Como quien lo estaba construyendo, creía que el riesgo era sobre todo técnico. ¿La app va a ser estable? ¿Los pagos van a funcionar? ¿Va a aguantar cuando la gente la use de verdad? Esas eran las preguntas en las que gastaba la mayor parte de mi energía, y eran las que sabía responder.
Mirando hacia atrás, ese era el lugar más cómodo para poner el riesgo. Era la parte que yo controlaba. Si el problema era técnico, se podía resolver con más trabajo. No tenía un plan para el caso en que el producto funcionara y aun así la gente no viniera.
Dónde se trabó
Alguna gente vino. Algunos profesionales usaron la plataforma con sus propios clientes dentro. Así que no es cierto que el producto no le funcionó a nadie. Simplemente nunca llegó al punto de crecer por sí solo.
Probamos los canales de siempre: Meta Ads, Google y contacto directo con gente del nicho. El problema no fue elegir el canal equivocado. Fue lo que el cliente encontraba del otro lado de cada canal: un mercado con competidores establecidos, que se destacaban más que nosotros.
Y cuando la gente nos probaba, chocábamos con dos cosas que subestimé. La primera fue el soporte. Un profesional que maneja parte de su negocio en tu app necesita respuestas rápidas, y ahí fallábamos. La segunda fueron features que simplemente no se nos habían ocurrido: los edge cases del uso real, las cosas que solo aparecen cuando la rutina real de alguien se encuentra con tu producto. Cada una era pequeña. Juntas, eran la diferencia entre probar el producto y quedarse en él.
Nada de eso es un problema de código. Podría haber escrito mejor código y nada de esta lista habría cambiado.
Cómo terminó
No hubo un día en que murió. El producto se fue apagando de a poco, y en algún momento una conversación entre los socios hizo oficial lo que ya era verdad. A finales de 2025, lo archivamos.
Ser el "CTO" de algo que claramente salió mal es una sensación extraña. La parte de la que eras responsable se sostuvo. La empresa no. Y empiezas a ver que la línea entre esas dos cosas nunca fue tan clara como creías.
Lo que haría hoy
Si empezara hoy, sé por dónde empezaría, y no sería por el código.
- Validar la tesis antes de construir. No si a la gente le gusta la idea, sino si el mercado realmente necesita este producto, viniendo de nosotros, como para cambiar lo que ya usa.
- Distribución desde el primer día. No como una fase que empieza cuando el producto está listo, sino como parte del producto. ¿Quién se va a enterar de esto, y por qué nos creería?
- Posicionamiento. En un mercado con competidores establecidos, "nosotros también hacemos esto" no es una razón para cambiar. Saber exactamente para quién es, y por qué es mejor para esa persona, es un trabajo que tiene que pasar antes del primer anuncio.
- Build in public. Mostrar el trabajo mientras se hace, para que la gente vea que es bueno. La confianza en un producto muchas veces empieza como confianza en quienes lo construyen, y esa confianza tarda más en construirse que cualquier feature.
- El soporte como parte del producto. Para quien maneja su propio trabajo en tu plataforma, la velocidad con la que respondes es parte de lo que está pagando.
Lo que me llevé
En mi último post escribí que, en algún momento, escribir código deja de ser la parte difícil. Aquí fue donde lo aprendí de la forma cara. Construimos el producto. Lo que no construimos fue una razón para que alguien lo eligiera.
Todavía llevo eso a la forma en que trabajo en productos hoy. No como "los ingenieros tienen que hacer marketing", sino como preguntas que hago mucho antes que antes: ¿para quién es esto, cómo lo van a encontrar y por qué confiarían? El código responde muchas preguntas. Esas no están entre ellas.
Construimos el producto. La distribución era el producto.