Cuando pusimos en marcha KeepFlow, nos enfrentamos a la elección a la que se enfrenta todo equipo técnico al principio: desarrollar software para clientes o desarrollar software del que seamos dueños. El camino de la agencia es el más seguro. Los clientes pagan a la entrega, los ingresos son previsibles y, cuando un proyecto se publica, se convierte en problema de otro. Elegimos deliberadamente el camino más difícil. De cada producto que hace KeepFlow somos dueños de principio a fin: lo construimos, lo operamos y convivimos con cada decisión durante todo el tiempo que exista.

Esto no es una declaración de marca. Cambia cómo funciona la ingeniería en realidad, de formas que tardamos un tiempo en apreciar del todo. Esto es lo que la propiedad hace con su forma de construir.

Cuando la relación no termina con la entrega

El rasgo que define el trabajo para clientes es que tiene un final. Se delimita un proyecto, se construye, se entrega y la relación se cierra. Lo que le ocurra a ese software después —los errores que afloran bajo carga real, las caídas de rendimiento, el parche de seguridad que nunca se aplica— pertenece ahora a otro. Uno ya ha pasado al siguiente contrato.

Ser dueño de sus productos elimina el final. No hay traspaso, no hay un momento en el que el código deje de ser su problema. Eso suena a carga, y algunos días lo es. Pero también elimina la mayor fuente de atajos que existe en el software: saber que no será usted quien lidie con las consecuencias. Cuando no hay salida, recortar por lo sano no es ahorrar tiempo: es prestarse a sí mismo un problema con intereses, y es usted quien lo devuelve.

Cada error es su error

El efecto más inmediato es sobre la responsabilidad, y no es abstracto. Cada error en un producto de KeepFlow es nuestro error. Cada regresión de rendimiento aparece en nuestras propias cifras. Cada usuario frustrado es un veredicto directo sobre un trabajo que hicimos. No hay nadie a quien pasarle el ticket.

Esto derriba un muro que la mayoría de las organizaciones de software dedican una energía enorme a mantener: el que separa a quienes escriben el software de quienes lo operan. En KeepFlow son las mismas personas. El ingeniero que construyó una función es quien la vigila en producción, quien responde cuando salta una alerta a las tres de la madrugada y quien lee lo que los usuarios dicen de ella.

Ese arreglo es incómodo por diseño, y esa es la cuestión. Cuando la persona que publica el código es la persona a la que ese código despierta de madrugada, los incentivos en torno a la calidad dejan de ser algo que haya que imponer con procesos. Nadie quiere depurar su propio atajo a las 3 de la madrugada. La presión por hacerlo bien a la primera surge de la estructura del trabajo, no de un documento de políticas.

Construir para vidas enteras, no para fechas de entrega

Los proyectos para clientes se organizan en torno a fechas de entrega. Los productos propios se organizan en torno a vidas enteras, y esa diferencia alcanza a decisiones técnicas que parecen idénticas en la superficie pero salen opuestas.

Cuando construye algo que va a operar durante años, el cálculo de casi cada elección se invierte:

  • Invierte en observabilidad desde el principio, porque es usted quien estará mirando fijamente los paneles a las 2 de la madrugada, y un sistema en cuyo interior no puede ver es un sistema que no puede operar.
  • Escribe las pruebas que tentaría saltarse bajo una fecha límite, porque será usted quien haga cambios en este código dentro de dos años, mucho después de haber olvidado cómo funciona.
  • Elige tecnología aburrida y probada antes que el emocionante framework nuevo, porque se compromete a mantener esta decisión durante muchísimo tiempo, y la novedad tiene la costumbre de convertirse en un lastre en cuanto el entusiasmo pasa de moda.

Ninguna de estas elecciones le ayuda a publicar más rápido este trimestre. Todas ellas son obviamente correctas en cuanto su horizonte temporal se mide en años en lugar de semanas. El trabajo para clientes rara vez las recompensa, porque quien hace la concesión no es quien hereda el coste. La propiedad funde a esas dos personas en una.

El bucle de retroalimentación se cierra

Hay un beneficio más sutil que tardamos más en advertir: cuando es dueño del producto, el bucle entre el problema de un usuario y su solución se acorta drásticamente, porque no hay ningún contrato interpuesto en medio.

En el trabajo de agencia, aprender algo sobre sus usuarios suele ser el comienzo de una negociación. Detecta un punto de fricción, pero actuar sobre él implica una solicitud de cambio, una conversación sobre el alcance, un nuevo pliego de trabajo, y para cuando todo eso se resuelve, la observación ya ha caducado. La economía desincentiva activamente actuar sobre lo que aprende, porque cada mejora es facturable y, por tanto, discutida.

Cuando el producto es suyo, advertir y arreglar son el mismo movimiento. Un ingeniero lee un hilo de soporte, reconoce el patrón que hay detrás de tres quejas y publica la solución esa misma tarde: sin cadena de aprobaciones, sin factura, sin debate sobre si entra en el alcance. Las personas más cercanas al problema tienen a la vez el contexto para entenderlo y la autoridad para resolverlo. A lo largo de los meses, esa acumulación de pequeñas mejoras sin bloqueos es la mayor parte de lo que separa a un producto que la gente tolera de uno en el que confía.

También cambia lo que construimos en primer lugar. Como operamos todo lo que hacemos, sentimos nuestras propias funciones ausentes antes de que un usuario llegue a reportarlas. Varias de las cosas más ingeniosas de nuestros productos empezaron como una molestia que alguno de nosotros se topó mientras gestionaba un producto distinto en el mismo equipo. Ser su propio cliente más exigente es un tipo de investigación que ningún encargo de cliente puede comprar.

No perseguir tendencias

En este sector existe la tentación de tratar lo más nuevo como lo mejor: reconstruir sobre cualquier framework en auge, perseguir el patrón de arquitectura que circula por ahí. Nos esforzamos mucho por resistirla, y la propiedad lo hace más fácil, porque sentimos el coste completo de cada tendencia que perseguimos. Una reescritura que está de moda este año es una carga de mantenimiento que arrastramos los cinco siguientes.

Lo que construimos en su lugar es infraestructura de la que los negocios dependen cada día: una atención al cliente que tiene que responder, una detección de fraude que tiene que acertar, una moderación que tiene que ser rápida, herramientas a las que la gente recurre sin pensar en lo que hay debajo. Ese tipo de software se gana la confianza despacio, a través de las virtudes aburridas: fiabilidad, consistencia, estar ahí y funcionar. Esas virtudes no vienen de la novedad. Vienen de preocuparse por algo el tiempo suficiente para hacerlo bien, y luego quedarse para mantenerlo así.

Esa es toda la razón por la que creamos nuestros propios productos. No porque sea más fácil —no lo es—, sino porque convivir con sus decisiones es la forma más fiable que conocemos de tomar buenas decisiones.