El que construye tu sistema y el que lo mantiene tienen que ser el mismo

En corto. El que construye un sistema y después lo opera toma decisiones distintas al que entrega y se va: elige lo que puede sostener un martes a la mañana, no lo que luce en la entrega. Duvaltech trabaja así, con presupuesto cerrado —el riesgo del desvío lo asume el studio— y entregas que se abren en el navegador en vez de informes de avance. No conviene si necesitás un equipo grande en paralelo o si ya tenés área de sistemas propia.

Hay una diferencia grande entre alguien que escribe un sistema y alguien que además lo tiene corriendo. No es una diferencia de experiencia ni de tecnología: es de a quién le duele después. El que se va cuando termina de construir trabaja para llegar a la entrega. El que se queda manteniéndolo trabaja para el martes a la mañana, cuando algo falla y suena el teléfono.

Este es el modelo con el que trabajo, y prefiero explicarlo con sus límites incluidos.

Un informe no se puede abrir en el navegador

Lo que se entrega es el sistema andando. No un avance del 40%, no un informe de estado, no una presentación con capturas. Una dirección web que abrís y usás, con lo que haya hasta ahora.

Suena obvio y no lo es. Cuando el entregable es un informe, el informe se puede escribir aunque el sistema no ande. Cuando lo que se entrega es el sistema funcionando, no hay dónde esconderse: o abre o no abre. Eso cambia la conversación semanal por completo, porque deja de discutirse el porcentaje de avance y se discute lo que se ve.

Tiene un efecto secundario que vale más que el primero: quien paga empieza a usar el producto mucho antes de que esté terminado, y las correcciones llegan cuando corregir todavía es barato. La mitad de las malas decisiones de producto se evitan simplemente mirando a alguien usar la versión incompleta.

Operar cambia lo que construís

Cuando sabés que vos vas a atender la falla, diseñás distinto. Es una consecuencia mecánica, no una virtud.

No dejás un proceso automático sin registro de lo que hizo, porque el día que falle vas a tener que adivinar qué pasó. No dependés de un servicio externo sin plan para cuando no responde, porque la caída te la va a contar un cliente por teléfono. No guardás las claves de cualquier manera, porque cambiarlas también te va a tocar a vos. No armás una puesta en marcha que sólo sale bien si la hacés a mano y en el orden correcto, porque en algún momento la vas a hacer apurado.

En LocalCenter eso se nota en decisiones concretas. La factura de ARCA no espera adentro de la venta: se manda aparte y se reintenta sola, porque si ARCA está caída el mostrador no puede frenar. Nadie diseña eso así en la primera versión. Se diseña así cuando ya te tocó atender esa llamada.

Presupuesto cerrado significa que el riesgo lo asumo yo

Alcance, precio y fecha antes de empezar. La consecuencia lógica es que si el trabajo lleva más horas de las estimadas, la diferencia no la paga el cliente.

Eso alinea bien los intereses, pero sólo funciona con una condición: el alcance tiene que estar realmente definido. Con un pedido difuso, el presupuesto cerrado o sale carísimo, porque hay que cubrir la incertidumbre, o termina en una discusión sobre qué estaba incluido. Por eso lo cerrado se cierra después de entender el problema, no antes, y por eso lo que entra y lo que no entra se escribe.

Qué evidencia hay de que esto funciona

Prefiero dos ejemplos propios antes que una lista de tecnologías.

LocalCenter es un sistema de gestión comercial que diseñé, construí y opero solo. Hoy tiene 9 clientes pagando, más de un año funcionando todos los días y mejoras nuevas cada semana. Ese último dato es el que importa acá: sacar una versión por semana durante un año sólo es posible si el que programa también maneja la puesta en marcha, los datos y el soporte. Cuando el trabajo pasa de un área a otra, ese ritmo se cae solo.

Sesión es un sistema clínico que construí en 5 días durante el hackathon de Anthropic × Kaszek 2025, después de ser elegido entre alrededor de 3.000 postulantes de la región. Sigue funcionando hoy. Ese caso prueba algo más acotado: que se puede llevar un producto de cero a andando en un plazo corto, en serio, sin que “andando” signifique una demo.

Ninguno de los dos prueba que este modelo sea mejor en abstracto. Prueban que sostiene ritmo, y que sostiene arranque.

Cuándo este modelo no te conviene

Acá está la parte que un folleto no incluiría.

No te conviene si necesitás varios frentes en paralelo. Una persona hace una cosa por vez. Si tenés el motor del sistema, la app del celular y un rediseño que tienen que avanzar juntos con fecha fija, necesitás un equipo: contratar a una sola persona te da exactamente lo mismo, pero uno atrás del otro.

No te conviene si el riesgo de depender de una sola persona es inaceptable para tu operación. Es un riesgo real: si el sistema es crítico y no hay nadie más que lo conozca, una enfermedad o un cambio de prioridades te deja expuesto. Se achica —todo documentado, los accesos a nombre del cliente, el código guardado en una cuenta que es suya y una puesta en marcha que cualquiera puede repetir— pero no se elimina. Si la respuesta honesta es que no podés tolerarlo, contratá un equipo o exigí desde el contrato un plan de traspaso.

No te conviene si necesitás cobertura permanente. Una persona no cubre veinticuatro horas los siete días. Si tenés esa exigencia, necesitás guardias, y las guardias necesitan gente.

No te conviene si tu organización requiere procesos formales de aprobación, trazabilidad de cada decisión y separación de responsabilidades por auditoría. Ese entorno tiene sus razones y este modelo le pelea en contra.

Y no te conviene si lo que buscás es explorar sin rumbo durante meses. El presupuesto cerrado y la entrega semanal necesitan un problema identificado. Si todavía no sabés qué querés construir, ese es otro trabajo, más corto, y hay que hacerlo primero.

Qué pedir antes de contratar a cualquiera

Independientemente de con quién trabajes, hay tres preguntas que separan bastante rápido:

1. ¿Qué puedo abrir hoy? La dirección web de algo que esa persona haya construido y que esté funcionando ahora, no una captura de pantalla.
2. ¿Quién me contesta cuando algo se rompe? Y si la respuesta pasa por un intermediario, cuánto tarda en llegar a quien puede arreglarlo.
3. ¿De quién es el código y los accesos? Si el código, el servidor y los dominios no están a tu nombre desde el primer día, no estás contratando un sistema: estás alquilando una dependencia.

Si las tres respuestas son claras, casi no importa el tamaño del proveedor. Si no lo son, tampoco importa.