Contrato de desarrollo de software: qué acordar antes de pagar
Qué acordar en un contrato de desarrollo de software: entregables, aceptación, pagos, derechos y soporte para arrancar sin expectativas cruzadas.
Un contrato de desarrollo de software debería ayudarte a responder algo sencillo antes de pagar: ¿qué vamos a construir y cómo sabremos que quedó listo? Si necesitas interpretar cada párrafo como una adivinanza, todavía falta trabajo.
El problema aparece cuando "plataforma completa" significa una cosa para el founder y otra para quien programa. Después llegan las diferencias sobre pagos, accesos y cambios. Conviene resolverlas con ejemplos antes de arrancar, no cuando ambos equipos ya están cansados.
Esta es una guía operativa para conversar con tu proveedor. Las cláusulas legales y su validez necesitan revisión de un abogado según tu proyecto y jurisdicción.
Describe una operación, no solamente un módulo
"Incluye inventario" cabe en una cotización. También puede esconder semanas de supuestos. ¿Habrá una sucursal o varias? ¿Quién puede ajustar existencias? ¿Qué ocurre si dos personas venden la última pieza?
Imagina un distribuidor que necesita registrar pedidos. Un entregable concreto sería que un vendedor autorizado pueda crear un pedido con productos disponibles y que el sistema reserve esas unidades. Cancelarlo debe liberar la reserva. Si además quieres facturación automática, hay que acordarla; no aparece por poner "ventas" en el documento.
El contrato puede remitir a un anexo con esos flujos, sus límites y la versión aprobada. Para preparar esa conversación sirve definir el alcance antes de pedir cotización. El anexo debe poder cambiar, pero cada cambio necesita quedar identificado.
Aterriza la entrega y la aceptación
Una demostración por videollamada no equivale a una entrega aceptada. Acuerden dónde se prueba, con qué datos, quién revisa y cuánto tiempo tendrá para responder. También qué evidencia confirma el resultado y cómo se registran los pendientes.
En el ejemplo del distribuidor, probarían un pedido con existencias suficientes y otro sin ellas. Luego cancelarían el primero y revisarían que el inventario se recupere. Es mucho más útil que escribir "el módulo deberá funcionar correctamente".
Distingue un defecto respecto al comportamiento acordado de una capacidad nueva. Si la cancelación debía liberar unidades y no lo hace, hay un incumplimiento del criterio. Agregar autorizaciones por monto puede ser otro alcance. Documentar la diferencia evita negociar desde el enojo cada viernes.
El esquema de pago depende del trabajo
Un contrato de desarrollo de software debe decir cuánto se paga, cuándo y contra qué condición. Para un proyecto grande pueden servir hitos verificables. Un ajuste pequeño sobre una plataforma existente puede contratarse con pago completo por adelantado. Ningún esquema sustituye un alcance claro.
Revisa qué sucede si falta información del cliente, si una integración externa se retrasa o si hay una factura vencida. Definan cómo se avisa una pausa y cómo se recalcula el calendario. Una fecha que depende de recibir un catálogo no debería presentarse como incondicional.
Pide que cada cambio indique su costo y efecto en la fecha antes de autorizarlo. Un mensaje de "sí, agrégalo" sin ese contexto deja demasiado espacio para una sorpresa.
Tener acceso al repositorio no resuelve la propiedad
Separen la entrega técnica de los derechos sobre el trabajo. El documento debe precisar qué código se entrega, qué uso puedes darle y qué cesiones o licencias corresponden. Pagar una factura o recibir una carpeta no es una explicación suficiente de esos derechos.
También hay componentes de terceros, suscripciones y herramientas previas del proveedor. Solicita que se identifiquen las dependencias relevantes y sus condiciones de uso. No tiene sentido prometerte propiedad exclusiva sobre una librería que se distribuye con su propia licencia.
Acuerden quién administra el dominio, hosting y servicios de pago, además de cómo recibirás los accesos. La entrega al cierre del proyecto debe permitir continuar la operación sin depender de una contraseña personal del desarrollador.
Define qué pasa después del lanzamiento
"Incluye soporte" puede significar corregir defectos o atender solicitudes nuevas. Pongan duración, cobertura, canal y horario. Distingan tiempo de respuesta de tiempo de resolución: confirmar que llegó un reporte no significa haberlo corregido.
Aclaren quién paga infraestructura y servicios externos. Si existe mantenimiento, especifiquen qué tareas cubre. Si no existe, acuerden cómo se pedirán cambios después. También conviene definir qué se entrega si el proyecto termina antes de lo previsto y cómo se calcula el trabajo pendiente de pago.
Firma cuando puedas explicar lo que compras
Antes de aprobar un contrato de desarrollo de software, intenta contarle a otra persona qué recibirás, cómo lo revisarás y qué quedará fuera. Si solo puedes repetir "una app completa", falta precisión.
En DevAces preferimos tener esa conversación antes de empezar. Si ya tienes una propuesta y necesitas aterrizar el alcance técnico, cuéntanos qué quieres construir. Mejor aclarar una duda hoy que discutir una expectativa cuando el código ya está hecho.