Primero, un hecho tranquilizador y comprobable: una aplicación generada fija sus dependencias a la versión EXACTA, Next, React, Prisma y el resto quedan anclados al número concreto, no a un rango. Por tanto, se reinstala idénticamente dentro de dos años y no se rompe por sí sola. los parches de seguridad de las bibliotecas, el alojamiento y las evoluciones funcionales derivadas de su actividad Mientras la aplicación siga funcionando en la URL incluida, los dos primeros no le suponen ningún coste; el día en que usted la aloje en su propio servidor o modifique su código, pasa a ser un software como cualquier otro, y como el código es Next.js y Prisma estándar, de su propiedad, cualquier desarrollador puede hacerse cargo de él.
Una aplicación que funciona no se degrada por sí sola
La intuición sugiere que el software «envejece» y acaba fallando solo. Pero eso no es lo que ocurre. El archivo `package.json` de una aplicación generada fija cada dependencia a su versión EXACTA, sin rangos, sin «última versión compatible»: el número concreto. Reinstalar la aplicación dentro de dos años reconstruye exactamente el mismo árbol de bibliotecas que el del primer día, y el código, por su parte, no ha cambiado ni un solo byte.
Lo que sí se degrada es el entorno que la rodea: el certificado que expira, el servidor que se migra, la versión de Node que un proveedor de alojamiento retira y, sobre todo, los parches de seguridad que ya no reciben las versiones fijadas. Esta diferencia cualitativa respecto a «el software se rompe» cambia por completo lo que hay que planificar.
Tres tipos de mantenimiento distintos, que solemos confundir
El primero es la SEGURIDAD de las bibliotecas: cuando se descubre una vulnerabilidad en una dependencia, eso implica una actualización de su versión. Es el único mantenimiento que sigue un reloj interno y no depende de su actividad empresarial.
El segundo es el ALOJAMIENTO: el dominio, el certificad, la base de datos, las copias de seguridad. Mientras la aplicación se sirva desde la URL incluida, esa responsabilidad recae en la plataforma; además, esta es la pregunta precisa que conviene plantear, tanto aquí como ante cualquier otro proveedor: ¿cuál es su política de copias de seguridad y con qué frecuencia se realizan? El día en que traslade la aplicación a su propio servidor, esta responsabilidad pasa íntegramente a usted.
El tercero no es mantenimiento, sino TRABAJO: añadir un campo, un estado o una pantalla porque su actividad operativa ha cambiado. Esto solo ocurre si usted lo solicita, y se gestiona según su propia escala, es precisamente el tema del guía «hacer evolucionar su aplicación».
¿Quién puede hacerlo y por qué nadie le tiene atado?
El código es Next.js y Prisma estándar, exportable como archivo ZIP o subible a GitHub, y le pertenece íntegramente. No contiene extensiones propietarias ni formatos que solo el editor pueda interpretar: el desarrollador que asuma el proyecto trabaja con las herramientas que ya conoce, y eso es lo que permite una transición fluida sin necesidad de nuestra intervención. Es justo lo opuesto a una herramienta cerrada, donde la pregunta «¿quién la mantendrá?» solo tiene una respuesta: el editor, mientras siga existiendo.
El contrapeso es honesto: el día en que usted modifique ese código personalmente, la versión en producción dejará de ser la que la plataforma sabe regenerar. Gana libertad total, pero asume también la responsabilidad del mantenimiento. Muchas pequeñas organizaciones nunca dan ese paso, y no lo necesitan, pero la puerta permanece abierta, y eso es lo que importa cuando llegue el momento de cruzarla.
Qué hay que presupuestar realmente
En el caso de software a medida, la literatura del sector sitúa el mantenimiento correctivo en torno al 15-20 % del coste inicial anual, y el conjunto de mantenimiento más evoluciones en aproximadamente la mitad del coste total de propiedad durante cinco años. Es una partida que casi nadie presupuesta, y que convierte un proyecto exitoso en una herramienta abandonada tres años después.
El cálculo cambia cuando el coste inicial es reducido y el alojamiento está incluido: no hay que reservar nada mientras la aplicación funcione tal como está. El gasto reaparece únicamente en dos escenarios: si usted traslada el alojamiento a sus propios servidores o si encarga modificaciones en el código. Decidir con esos dos caminos claros ante usted es mucho más sensato que pagar un seguro contra una avería que, con versiones fijadas, simplemente no ocurre.