De un proyecto de cliente a un producto: cuándo tiene sentido

Antes de 2004, 37signals era una firma de diseño web de tres diseñadores cuya comunicación de proyectos con los clientes se había vuelto un desorden. Las actualizaciones por correo funcionaban, como diría después Jason Fried, durante unos cinco minutos. Así que construyeron su propia herramienta de proyectos y empezaron a manejar el trabajo con clientes a través de ella. Los clientes les decían una y otra vez que necesitaban algo así para sus propios proyectos. La firma la lanzó como Basecamp el 4 de febrero de 2004. En privado esperaban que generara 5,000 dólares al mes después de un año. Llegó ahí en seis semanas.

La historia suele contarse como si el camino fuera obvio: construir para ti o para un cliente, notar la demanda, convertirte en una empresa de software. Es sesgo de supervivencia. La mayoría de las herramientas internas y de los desarrollos para clientes nunca se convierten en otra cosa, y la mayoría no debería.

La pregunta también está menos resuelta que antes. En junio de 2025, Andreessen Horowitz publicó un ensayo que argumentaba que las empresas de software de IA deberían abrazar los servicios, con forward deployed engineers que se integran a la operación del cliente y hacen el trabajo de implementación. Decía que "a veces los servicios intensivos en personas son necesarios para crear software transformador". Las empresas de producto se están moviendo hacia los servicios al mismo tiempo que algunas firmas de servicios se mueven hacia los productos. La frontera se está desdibujando desde ambos lados, y eso hace más importante saber por qué la estás cruzando.

Dos orígenes distintos

En WAOF, un estudio de tecnología, producto y creatividad que nació en Monterrey, dos de nuestros productos surgieron del trabajo con clientes, y vinieron de lugares distintos. La diferencia importa.

Neo empezó dentro de Soriana en 2023. Soriana necesitaba capacitar a una fuerza laboral nacional que cambia constantemente, y construimos su sistema de aprendizaje corporativo desde dentro de la operación. Nuestra tesis lo describe como un LMS corporativo a la medida con una experiencia tipo streaming, construido para centralizar el conocimiento operativo en una red nacional de retail, con 58,146 usuarios registrados desde 2023. Se convirtió en neo.education, y hemos dicho públicamente que lo estamos abriendo a más operadores. Neo es el caso de un proyecto que resultó ser más general que su brief.

Mapboard no salió de un solo proyecto. Durante años, las cadenas de retail en México nos dijeron lo mismo: las herramientas de búsqueda local están hechas para equipos de marketing, mientras que los responsables de cientos de ubicaciones físicas necesitan algo distinto. Ningún proyecto por sí solo habría pagado la construcción de un producto para eso. Solo se hizo visible a lo largo de varios clientes y con el tiempo. Mapboard es un patrón que no pertenecía a ningún proyecto.

Los dos caminos pueden funcionar. Fallan de maneras distintas y plantean preguntas distintas.

Cuatro pruebas

Estas son las preguntas que creemos que necesitan una respuesta clara antes de que un desarrollo para un cliente se convierta en producto. Son nuestra opinión, no un método que digamos haber aplicado a la perfección.

La primera es si el problema se repite, no solo la solución. La señal de Basecamp fue que clientes y colegas pedían la herramienta por su cuenta. En el caso de Neo, la condición detrás del problema, equipos de primera línea que se contratan todo el tiempo y se capacitan lejos de un escritorio, es común en todo el retail. Si el segundo cliente necesitaría reconstruir la mitad del sistema, lo que tienes es un servicio con pantalla de inicio de sesión, y debería cotizarse y operarse como tal.

La segunda es si la propiedad está clara antes de que alguien pronuncie la palabra producto. En México, la Ley Federal del Derecho de Autor establece dos reglas por defecto que aplican salvo que las partes acuerden otra cosa. Según el artículo 103, el software que los empleados escriben como parte de su trabajo pertenece al empleador, así que normalmente la agencia es dueña de lo que escribe su propia gente. Según el artículo 83, quien comisiona una obra es titular de sus derechos patrimoniales, así que, cuando la obra fue comisionada, la regla por defecto apunta al cliente. Cualquier transmisión de esos derechos tiene que constar por escrito. En la práctica, los contratos suelen separar lo que la agencia aportó al proyecto, como sus propias herramientas, componentes y métodos, de lo que se construyó para ese cliente, y dicen quién conserva cada cosa y qué licencia se otorga en sentido contrario. Las ideas y el conocimiento general no están protegidos por el derecho de autor, aunque las cláusulas de confidencialidad pueden limitar cómo se reutilizan. Un producto construido a partir del trabajo con un cliente se sostiene en lo que se firmó, no en quién escribió el código. Los datos son una línea aparte y más estricta, regida por la confidencialidad y la protección de datos, no por el derecho de autor. Nada de lo que un cliente compartió sobre su gente, sus procesos o sus resultados debería viajar al producto. Esta es una descripción general, no asesoría legal, y cada caso debe revisarlo un abogado.

La tercera es si alguien está dispuesto a operarlo. Un producto es una operación, no una entrega. Necesita soporte, disponibilidad, un roadmap y personas que respondan cuando se rompe. Nuestro enfoque enumera los pasos en orden: observar, prototipar, operar y luego convertir en producto. El orden importa. Neo lleva tres años en producción a escala nacional, y apenas ahora lo estamos abriendo a más operadores. Basecamp, por su parte, funcionó en un solo servidor durante su primer año. La disposición a operar llegó antes que cualquier escala.

La cuarta es si el primer cliente termina mejor. Un producto tiende hacia el cliente promedio, y el cliente detrás de la primera versión puede encontrar sus necesidades específicas compitiendo con las de todos los demás en un roadmap compartido. También hay un conflicto más silencioso. Una vez que una agencia es dueña de productos, su consejo deja de ser neutral. Cuando el problema de un cliente se parece a algo que vendemos, lo mínimo es decirlo con claridad y dejar que el cliente decida.

Cuándo no tiene sentido

A veces el valor de un desarrollo es que se ajusta muy bien a una sola operación. Generalizarlo lo empeoraría para el cliente y lo dejaría apenas promedio para todos los demás. A veces el cliente, con razón, vería un producto como su idea saliendo por la puerta. Y a veces nadie en el equipo quiere operar software durante años, lo cual es una razón legítima para seguir siendo una empresa de servicios. La mayor parte de lo que construimos para clientes cae en uno de estos casos, y sigue siendo suyo.

Los casos que tienen sentido suelen tener algo en común: el problema existía antes del proyecto, aparece en más de un lugar, la propiedad está resuelta por escrito y alguien está listo para estar de guardia. Nuestra tesis lo dice así en la última parte: los productos regresan a operaciones reales, donde los seguimos probando y mejorando. Un producto que no regresa a una operación es solo un repositorio de código con una página de ventas.