Contratar software a la medida: ocho preguntas antes de firmar

Cuando una empresa cotiza software a la medida suele comparar tres cosas: el precio, el plazo y qué tan bien presentada llegó la propuesta. Ninguna de las tres te dice si dentro de un año vas a tener un sistema funcionando. Y mucho menos si ese sistema va a ser tuyo.

Llevo 14 años construyendo software para empresas y te lo digo de frente: lo que define cómo termina un proyecto casi nunca está en la cifra final de la cotización. Está en lo que nadie preguntó antes de firmar.

Estas son las ocho preguntas que yo le haría a cualquier proveedor. Incluido yo.

1. ¿Quién va a escribir el código?

Parece obvia y casi nadie la hace. En muchas empresas de desarrollo, la persona que te vende no es la que diseña, y la que diseña no es la que programa. Tú explicas tu operación una vez, y esa explicación pasa por dos o tres personas antes de llegar a quien escribe la primera línea.

Pregunta con nombre propio: quién programa, cuántos años de experiencia tiene, si vas a poder hablar con esa persona y qué pasa si se va a mitad del proyecto.

No hay una respuesta única correcta. Un equipo grande puede funcionar muy bien. Lo que no funciona es no saberlo.

2. ¿De quién es el código y dónde va a vivir?

Esta es la que más caro sale cuando se omite.

En Colombia, el artículo 20 de la Ley 23 de 1982, modificado por el artículo 28 de la Ley 1450 de 2011, presume que los derechos patrimoniales de una obra hecha por encargo pasan a quien la encargó. El software cuenta como obra. Pero esa presunción tiene una condición: el contrato debe constar por escrito. Si acordaste todo de palabra o por WhatsApp, la ley no presume nada a tu favor.

No soy abogado, y un contrato de este tamaño merece que uno lo revise. Pero hay tres cosas que puedes exigir sin título de derecho:

• Que el contrato diga de forma expresa que los derechos patrimoniales del código son tuyos, y desde cuándo: con cada pago o al final.
• Que el repositorio esté a tu nombre desde el primer día. El repositorio es el lugar donde se guarda el código con todo su historial. Si vive en la cuenta del proveedor, dependes de su buena voluntad para recuperarlo.
• Que las cuentas también sean tuyas: el dominio, el servidor, la cuenta de desarrollador de Apple o Google, la pasarela de pagos. Todo a nombre de tu empresa, con el proveedor como invitado.

Pregunta también qué partes del sistema no son código nuevo. Si usa componentes propios del proveedor o licencias de terceros, necesitas saber cuáles y en qué condiciones puedes seguir usándolos.

3. ¿Qué número va a mover este proyecto?

Si el proveedor no te pregunta cuánto te cuesta hoy el proceso, no tiene forma de saber si lo que te vende vale la pena.

Te doy un ejemplo propio. Para el PNUD, el programa de Naciones Unidas para el desarrollo en Colombia, construí una plataforma de gestión de subvenciones. El número que importaba era uno: cuánto tardaba en generarse un acuerdo. Podía tardar hasta 30 días. Pasó a 2 horas. En los primeros tres meses salieron más de 200 acuerdos por la plataforma. El detalle está en el caso del PNUD.

Ese número existía antes de escribir código. Por eso se pudo medir después.

Pide que la propuesta diga qué indicador cambia, cuánto y en qué plazo. «Mejorar la eficiencia» no es un indicador.

4. ¿Qué voy a ver funcionando, y cuándo?

El peor esquema posible es el de seis meses de silencio y una entrega al final. Para cuando ves el sistema, ya está pagado y ya es tarde para corregir lo que se entendió mal.

Pregunta cada cuánto vas a recibir algo que puedas abrir y usar. No una presentación ni un informe de avance: una versión funcionando, aunque sea pequeña. Yo trabajo con entregas cada dos semanas, justo por eso. Un malentendido que se detecta en la semana dos cuesta una conversación. En el mes cinco cuesta rehacer un módulo.

Y amarra los pagos a esas entregas. Un anticipo es normal. Pagar el 80% antes de ver algo funcionando no lo es.

5. ¿Qué no está incluido?

Toda cotización tiene un alcance, y todo alcance tiene bordes. El problema es descubrirlos después.

Pide la lista de lo que queda por fuera:

• Costos mensuales de terceros. Servidor, correo transaccional, mensajes por WhatsApp, comisiones de la pasarela de pagos. No los cobra el proveedor, pero los pagas tú. Sobre uno de ellos ya escribí aparte: cuánto cuesta la API de WhatsApp Business.
• Migración de datos. Pasar lo que hoy tienes en hojas de cálculo o en otro sistema suele ser más trabajo del que parece.
• Capacitación a tu equipo.
• Cambios. Vas a pedir cambios, siempre pasa. Pregunta cómo se cotizan y quién decide si algo es un cambio o un error.

6. ¿Qué pasa el día después de la entrega?

Un sistema en producción necesita atención: actualizaciones de seguridad, copias de respaldo, alguien que mire cuando algo falla un domingo.

Pregunta cuánto tiempo corrige el proveedor los errores sin cobrar, qué cubre el soporte mensual, cuánto cuesta y en cuánto tiempo responde. Y pregunta quién se entera primero cuando el sistema se cae: ¿él o tu cliente?

7. ¿Puedo ver algo tuyo que lleve años funcionando?

Un prototipo bonito lo hace cualquiera. Lo difícil es que un sistema siga funcionando cuando ya tiene usuarios reales, datos reales y años encima.

Pide ver sistemas en producción, no maquetas. Pregunta cuánto tiempo llevan operando y cuánta gente los usa. Yo puedo mostrar un campus virtual con más de 9.000 estudiantes activos y una plataforma de turismo de la que fui cofundador y director de tecnología durante 8 años, que opera en todo el país con dos personas administrativas. Todas las plataformas de mi portafolio las construí yo solo, de principio a fin, así que respondo por cada decisión que hay adentro.

Si el proveedor solo te muestra diseños, pregúntate por qué.

8. ¿Qué pasa si dejamos de trabajar juntos?

Es la pregunta incómoda, y por eso es la mejor.

Un proveedor serio te la responde tranquilo: el código está en tu repositorio, hay documentación para que otro equipo continúe, las credenciales son tuyas y hay un periodo de transición acordado. Uno que te quiere amarrado cambia de tema.

Yo no trabajo con esquemas que te dejen atado a mí. Si un cliente se queda, que sea porque el trabajo le sirve.

Cuándo NO deberías firmar todavía

Esta parte me quita trabajo, pero es la verdad.

Si un programa que ya existe resuelve el 80% de tu proceso, empieza por ahí. Sale más barato y lo tienes funcionando en días. En otro artículo explico cómo decidir entre SaaS y software a la medida.

Si no puedes describir tu proceso en una hoja, todavía no es momento. El software no ordena una operación que nadie ha definido: la vuelve más rápida, con desorden incluido. Primero haz el inventario que propongo en cuándo dejar Excel en tu empresa.

Si nadie en tu empresa va a ser dueño del proyecto, tampoco. Alguien tiene que responder dudas, probar cada entrega y tomar decisiones. Sin esa persona, hasta el mejor proveedor construye a ciegas.

Y una más, sobre mí: si tu proyecto necesita diez desarrolladores en paralelo para salir en tres meses, yo no soy la opción. Trabajo solo. Eso es una ventaja cuando lo que importa es que una misma cabeza entienda el negocio y escriba el código, y un límite cuando lo que importa es volumen de manos. Prefiero decírtelo antes de cotizar.

Conclusión

Contratar software a la medida no se decide por la cotización más baja ni por la propuesta más bonita. Se decide por las respuestas a estas ocho preguntas: quién programa, de quién es el código, qué número cambia, qué ves y cuándo, qué queda por fuera, quién responde después, qué puede mostrar y cómo se sale.

Si un proveedor responde las ocho por escrito, vas bien, sea quien sea.

Si quieres hacerme las ocho a mí, aquí cuento cómo trabajo con empresas en Colombia y desde ahí me puedes escribir. Si después del diagnóstico la respuesta es que no necesitas construir nada, te lo digo de frente.