Criterios para contratar a un desarrollador independiente

1. Pide una conversación sobre el negocio

Explica qué ocurre hoy, quién hace el trabajo y qué falla. La persona candidata debería preguntar por usuarios, datos, excepciones, sistemas existentes y prioridades antes de recomendar una tecnología. Si promete una solución y un precio sin entender el proceso, pide que detalle sus supuestos.

2. Revisa trabajo comparable y su aporte

Pregunta por proyectos parecidos y qué parte hizo personalmente. Una demostración o caso de estudio vale más que una lista de lenguajes. Solicita ejemplos de problemas resueltos, decisiones tomadas y resultados observables; respeta la confidencialidad de sus clientes.

3. Compara propuestas con el mismo alcance

La propuesta debe decir qué incluye, qué queda fuera, fases, fechas, precio, forma de pago y qué necesita de ti. Compara el costo total: desarrollo, hosting, licencias, mantenimiento y cambios previsibles. Una cotización barata con alcance ambiguo puede terminar costando más.

4. Define criterios de aceptación antes de pagar cada fase

Un criterio de aceptación describe una prueba observable: “un vendedor registra una venta, el inventario baja una vez y el supervisor puede verla en el reporte”. Acuerden quién ejecuta la prueba, con qué datos, cómo se reportan defectos y qué pasa si la fase no la supera. La guía contractual de OWASP muestra cómo incorporar requisitos y revisión de seguridad al acuerdo; adapta el nivel de detalle al tamaño del proyecto.

5. Aclara propiedad, accesos y continuidad

Deja por escrito quién tendrá el repositorio, dominio, hosting, base de datos, claves de publicación y documentación. Comprueba qué entregables permiten que otra persona mantenga el sistema si la relación termina. La titularidad y las licencias deben quedar pactadas expresamente; no las des por supuestas.

6. Pregunta por seguridad, pruebas y soporte

¿Cómo separa pruebas y producción? ¿Cómo maneja credenciales y respaldos? ¿Qué corrige sin costo tras la entrega y durante cuánto tiempo? ¿Cómo se reporta una urgencia? El marco SSDF de NIST ofrece un vocabulario para conversar sobre prácticas de desarrollo seguro con proveedores.

Señales de alerta y siguiente paso

• No hay alcance escrito ni forma de comprobar la entrega.
• Todas las cuentas se crean a nombre del desarrollador y no existe plan de transferencia.
• La propuesta evita hablar de datos, seguridad, respaldo o soporte.
• Hay promesas absolutas de costo, plazo o “cero errores” sin conocer el proyecto.

Antes de contratar, pide una primera fase pequeña y verificable. Para preparar la revisión final, usa esta lista de criterios de aceptación de un sistema.