Desarrollo barato, mantenimiento caro
Pides tres presupuestos para el mismo software. Dos se mueven en cifras parecidas. El tercero cuesta bastante menos, y nadie te explica por qué. La lectura fácil es que los otros dos van sobrados de margen. A veces es así. Pero hay otra explicación más habitual: el presupuesto barato no está compitiendo por el desarrollo. Está comprando lo que viene después.
Antes de seguir, una aclaración que importa: esto no va de estafas ni de malos profesionales. Es un modelo de negocio, legal y muy extendido, y hay proveedores que lo practican entregando software que funciona. Nosotros lo conocemos desde el lado incómodo: en Vettra hemos estado en el lado del cliente de un desarrollo contratado así. Este artículo es esa experiencia convertida en criterio: qué mirar en una propuesta para saber qué modelo tienes delante.
Dónde se recupera la diferencia
El desarrollo inicial se cobra ajustado, a veces por debajo de su coste real. La diferencia se recupera después, por tres vías que tienen una cosa en común: todas son recurrentes.
La cuota de mantenimiento. Obligatoria desde la entrega, se necesite ese mes o no. No cubre evoluciones ni mejoras: cubre que el software siga encendido. En la propuesta aparece como una línea pequeña al lado del precio del proyecto; multiplicada por los años de vida del software, deja de serlo.
El hosting con margen. El proveedor contrata los servidores y te los revende dentro de la cuota. Nunca ves la factura real de la infraestructura, así que no sabes qué parte es coste y qué parte es margen. Y como está contratada a su nombre, tampoco puedes llevártela a otro sitio.
Cada cambio, facturado aparte. El precio cerrado cubre exactamente lo que se firmó. Pero el software vive: cambia el negocio, cambia una normativa, aparece una necesidad que nadie previó. Cada cambio se presupuesta por separado, a la tarifa que toque ese día. Y esa tarifa ya no compite con nadie, porque cambiar de proveedor ha dejado de ser una opción real. Enseguida vemos por qué.
Las dos condiciones que lo sostienen
Este modelo solo funciona si se cumplen dos condiciones. Las dos suelen estar en el contrato. O, más exactamente, en lo que el contrato no dice.
El código no es del cliente. El repositorio está a nombre del proveedor y el cliente no tiene acceso. Paga por usar el software, no por poseerlo. En muchos contratos la propiedad del código ni se menciona; en otros se cede "a la finalización del servicio", una finalización que el propio modelo se encarga de que no llegue nunca.
La infraestructura va a nombre del proveedor. Dominio, servidores, base de datos, copias de seguridad. Todo contratado por él, en sus cuentas. El cliente tiene un usuario para entrar en su aplicación; el proveedor tiene todo lo demás.
Ninguna de las dos condiciones se oculta. Simplemente no se mencionan, y casi nadie pregunta por ellas. Preguntarlas es gratis y es, con diferencia, lo más rentable que puedes hacer antes de firmar.
Por qué cuesta tanto salir
Con el código y la infraestructura en manos del proveedor, cambiar no es cambiar: es empezar de cero. Un equipo nuevo, sin acceso al código, no puede continuar el trabajo de nadie. Puede mirar la aplicación desde fuera y reconstruirla, que es pagar el proyecto otra vez. Y mientras tanto los datos, el dominio y los correos viven en cuentas que no controlas y cuya entrega hay que negociar con quien acabas de dejar.
Ahí se cierra el círculo. La cuota de mantenimiento ya no se compara con otras cuotas del mercado: se compara con el coste de rehacerlo todo. Contra esa alternativa, cualquier cifra parece razonable. El negocio no está en cobrar de más por cada cosa; está en que irse sea siempre más caro que quedarse. Si lo que estás valorando es un ERP a medida, esta criba importa todavía más: el sistema que quedaría atrapado no es una web, es la herramienta que lleva tu operación diaria.
Cómo lo hacemos nosotros
Lo contamos no para presumir, sino porque demuestra que el modelo contrario existe y es viable. Cuatro decisiones, tomadas precisamente porque hemos estado al otro lado:
El código y el repositorio van a tu nombre desde el primer día. No al terminar: desde la primera entrega. Si mañana quieres seguir con otro equipo, les das acceso y siguen donde lo dejamos.
La suscripción de nube va a tu nombre. Pagas el consumo directamente al proveedor de infraestructura, sin pasar por nosotros y sin margen. Ves la misma factura que vemos nosotros, céntimo a céntimo.
El mantenimiento durante la garantía cuesta cero. Seis meses después de cada entrega, corregir lo que falle es cosa nuestra. Sin cuota.
Después, el mantenimiento es opcional y sin permanencia. Si lo quieres, lo contratas. Si montas tu propio equipo o prefieres otro proveedor, te vas con todo. Porque todo era tuyo desde el principio.
Esto solo se sostiene de una manera: cobrando el desarrollo por lo que cuesta el desarrollo. Por eso nuestra tarifa está publicada en la sección de precios y no necesitamos recuperar nada por detrás.
Qué preguntar a cualquier propuesta
No hace falta ser técnico para detectar el modelo. Bastan cuatro preguntas, hechas antes de firmar: ¿de quién es el código y el repositorio, y desde cuándo? ¿A nombre de quién va la infraestructura, y quién ve la factura de la nube? ¿Qué pasa si me quiero ir el mes que viene: con qué me voy exactamente? ¿Cuánto cuesta el mantenimiento, qué incluye y es obligatorio?
Las respuestas no necesitan interpretación. Donde hay rodeos, cesiones "a la finalización" o cuotas que no se pueden desglosar, ya sabes qué modelo tienes delante. Puedes firmarlo igualmente, y es una decisión legítima si el precio inicial es lo que tu caja permite hoy: pero lo firmas sabiendo lo que compras. Si quieres estas cuatro respuestas aplicadas a tu proyecto, cuéntanoslo: las nuestras son siempre las mismas y van por escrito.