Cómo elegir quién te hace el sistema: 7 preguntas antes de firmar

Si buscaste “empresas de desarrollo de software en Argentina” te encontraste con dos cosas: páginas de proveedores explicando por qué son buenos, y rankings de “las 10 mejores” escritos por una de las diez. Lo que no aparece en ninguna es la parte que importa: qué preguntar antes de firmar.

Nosotros somos proveedores, así que corresponde aclararlo de entrada: varias de estas preguntas nos complican a nosotros también. Las ponemos igual, porque el problema que más vemos no es que alguien elija mal por barato. Es que elige sin preguntar nada de esto y se entera a los ocho meses, cuando ya no puede volver atrás.

Antes de elegir un proveedor, elegí el tipo de proveedor

Buena parte de los proyectos que salen mal no fallan por la empresa elegida, sino por haber elegido la categoría equivocada para lo que se necesitaba. Hay cuatro tipos y hacen cosas distintas:

Nosotros somos la cuarta, y no siempre es la respuesta. Si sabés con precisión lo que querés, un estudio de desarrollo te va a salir más barato y te va a servir igual. Si lo que necesitás es facturación electrónica y libro IVA, no contrates desarrollo: comprá un ERP. Ese tema lo desarrollamos en ERP enlatado o sistema a medida.

1. ¿De quién es el código y dónde vive?

La pregunta más importante de todas y la que casi nadie hace. Pedila así de concreta: “¿el repositorio va a estar a nombre de mi empresa y voy a tener acceso desde el primer día?”

Hay tres respuestas posibles y conviene conocerlas antes:

• El código es tuyo y está en tu cuenta. Es lo que corresponde cuando pagás un desarrollo a medida.
• El código es tuyo pero está en la cuenta del proveedor. Funciona si está escrito, pero exigí una copia periódica en tu propia cuenta. “Te lo entregamos cuando termine el proyecto” no sirve: los proyectos no terminan, se discontinúan.
• El código es del proveedor y vos pagás una licencia de uso. No está mal per se —es el modelo de cualquier software de suscripción— pero entonces no estás comprando un sistema a medida: estás alquilando un producto que además pagaste desarrollar. Si te cobran el desarrollo y se quedan con el código, que al menos sea una decisión consciente y con un precio acorde.

No des por sentado que pagar el desarrollo te convierte automáticamente en titular de los derechos sobre el código: en un contrato de servicios la cesión tiene que estar escrita. Esto no es asesoramiento legal —no lo somos— pero es exactamente el punto que conviene que mire tu abogado antes de firmar, y no después.

2. ¿Qué pasa el día que nos separemos?

Es una pregunta incómoda de hacer en la primera reunión y por eso nadie la hace. Hacela igual. Un proveedor serio ya la pensó y tiene respuesta; uno que se incomoda con la pregunta te está diciendo algo.

Lo que tiene que estar por escrito, en el contrato o en un anexo:

• Entrega del código fuente completo y de todo lo necesario para desplegarlo.
• Un backup completo de la base de datos en un formato estándar, no una exportación a Excel de algunas pantallas.
• Documentación mínima: cómo se levanta el sistema, qué servicios externos usa, dónde están las credenciales.
• Un período de transición pago, con horas definidas, para que otro equipo pueda tomarlo.

El escenario que hay que evitar no es el conflicto: es el desinterés. El proveedor no desaparece, simplemente deja de priorizarte, y vos no tenés con qué irte a otro lado.

3. ¿Dónde están mis datos y quién puede leerlos?

Tu sistema va a tener adentro tus clientes, tus precios, tus márgenes y probablemente los sueldos. Preguntá cuatro cosas:

• ¿La cuenta del servidor o de la nube está a nombre de quién? Si está a nombre del proveedor y un día deja de pagarla, tu sistema se apaga y vos no podés hacer nada. Que esté a tu nombre y que el proveedor tenga acceso, no al revés.
• ¿Quién del equipo puede leer la base en producción? Que la respuesta sea “todos” es normal en un estudio chico, pero tenés derecho a saberlo y a pedir que se limite.
• ¿Cómo son los backups? Frecuencia, dónde se guardan, y la pregunta que casi nadie hace: ¿alguna vez probaron restaurar uno? Un backup que nunca se restauró no es un backup, es una carpeta.
• ¿Los datos salen del país o se usan con servicios de terceros? Especialmente si hay componentes de IA involucrados. No es necesariamente un problema, pero tenés que saberlo.

4. ¿Cómo estimás el precio y qué pasa cuando algo cambia?

Hay dos modelos y los dos tienen una trampa.

Precio cerrado. Te da previsibilidad, que es lo que querés. La trampa es que un precio cerrado sobre un alcance mal definido se resuelve siempre de la misma manera: o te cobran cada cambio como adicional, o te entregan la interpretación más barata posible de lo que estaba escrito. Ninguna de las dos es mala fe; es la única forma de que el número cierre.

Tiempo y materiales. Se adapta a los cambios, que en un proyecto real van a existir. La trampa es obvia: no sabés dónde termina.

La salida que funciona: pagar primero un relevamiento corto y acotado —una o dos semanas— del que salga un alcance escrito, y recién sobre eso pedir precio cerrado. Sale plata, sí. Sale mucho menos que un precio cerrado calculado sobre una charla de una hora. Sobre cómo poner números a esto escribimos cuánto cuesta automatizar un proceso.

Y una pregunta puntual que revela mucho: “¿cuánto me cuesta un cambio chico dentro de seis meses?” Si no hay una respuesta clara —una tarifa por hora, un bono de horas, algo— vas a descubrir el precio cuando lo necesites y no tengas alternativa.

5. ¿Quién va a venir a ver cómo trabajamos?

Un sistema a medida que se diseña sin haber visto la operación sale del escritorio del que lo diseñó. Funciona, se ve bien, y no lo usa nadie: los operarios siguen anotando en papel porque cargar en el sistema les lleva más tiempo que antes.

Preguntá concretamente: quién viene, cuántas horas, con quién va a hablar y si va a estar presente en el lugar donde ocurre el proceso. No alcanza con reunirse con vos: el que sabe cómo funciona realmente el circuito es el que lo ejecuta todos los días, y casi siempre tiene un método propio que no está escrito en ningún lado.

Si te dicen que con una reunión de dos horas alcanza para cotizar un sistema que va a atravesar tres áreas, no es agilidad: es que van a adivinar. Así trabajamos nosotros el mapeo de procesos, y es la etapa donde aparecen las cosas que nadie mencionó en la reunión inicial.

6. ¿Cuántas personas de tu equipo van a entender mi sistema?

Es la misma pregunta que te hacés sobre tu propia empresa cuando pensás qué pasa si se va tu encargado de depósito. Del lado del proveedor se aplica igual.

• ¿Cuántas personas tocaron el código? Si es una sola dentro de una empresa de veinte, estás contratando a esa persona, no a la empresa.
• ¿Está construido sobre tecnologías comunes? No necesitás entender de tecnología para evaluar esto: pedí los nombres y buscá cuántas búsquedas de empleo hay con esos términos en Argentina. Si tu sistema está hecho sobre algo que maneja muy poca gente, el día que necesites otro proveedor vas a tener un problema serio de negociación.
• ¿Queda documentado o queda en la cabeza de alguien?

7. ¿Cómo es el soporte después de la entrega?

El proyecto dura unos meses. El sistema vive años. La mayor parte de la relación con tu proveedor va a transcurrir después de la entrega, y es la parte que casi nunca se negocia.

• ¿Por dónde se pide soporte? Si la respuesta es el WhatsApp personal de alguien, funciona hasta que esa persona se va de vacaciones.
• ¿En cuánto tiempo responden si el sistema se cae un martes a las 9? Que haya un compromiso, aunque sea modesto y realista.
• ¿Qué está incluido y qué se cobra aparte? Corregir un error del sistema no debería cobrarse. Agregar una funcionalidad nueva, sí. Que la línea esté escrita.
• ¿Hay un costo mensual y qué cubre? Servidores, mantenimiento, actualizaciones de seguridad. Este número tiene que estar sobre la mesa desde el principio, porque es el que convierte un proyecto en un gasto permanente.

¿Qué señales de alerta hay que mirar?

• Te cotizan sin preguntarte casi nada. Un número rápido se siente eficiente y es la señal más confiable de que no entendieron el problema.
• No te dejan hablar con ningún cliente anterior. Pedí un teléfono, no un logo en la web. Los logos no atienden.
• El contrato no dice nada sobre el código, los datos ni la salida.
• Te prometen plazos que no incluyen tus tiempos. Buena parte de cualquier proyecto depende de que tu gente valide, pruebe y decida. Un cronograma que no reserva tiempo para eso está mal hecho desde el día uno.
• Empiezan por la tecnología. Si la primera reunión es sobre IA, blockchain o la nube y todavía no te preguntaron cómo cotizás hoy, te están vendiendo lo que tienen para vender.
• Dicen que sí a todo. Un proveedor que nunca te dice “esto no conviene hacerlo” o “esto ya lo resuelve tu ERP, no lo construyas” te va a construir todo lo que le pidas y a cobrártelo.

Las señales buenas son más aburridas: te hacen muchas preguntas incómodas, te dicen que una parte de lo que pediste no vale la pena, te muestran un alcance escrito antes de un número, y te explican qué pasa si la cosa no funciona.

¿Cómo comparo dos presupuestos que no se parecen en nada?

Es la situación normal: te llegan tres propuestas, una de USD 6.000, otra de USD 18.000 y otra de USD 40.000, y parecen hablar de proyectos distintos. Generalmente están hablando de proyectos distintos. Para compararlas, llevalas a la misma grilla:

Cuando armás esa grilla, la propuesta de USD 6.000 casi siempre resulta ser otra cosa: la misma pantalla sin integración, sin migración y sin soporte. No es que sea mala; es que no es comparable.

Las preguntas que no sirven

• “¿Qué tecnología usan?” Salvo por el punto 6 —que sea algo común—, la respuesta no te dice nada que puedas evaluar. Vas a escuchar tres siglas y asentir.
• “¿Cuántos años tienen en el mercado?” Hay estudios de dos años excelentes y empresas de veinte que hacen siempre lo mismo. Sirve más ver un proyecto parecido al tuyo que una antigüedad.
• “¿Trabajaron con empresas de mi rubro?” Ayuda, pero menos de lo que parece. Lo que importa es si trabajaron con un proceso parecido: una trazabilidad de lotes en alimentos y una trazabilidad de piezas en metalmecánica se parecen mucho más entre sí que dos empresas del mismo rubro.
• “¿Me lo pueden hacer más barato?” Siempre pueden. La pregunta correcta es “¿qué sacarías del alcance para que baje el precio?”, que te dice qué considera prescindible y te deja decidir a vos.

En resumen

Elegir bien a quién te hace el sistema tiene menos que ver con encontrar al mejor programador que con cerrar de antemano las cuatro cosas que después no se pueden arreglar: de quién es el código, dónde están los datos, cómo se sale y cuánto cuesta el día después. Lo demás —el precio, la tecnología, la antigüedad— se negocia.

Y una última cosa, que es la que más vale: contratá a alguien que te diga que no. El proveedor que te explica qué parte de lo que pediste no conviene construir te está ahorrando plata en la primera reunión, antes de facturarte un peso.