Más allá del precio y el plazo
La mayoría de los contratos de desarrollo de software se enfocan en dos cosas: cuánto cuesta y cuándo se entrega. Eso es insuficiente — ya sea que estés firmando tu primer contrato o que vengas de una experiencia donde las cosas no salieron como esperabas.
Un contrato bien hecho protege ambas partes y reduce la zona de ambigüedad, que es donde nacen los conflictos.
Lo que SÍ debería incluir
1. Definición de "terminado"
¿Cuándo una tarea está "terminada"? No cuando el dev dice que ya. Cuando cumple criterios de aceptación verificables y pasa calidad automatizada.
Tu contrato debería especificar que "entrega" significa: código que pasa CI, que cumple criterios medibles, y que tiene evidencia auditable. Si es tu primer proyecto, esto es exactamente lo que deberías exigir desde el día uno. Si ya pasaste por un proyecto donde "terminado" era subjetivo, sabes por qué importa.
2. Propiedad del código
El código es tuyo. El repositorio es tuyo. Los accesos son tuyos. Si tu proveedor desaparece mañana, deberías poder continuar con otro equipo sin perder nada.
Exige: acceso completo al repositorio desde el día 1, no al final del proyecto.
3. Proceso de verificación
¿Cómo se verifica que lo entregado funciona? El contrato debería especificar:
- Tests automatizados obligatorios
- Pipeline de CI/CD activo
- Criterios de aceptación por tarea
- Proceso de aprobación de entregas
4. Comunicación y visibilidad
¿Cómo te enteras del progreso? No "reuniones semanales" — acceso directo a un dashboard con estado real. Milestones, tareas, pipeline, horas.
5. Manejo de cambios
Los requerimientos cambian. Eso es normal. Lo que no es normal es que cada cambio se convierta en una negociación hostil. Define: cómo se documentan cambios, cómo se estiman, y quién aprueba.
6. Cláusula de salida
Si algo no funciona, ambas partes deberían poder terminar la relación de manera ordenada. Define: entrega del código, documentación, handoff, y período de transición.
Lo que NO debería importarte tanto
- Número de horas — importa más lo que se entrega que cuántas horas tomó
- Tamaño del equipo — un dev senior con proceso vale más que 5 juniors sin sistema
- Tecnología específica — lo que importa es que haya proceso, no que usen React o Vue
La pregunta clave
Antes de firmar, pregunta: "Si algo sale mal, ¿cómo me entero? ¿Y cómo se arregla?"
Si la respuesta es clara y específica, vas por buen camino. Si es vaga, reconsidera.