El desarrollo a la medida que se rompe en la siguiente actualización

Por qué se rompe

Un desarrollo a la medida clásico vive por fuera del producto. Es código escrito para una sola empresa, que se apoya en cómo funcionaba el sistema el día que se escribió: esas pantallas, esas tablas, esos nombres. Cuando el producto cambia por dentro, y tiene que cambiar porque cambia la DIAN y cambia la ley laboral, lo que se apoyaba en la versión vieja deja de encajar.

Y como ese código existe solo en tu empresa, nadie más lo prueba. Cada actualización se prueba contra el producto, no contra tu informe. El primero que descubre que se rompió eres tú, en producción, un martes.

Las tres facturas

Cuando te cotizan un desarrollo a la medida te muestran la primera. Hay tres.

La primera, hacerlo. Es la que aparece en la cotización y la que discutes.

La segunda, mantenerlo vivo. Cada actualización mayor puede necesitar ajustarlo. No siempre. Pero cada ajuste se cotiza aparte, y conviene preguntar de entrada cuánto ha costado mantener un desarrollo parecido en otro cliente.

La tercera, la que nadie cotiza, es quedarte quieto. Es el costo de no actualizar. No llega en una factura. Llega como una lista de cosas que tu sistema no hace y que ya no se pueden agregar sin un proyecto.

La pregunta que lo detecta en dos minutos

Las dos respuestas son legítimas. Si queda en el producto general, viaja con cada actualización y lo prueban con todo lo demás; a cambio, tus competidores también lo van a tener, y para un informe, un control o un campo eso da igual. Si queda solo en tu instalación, aplican las tres facturas.

Qué pedir por escrito, si de todos modos lo vas a aceptar

Hay casos donde un desarrollo exclusivo tiene sentido. Una regla de costeo que es tuya y de nadie más, un acuerdo con un cliente grande que nadie va a repetir. Si el tuyo es uno de esos, deja escritas cinco cosas antes de aprobar la cotización, y pídelas en el mismo correo, no en la reunión.

Dónde queda

Dentro del producto general o solo en tu instalación. Es la pregunta de arriba, y va escrita porque en la reunión se contesta distinto que en un correo. Pide además el nombre de la versión del producto sobre la que se va a construir.

Quién lo mantiene compatible, y con cargo a quién

El día que salga la versión nueva, alguien tiene que revisar que tu informe siga saliendo. Pregunta si esa revisión está incluida, cada cuánto se hace y qué pasa si encuentra algo. Una respuesta útil trae un plazo en horas. Una respuesta de «lo vemos cuando pase» significa que lo vas a pagar otra vez.

Qué pasa si no puedes actualizar

Escribe la pregunta al revés, que es como duele: si por culpa de este desarrollo tu empresa se queda dos años sin actualizar, ¿quién responde por las funciones que salieron en ese tiempo y por los cambios de norma que no llegaron? Tu contador va a ser el primero en enterarse, y va a ser en enero.

Quién lo entiende además de quien lo escribió

Pide el nombre de la persona y pide dónde está documentado. Un desarrollo que solo entiende un consultor que hoy trabaja ahí es un riesgo con fecha de vencimiento desconocida. Si la documentación es «el código está comentado», no hay documentación.

De quién es el código

Es la que más cara sale. Hay empresas que descubrieron, el día que quisieron cambiar de proveedor, que lo que habían pagado durante años no se lo podían llevar. Deja escrito qué te entregan si te vas, en qué formato y en cuántos días. Cómo pedir lo que sí es tuyo está en cómo sacar tu información del sistema que usas hoy.

Que el sistema se adapte por datos, no por código

Hay otra forma de construir software, y cambia el problema de raíz. En lugar de escribir código aparte para cada cliente, lo que varía se resuelve por configuración y por datos. Se nota en tres cosas.

Cada empresa es un registro, no un despliegue. Si activar un cliente nuevo no obliga a tocar código, personalizar tampoco.

Lo nuevo nace apagado. Cada control que se agrega, por ejemplo avisar cuando una factura llega por encima del precio que acordaste, entra con un interruptor por empresa y arranca avisando antes que bloqueando. Tú decides cuándo aprieta. Entre «actualizaron el sistema y se paró la operación» y que no pase nada, ahí está la distancia.

El sistema mejora sin que te instalen nada. Los motores que aprenden de las correcciones de tu gente, la cuenta que tu contador corrige, la cantidad que tu comprador ajusta, cierran ese ciclo sin desplegar código nuevo. El sistema que tienes hoy funciona mejor en un mes porque tu gente lo usó, no porque te llegó una versión.

Así trabaja Mavox, y por eso vale la pena decir cómo se cobra acá lo que pidas, que es la otra mitad de la pregunta. Todo lo que quede pactado antes de que arranque el canon va cubierto por la implementación. Si pides algo después, ya operando, se cotiza antes de empezar con las horas escritas, y decides tú. Y cada cosa que se construye entra al producto general, así que viaja con cada actualización y no se rompe en la siguiente versión. Un desarrollo exclusivo para una sola empresa se pacta por escrito, con alcance propio, y se factura aparte. El modelo completo está en cómo cobramos.