Contratar desarrollo cuando no sos técnico tiene un problema de fondo: no podés evaluar el producto que estás comprando. Vas a ver pantallas, y las pantallas se ven bien tanto en un sistema sano como en uno que se va a caer a pedazos.
La buena noticia es que no hace falta leer código. Alcanza con hacer las preguntas correctas y escuchar cómo te responden.
1. "¿De quién es el código?"
Es la primera y la más importante. La respuesta tiene que ser: tuyo, sin vueltas.
Pedí acceso al repositorio desde el día uno, aunque no lo vayas a abrir nunca. No para controlar: para que exista. Si el código vive sólo en la máquina de alguien, o en una cuenta a la que no entrás, no tenés un sistema: tenés una dependencia.
Una señal de alarma: que te digan que lo van a entregar "cuando esté terminado". El código se entrega desde el primer día y crece a la vista.
2. "¿Qué pasa si mañana se van?"
No es desconfianza, es continuidad. Un proveedor serio ya pensó en esto.
Lo que querés escuchar: que hay documentación de cómo se levanta el proyecto, que las claves y accesos están en algún lado que vos controlás, y que otro equipo podría tomarlo. Lo que no querés escuchar: "no te preocupes, no nos vamos a ir".
Una prueba concreta y muy reveladora: pediles que te expliquen cómo haría otro equipo para levantar el proyecto de cero. Si la respuesta es larga, oral y llena de "y también hay que...", esa es tu respuesta.
3. "¿Cómo sabemos que anda?"
Preguntá cómo se prueba lo que hacen. No te van a poder mentir mucho, porque la diferencia entre "lo probamos a mano antes de subir" y "hay pruebas automáticas" es enorme.
Ninguna de las dos está mal per se: un proyecto chico y estable puede vivir con pruebas manuales. Pero si te dicen que hay pruebas automáticas, pedí ver que corran. Es un minuto y te dice mucho.
4. "¿Dónde están mis datos y quién puede verlos?"
Especialmente si manejás datos de clientes.
Preguntá dónde está la base, quién tiene acceso, cada cuánto hay backup y —esta es la clave— si alguna vez probaron restaurar uno. Un backup que nunca se restauró no es un backup: es una carpeta.
Es una pregunta simple y la cara que ponen ya te dice bastante.
5. "¿Qué pasa cuando se rompe un domingo?"
Todo software falla. Lo que distingue a un proveedor no es prometerte que no va a pasar, es tener una respuesta clara de qué ocurre cuando pasa.
¿Se enteran solos o me entero yo por un cliente enojado? ¿Hay alguien? ¿En cuánto tiempo? Si la respuesta es "avisanos por WhatsApp y lo vemos", está bien siempre y cuando lo sepas de antemano y sea acorde a lo que pagás.
6. "¿Por qué esto y no lo otro?"
Preguntá por qué eligieron las tecnologías que eligieron. No para juzgar la respuesta técnica, sino para escuchar si hay una razón.
Una buena respuesta menciona tu caso: el volumen que esperás, el equipo que lo va a mantener, lo que ya tenés funcionando. Una mala respuesta menciona sólo la tecnología: que es moderna, que es rápida, que es lo que se usa.
Si eligieron algo porque les gusta a ellos y no porque te sirve a vos, eso se va a repetir en cada decisión del proyecto.
La señal más confiable
Después de bastantes años, la señal que mejor funciona no es ninguna de las anteriores: es si alguna vez te dicen que no.
Un proveedor que a todo lo que pedís responde "sí, se puede", te está diciendo lo que querés escuchar. Uno que a veces te dice "eso se puede pero no conviene, y te explico por qué" está pensando en tu problema y no en la factura.
Lo mismo con los plazos. El que promete la mitad de tiempo que los demás no es más rápido: es el que todavía no pensó el problema.
Si estás por encarar un proyecto y querés una segunda opinión sobre lo que te están proponiendo, escribinos. A veces la mejor recomendación que damos es que no lo hagas.
