Toda desviación del estándar —un módulo propio, una modificación, una línea de código— es deuda técnica en potencia. No significa que no haya que personalizar: significa que hay que saber qué se está firmando.
El orden correcto para decidir
Configuración nativa primero, después Studio, después un módulo que ya exista, y solo si las tres respuestas son «no», desarrollo a medida. Desarrollamos el criterio con ejemplos en Studio o Python: cómo decidir sin hipotecar tus futuras actualizaciones; aquí nos centramos en lo que cuesta mantener la decisión una vez tomada.
El límite de Studio, que conviene conocer antes
Studio no admite Python. El cargador de módulos importables acepta únicamente ficheros .xml,
.csv y .sql, además de los recursos estáticos —JavaScript sí está permitido—. Un fichero
Python colocado ahí se ignora en silencio, con una simple línea informativa en el log. Es decir: no
falla, sencillamente no hace nada. Saberlo evita perder días buscando por qué una lógica «no se ejecuta».
Existe además una tercera vía que casi nadie considera y que resuelve muchos casos: los módulos de datos importables, hechos solo con XML y CSV. Se versionan en un repositorio como cualquier código, se despliegan en entornos en la nube y no requieren servidor propio.
Qué justifica un desarrollo a medida
Una personalización debería responder a un problema concreto: trabajo manual repetitivo, tasa alta de errores o un requisito normativo. El criterio práctico es sencillo: si no reduce errores, no ahorra tiempo de forma medible a más de una persona o no aporta un valor de negocio identificable, probablemente sea mejor dejarlo estar.
El coste que no aparece en el presupuesto
Cada personalización hay que probarla en cada versión nueva, adaptarla cuando la API cambia y mantenerla al margen de las funcionalidades del núcleo. Los sistemas muy personalizados llegan a un punto en que actualizarlos exige una revisión completa, y entonces la empresa se queda anclada en una versión antigua por miedo a migrar. Ese es el escenario que hay que evitar, y se evita en la fase de decisión, no después.
Dos hábitos que abaratan el mantenimiento
- Documentar la justificación de negocio de cada personalización, no solo su diseño técnico. Dentro de tres años, alguien tendrá que decidir si sigue mereciendo la pena mantenerla, y sin ese contexto la respuesta por defecto es «no tocar nada».
- Revisar el inventario de personalizaciones en cada upgrade y retirar las que ya no se usan. Es la única forma de que la deuda no crezca sola.