Cómo elegir una empresa de software en Argentina en 2026

Para elegir una empresa de software en Argentina, no empieces por el precio total ni por el portfolio. Primero verificá quién ejecutará el trabajo, qué significa terminar cada etapa, qué accesos y entregables conservarás, cómo se atenderán los incidentes y cómo podrías cambiar de proveedor. Después compará propuestas con la misma evidencia y recién entonces evaluá costo, plazo y afinidad.

La decisión mejora cuando deja de ser una competencia de presentaciones comerciales. Una propuesta más extensa no es necesariamente más segura; una más económica tampoco es necesariamente peor. Lo que importa es cuánta incertidumbre queda a cargo de tu organización después de leerla, entrevistar al equipo y revisar una muestra concreta de su forma de trabajo.

Esta guía mantiene ese foco: seleccionar un proveedor para un proyecto concreto, no armar un ranking de empresas. Propone una scorecard reutilizable, preguntas de verificación y una regla de decisión. Las ponderaciones son una herramienta editorial ajustable, no un estándar de mercado.

Respuesta corta: qué revisar antes de contratar

Antes de firmar, pedí evidencia sobre siete áreas:

Equipo ejecutor: nombres o roles, dedicación prevista y referente técnico.
Alcance y aceptación: entregables, exclusiones y forma de aprobar cada etapa.
Código, datos y accesos: repositorios, ambientes, credenciales y exportación de información.
Continuidad: soporte, correcciones, mantenimiento y transferencia de conocimiento.
Comunicación: responsables, frecuencia, registro de decisiones y escalamiento.
Evidencia comparable: trabajos pertinentes explicados con contexto y límites.
Operación técnica: despliegues, pruebas, respaldos, permisos y respuesta ante fallas según el riesgo del sistema.

Si una respuesta importante queda en un “lo vemos después”, registrala como incertidumbre; no la completes con una suposición favorable. Una empresa puede ser adecuada aun si no obtiene el puntaje máximo, pero no debería avanzar si no acepta condiciones básicas de control, seguridad o salida que tu proyecto necesita.

El marco Evidencia–Riesgo–Salida

El marco tiene cuatro pasos y evita que la puntuación esconda un problema crítico.

1. Definí el riesgo antes de pedir propuestas

Escribí en una página qué proceso se quiere mejorar, quién lo usa, qué sistemas debe conectar, qué datos toca, qué interrupción sería tolerable y qué fecha responde a una necesidad real. Separá tres niveles:

Crítico: una falla detiene ventas, pagos, atención u otra operación central.
Importante: una falla genera trabajo manual o demora, pero existe una alternativa temporal.
Conveniente: el impacto de postergar o fallar es acotado.

Esta clasificación no pretende medir el negocio con precisión científica. Sirve para ajustar la exigencia. Una web informativa y un sistema que organiza una operación diaria no deberían pasar por el mismo proceso de compra.

2. Convertí promesas en evidencia observable

Para cada afirmación comercial, pedí un objeto o una explicación verificable. “Trabajamos de forma ágil” puede transformarse en una muestra anonimizada de planificación y en la explicación de cómo se registra un cambio. “Entregamos calidad” puede convertirse en criterios de aceptación, estrategia de pruebas y responsable de aprobar. “El cliente es dueño” exige detallar código, cuentas, datos, documentación y componentes preexistentes.

No hace falta recibir material confidencial de terceros. El proveedor puede mostrar plantillas vacías, capturas anonimizadas, repositorios de demostración o un recorrido en vivo sin exponer información ajena. Negarse a compartir secretos es correcto; no poder explicar el método es otra cosa.

3. Aplicá filtros y después puntuá

Los filtros son condiciones de no avance. Definilos antes de conocer a los candidatos para evitar excepciones por simpatía o urgencia. Ejemplos:

no identificar quién tiene responsabilidad técnica;
no acordar acceso suficiente al código o a los datos cuando sea requisito del proyecto;
no describir qué se entrega si la relación termina;
pedir credenciales personales compartidas en lugar de accesos administrables;
no aceptar por escrito alcance, exclusiones y mecanismo de cambios.

Un filtro fallido no se compensa con una buena presentación. Si no hay fallas excluyentes, usá la matriz para ordenar diferencias.

4. Simulá la salida antes de entrar

Preguntá qué ocurriría si el proyecto se pausa después de una etapa, si cambia el responsable del cliente o si otro equipo debe continuar. La respuesta debería permitir identificar el estado del código, la documentación mínima, los datos exportables, las cuentas bajo control del cliente, los pendientes y el tiempo de transferencia.

Este paso no presupone una relación conflictiva. Diseñar la salida también mejora la continuidad ante rotación, cambios de prioridad o una incorporación futura de equipo interno.

Scorecard para comparar empresas de software

Puntuá cada criterio de 0 a 3 usando únicamente evidencia recibida:

0: no está respondido o contradice un requisito.
1: hay una promesa general, sin mecanismo suficiente.
2: hay mecanismo claro, pero quedan vacíos relevantes.
3: hay mecanismo, responsables, entregables y evidencia coherente con el proyecto.

Criterio	Peso orientativo	Evidencia a solicitar	Pregunta de verificación
Equipo ejecutor	15	Roles, dedicación, referente y reemplazos	¿Quién decide arquitectura y cuánto contacto tendremos?
Alcance y aceptación	20	Etapas, entregables, exclusiones y criterios de aprobación	¿Qué debe ocurrir para aceptar o rechazar una entrega?
Código, datos y accesos	15	Esquema de repositorios, cuentas, permisos y exportación	¿Qué podremos usar y administrar si el contrato termina?
Continuidad	15	Período posterior, canales, prioridades y transferencia	¿Quién recibe un incidente el día siguiente al lanzamiento?
Comunicación	10	Cadencia, responsables, tablero y registro de decisiones	¿Cómo veremos un desvío antes de que se vuelva urgente?
Evidencia comparable	10	Caso pertinente, muestra de proceso o referencia autorizada	¿Qué parte hicieron y qué limitación tuvo?
Operación técnica	15	Plan de pruebas, despliegue, permisos, respaldo y recuperación	¿Cómo reducen el impacto de un cambio fallido?

Para calcular el resultado, multiplicá el peso por el puntaje dividido por tres y sumá los siete valores. El máximo es 100. Conservá además una columna de “pendiente”: un número no convierte una respuesta ausente en evidencia.

No uses un umbral universal. Definí tu regla por adelantado. Una regla posible es: descartar filtros fallidos; pedir aclaración si un criterio crítico recibe 0 o 1; y usar el total solo para comparar propuestas que ya son viables. Si los puntajes quedan cerca, priorizá la diferencia en los criterios más importantes para tu caso, no la suma por sí sola.

Cómo evaluar cada criterio sin comprar etiquetas

Equipo ejecutor

“Equipo senior” es una etiqueta insuficiente. Pedí saber qué roles intervienen durante definición, desarrollo, revisión, pruebas y lanzamiento. También quién puede tomar una decisión técnica, quién conoce el proceso de negocio y qué sucede ante una ausencia.

La entrevista más útil incluye a una persona que ejecutará o supervisará el proyecto. Presentale un escenario ambiguo y observá si pregunta por usuarios, datos, excepciones, restricciones y operación. No busques una respuesta brillante e instantánea; buscá un razonamiento que haga visible lo que todavía no se sabe.

Alcance y aceptación

Dos presupuestos con el mismo título pueden incluir trabajos distintos. Para compararlos, normalizá una lista: investigación, diseño, frontend, backend, migración, integraciones, pruebas, infraestructura, capacitación, documentación y soporte. Marcá incluido, excluido o pendiente en cada propuesta.

La aceptación debe describir quién revisa, con qué criterio, dentro de qué etapa y cómo se corrige un rechazo válido. Evitá que “terminado” signifique algo distinto para compras, usuarios y desarrolladores. También pedí el proceso para cambios: quién los solicita, cómo se estima su impacto y qué decisión habilita ejecutarlos.

Código, datos y accesos

Separá propiedad contractual de control operativo. Aunque un documento hable de titularidad, todavía necesitás saber dónde vive el repositorio, quién administra los ambientes, cómo se entregan las credenciales, en qué formato salen los datos y qué componentes tienen condiciones propias.

Prepará un inventario de activos desde el inicio: repositorios, dominios, nube, base de datos, analítica, correo transaccional, certificados, tiendas de aplicaciones y documentación. No todos aplican a todos los proyectos. Los que sí aplican deben tener un dueño, administradores identificados y un mecanismo de recuperación. La revisión legal del contrato corresponde a profesionales habilitados; esta lista cubre la continuidad operativa.

Continuidad y operación

“Lanzamiento” no define quién corrige un defecto, quién observa el sistema ni cómo se prioriza una mejora. Pedí distinguir corrección de fallas, soporte a usuarios y desarrollo evolutivo. Acordá canales, horarios o límites que correspondan al impacto real, sin asumir cobertura que no figure en la propuesta.

Para sistemas importantes, solicitá un recorrido de un cambio: revisión, pruebas, aprobación, despliegue y reversión. Preguntá cómo se restringen accesos y cómo se recupera información. La profundidad debe ser proporcional al riesgo; exigir el mismo proceso para cualquier sitio puede sumar costo sin aportar valor.

Evidencia comparable

Un portfolio muestra resultados visibles, pero no necesariamente el alcance ejecutado, las restricciones ni el estado actual. Elegí uno o dos trabajos cercanos por complejidad: integraciones, tipo de usuarios, operación o restricciones, no solo por industria o apariencia.

Pedí que expliquen qué parte realizó el proveedor, qué dependía del cliente, qué decisión difícil enfrentaron y qué no resolvió la primera versión. Si ofrecen una referencia, acordá con esa persona una conversación breve y respetuosa. No pidas datos confidenciales ni interpretes una marca conocida como prueba automática de adecuación.

Ejemplo práctico localizado: dos propuestas para una pyme argentina

El siguiente caso es completamente hipotético. Una pyme de Córdoba quiere reemplazar planillas usadas para coordinar pedidos y entregas entre administración y depósito. Necesita usuarios con permisos, importación inicial, historial de cambios y una integración con su sistema actual. Clasifica la solución como importante: una caída genera trabajo manual, pero no detiene toda la empresa.

La Propuesta A ofrece construir la solución completa. Identifica un responsable comercial, pero no confirma el referente técnico. Describe módulos, aunque no incluye criterios de aceptación. El repositorio quedaría inicialmente en una cuenta del proveedor y la transferencia no está detallada. Propone coordinar soporte cuando se acerque el lanzamiento. Sí establece una reunión semanal y muestra una explicación general de un trabajo anterior.

La Propuesta B divide el trabajo en definición y construcción. Identifica roles, incluye criterios de aceptación y exclusiones, y propone repositorio y ambientes con acceso administrable por el cliente. Define una etapa de acompañamiento y un paquete de transferencia, aunque todavía debe precisar tiempos de respuesta. Presenta una muestra anonimizada de su tablero y explica un proyecto con integración, pero la evidencia sobre recuperación ante fallas queda incompleta.

Con los pesos de la tabla, el equipo comprador asigna estos puntajes hipotéticos:

Criterio	A	B
Equipo ejecutor	1	2
Alcance y aceptación	1	3
Código, datos y accesos	0	3
Continuidad	1	2
Comunicación	2	2
Evidencia comparable	1	2
Operación técnica	1	2
Total ponderado	31,7	78,3

La tabla no autoriza a contratar B automáticamente. Primero, la pyme debe verificar si el acceso al repositorio es un filtro excluyente; si lo es, A no avanza hasta corregir esa condición. Luego debe pedir a B definiciones sobre soporte y recuperación. Tampoco puede concluir qué propuesta es más conveniente sin normalizar alcance, condiciones comerciales y restricciones.

El valor del ejercicio es hacer visibles las preguntas. En vez de discutir si una presentación “dio más confianza”, el equipo puede registrar qué falta, quién debe responder y qué cambio haría viable cada opción.

Protocolo de implementación en siete pasos

Nombrá una persona responsable de la decisión. Debe consolidar preguntas y evitar que cada área negocie supuestos distintos.
Redactá el resumen de una página. Incluí objetivo, usuarios, proceso actual, integraciones, datos, restricciones, nivel de criticidad y exclusiones conocidas.
Definí filtros y ajustá pesos. Hacelo antes de recibir respuestas. Si la continuidad pesa más que la velocidad, reflejalo.
Enviá el mismo paquete a cada candidato. Permití preguntas, pero mantené una base comparable y compartí aclaraciones que cambien el alcance.
Pedí propuesta y evidencia. No solicites documentación excesiva: elegí una pieza concreta por criterio y registrá pendientes.
Hacé una reunión de verificación. Sumá a quien ejecutará, recorré un escenario de falla o cambio y anotá respuestas sin puntuar en vivo por intuición.
Cerrá condiciones y prepará el inicio. Confirmá alcance, aceptación, activos, accesos, comunicación, continuidad y salida. Después trasladá esos acuerdos al documento contractual con el asesoramiento que corresponda.

Una forma simple de operar la evaluación es una planilla con estas columnas: criterio, peso, requisito, evidencia pedida, respuesta A, puntaje A, pendiente A y equivalente para cada candidato. Agregá responsable y fecha límite a cada pendiente. Si una aclaración modifica la propuesta, pedí que quede incorporada por escrito.

Checklist de decisión final

Antes de aprobar la contratación, comprobá:

Si necesitás ordenar qué tipo de implementación corresponde antes de pedir propuestas, la página de servicios de software y automatización de Develop Argentina resume los alcances publicados para web, apps, SaaS, MVP, sistemas, integraciones, IA y automatización. Usala como referencia de categorías, no como sustituto de esta evaluación.

Limitaciones y trade-offs

Esta matriz no predice el resultado de un proyecto ni certifica la capacidad de una empresa. Evalúa la calidad y completitud de la evidencia disponible en un momento determinado. Un proveedor puede documentar bien y ejecutar mal; otro puede tener buen criterio pero presentar una propuesta incompleta. Por eso conviene combinar documentos, conversación con el equipo ejecutor y una etapa inicial acotada cuando el riesgo lo justifique.

Los pesos no provienen de estadísticas de la industria. Son una guía first-party para estructurar decisiones y deben cambiar según criticidad, madurez interna, regulación, dependencia de integraciones y capacidad del cliente para participar. Tampoco existe un puntaje mínimo válido para todos los casos.

Pedir más controles tiene un costo. Un proceso formal, documentación extensa o cobertura amplia puede ser desproporcionado para una pieza simple y temporal. En sentido inverso, ahorrar en transferencia, permisos o recuperación puede trasladar riesgo al cliente en un sistema operativo. La meta no es maximizar requisitos, sino hacerlos proporcionales.

La scorecard no reemplaza una auditoría técnica, una revisión de seguridad, una evaluación de privacidad ni asesoramiento legal, contable o regulatorio. Si el proyecto procesa información sensible, pagos o decisiones críticas, incorporá especialistas habilitados y requisitos específicos. Esta guía tampoco compara proveedores concretos ni valida credenciales, referencias, precios o plazos de terceros.

Preguntas frecuentes

¿Qué es lo primero que debo pedir a una empresa de software?

Un resumen escrito de alcance, exclusiones, equipo ejecutor, criterios de aceptación, activos que recibirás y esquema posterior al lanzamiento. Es más útil que empezar por una fecha o un precio aislado.

¿Conviene elegir la propuesta más barata?

Solo después de normalizar alcance, responsabilidades y continuidad. Si una propuesta omite tareas que otra incluye, sus totales no son comparables. Registrá también el riesgo y el trabajo que quedarán a cargo de tu equipo.

¿Cómo verifico el seniority sin tomar una prueba técnica?

Conversá con la persona que ejecutará o supervisará el trabajo. Presentá un escenario real y observá qué preguntas hace, cómo explicita supuestos y cómo relaciona decisiones técnicas con impacto operativo. Eso no prueba todo su desempeño, pero aporta más evidencia que una etiqueta.

¿Tengo que exigir que el repositorio esté en una cuenta propia?

Depende del acuerdo y del proyecto, pero el acceso, la administración, la transferencia y la recuperación deben quedar claros. Si la continuidad exige control del cliente, definilo como requisito antes de contratar, no al final.

¿Cuántas referencias debería pedir?

No hay un número universal. Una referencia pertinente y bien consultada puede aportar más que varias marcas sin contexto. Priorizá similitud en complejidad, integración, operación o restricciones, y respetá la confidencialidad.

¿Qué hago si ningún proveedor alcanza el nivel esperado?

No bajes un filtro crítico por apuro. Podés acotar el alcance, separar una etapa de definición, pedir aclaraciones o buscar otra alternativa. También revisá si tus requisitos son proporcionales y si entregaste información suficiente para responder.

¿Sirve hacer una prueba paga antes del proyecto completo?

Puede servir cuando produce un entregable útil y tiene objetivo, alcance, acceso y cierre definidos. No la trates como garantía de desempeño futuro ni pidas trabajo especulativo. Evaluá qué incertidumbre concreta debería reducir.

¿Empresa local o equipo de otro país?

La ubicación puede influir en coordinación, idioma o conocimiento del contexto, pero no reemplaza evidencia sobre ejecución y continuidad. Aplicá los mismos filtros y ajustá requisitos si necesitás presencia, horarios o conocimientos jurisdiccionales específicos.

¿Cuándo debo involucrar a un abogado o especialista en seguridad?

Antes de cerrar condiciones que afecten propiedad, datos, responsabilidades o cumplimiento, y con mayor profundidad cuanto más crítico o sensible sea el sistema. La scorecard ayuda a identificar temas; no brinda dictamen profesional.

Decisión final

Elegir una empresa de software es decidir cómo se distribuirá la incertidumbre durante meses o años. La comparación más útil no pregunta quién promete más, sino quién puede mostrar un equipo identificable, un alcance aceptable, activos controlables, una operación sostenible y una salida posible.

Definí primero tus filtros. Pedí la misma evidencia. Puntuá sin esconder pendientes. Simulá un cambio o una falla. Recién después compará condiciones comerciales. Ese orden no elimina el riesgo, pero evita que una buena reunión complete con entusiasmo lo que la propuesta todavía no demuestra.