Propiedad del código
El código fuente, los repositorios y la documentación son de la empresa que paga. Debe decirlo el contrato, y el acceso debe existir desde la primera semana, no al final.
Casi todos los proyectos de software que fracasan lo hacen por razones que se podían ver en la primera reunión. No por la tecnología: por acuerdos que nadie escribió, por alcances que nadie cerró y por preguntas que nadie hizo. Esta guía reúne las que conviene hacer, incluso (sobre todo) si vas a contratar a alguien más.
Ninguna de estas exigencias es agresiva ni desconfiada. Un proveedor serio ya las tiene resueltas y las va a poner por escrito sin resistencia.
El código fuente, los repositorios y la documentación son de la empresa que paga. Debe decirlo el contrato, y el acceso debe existir desde la primera semana, no al final.
El dominio, la cuenta de nube, las bases de datos y las llaves de servicios de terceros van a nombre de la empresa. Que el proveedor los administre está bien; que los posea, no.
Un documento que diga qué se entrega, qué no, y qué se considera un cambio. Sin eso, cada desacuerdo se resuelve por quién insiste más.
Cómo se sabe que una fase está terminada. «Que funcione» no es un criterio; «un usuario con rol de cajero puede cerrar caja y el reporte cuadra con las ventas del día» sí lo es.
Un período en el que los defectos de lo entregado se corrigen sin costo. Distinto del mantenimiento, que son mejoras y cambios nuevos.
Cómo se entrega todo si la relación se acaba: código, datos exportados, credenciales y documentación. Acordarlo al inicio, cuando todos están de buen ánimo, es lo que evita un conflicto después.
¿Quién va a trabajar en esto y a qué dedicación? ¿Qué pasa si esa persona se va? ¿Quién responde si algo se rompe un viernes a las seis de la tarde? Muchas empresas venden con su mejor gente y ejecutan con la que está libre.
¿Cuándo voy a ver algo funcionando por primera vez? ¿Cómo se prueba antes de llegar a producción? ¿Con qué frecuencia vamos a hablar? Si la primera demostración es al final, el riesgo es entero suyo.
¿Qué sistemas suyos están hoy en producción y puedo hablar con esos clientes? Un portafolio de capturas de pantalla no dice nada; un cliente que contesta el teléfono, todo.
¿Qué parte de esto no harían y por qué? Un proveedor que dice que sí a todo, incluido lo que está fuera de su especialidad, es un riesgo. La respuesta más valiosa de una reunión de ventas suele ser un «eso no lo hacemos nosotros».
¿Cuánto cuesta mantener esto al año? ¿Qué incluye? ¿Qué pasa si quiero que lo mantenga otro equipo? Un sistema entregado sin plan de mantenimiento se degrada solo.
Un plazo dado en la primera reunión, sin haber visto la operación, no es un compromiso: es una técnica de cierre. Después se cumple recortando lo que no se ve.
Cualquier justificación para no dar acceso al repositorio («es nuestra metodología», «lo entregamos al final») es una forma de asegurar dependencia.
Un anticipo razonable es normal. El pago total antes de ver algo funcionando traslada el riesgo completo al cliente.
Si en la primera reunión hablaron ellos el 80 % del tiempo, van a construir lo que imaginaron, no lo que la operación necesita.
La presión por firmar hoy con un precio que vence mañana rara vez acompaña a un trabajo cuidadoso.
Quien no habla de qué pasa después de la entrega es porque no piensa estar ahí después de la entrega.
Publicar una lista de preguntas incómodas y no responderlas sería absurdo, así que aquí están nuestras respuestas: el código, los repositorios, los dominios y las credenciales quedan a nombre del cliente desde la primera semana. Cotizamos por fases con alcance escrito y supuestos explícitos. Hay algo funcionando en las primeras semanas, no al final.
Nuestros sistemas en producción se pueden ver y sus clientes se pueden contactar: los productos propios están publicados y en uso, y varios proyectos a medida operan hoy en clínicas, laboratorios, transporte, agro y desarrollos inmobiliarios de Guatemala y la región.
Y sobre los límites: no hacemos gestión de redes sociales ni producción audiovisual, y no vendemos infraestructura por hora. Cuando un proyecto pide eso, lo decimos y recomendamos a alguien que lo haga bien.
Depende de qué tan cerca tenga que estar el proveedor de la operación. Un proyecto que exige entender cómo trabaja el personal, visitar la bodega o coordinar con el contador se hace mucho mejor localmente y en la misma zona horaria. Un producto puramente digital puede desarrollarse desde cualquier lado.
Pida ver sistemas suyos funcionando hoy, no capturas. Pida hablar con dos clientes. Revise si el equipo tiene presencia pública verificable. Y observe si en la reunión hacen más preguntas de las que responden.
Es razonable y cualquier proveedor formal lo firmará sin problema. Tenga en cuenta que un acuerdo de confidencialidad protege información, no ideas de negocio: lo que realmente protege un proyecto es un contrato con alcance y propiedad claros.
Primero, recuperar el acceso al código y a los datos, que es lo urgente. Después evaluar qué parte de lo construido sirve. Retomar un proyecto ajeno es posible y lo hemos hecho varias veces; lo que no funciona es seguir pagando avances que nadie puede verificar.
Idealmente entre cuatro y ocho semanas, terminando con algo que alguien pueda usar de verdad. Una primera fase de seis meses sin entregas intermedias es una apuesta, no un plan.
Quién escribe los rankings que salen primero y qué tipo de proveedor te conviene.
Para saber si la propuesta que te dieron tiene sentido.
Cómo se ve un proyecto bien llevado, paso por paso.
Qué exigirle en seguridad a quien va a tocar tus datos.
Con gusto revisamos contigo la propuesta que tengas sobre la mesa, aunque no sea nuestra. Una segunda lectura antes de firmar cuesta una conversación y ahorra meses.
¿Prefieres hablarlo antes de escribir nada?
Agendar consultorio gratisMedia hora para desarmar el proceso que te cuesta horas. Cinco espacios al mes.