Cuánto cuesta un software a medida en Argentina
Una guía para entender qué cambia el presupuesto, cómo comparar propuestas y qué condiciones conviene aclarar en Argentina.
Resumen
Ideas clave
- No existe un precio responsable sin definir alcance, integraciones, datos y riesgo operativo.
- Las reglas del negocio suelen pesar más que la cantidad de pantallas.
- Dos propuestas sólo son comparables cuando explicitan los mismos supuestos y exclusiones.
- En Argentina conviene aclarar moneda, impuestos, vigencia y mecanismo de ajuste.
- Un producto mínimo viable (MVP) reduce amplitud; no debería recortar seguridad, trazabilidad ni mantenibilidad básica.
La respuesta corta
Un software a medida no tiene una tarifa universal. Un portal de clientes, un sistema interno de gestión y una plataforma que procesa pagos pueden tener una cantidad parecida de pantallas y, sin embargo, exigir esfuerzos muy distintos. Lo que cambia el presupuesto son las reglas, los datos, las integraciones, el nivel de continuidad y el riesgo que asume la operación.
Por eso, un número aislado sirve poco. Antes de cotizar hay que acordar qué problema se resuelve, quién usa la solución, qué parte entra en la primera versión y qué queda afuera. Una propuesta seria no oculta esa incertidumbre: la reduce y deja por escrito los supuestos.
Primero se define el problema y la primera versión
El punto de partida no debería ser una lista de funciones. Conviene describir el proceso actual, dónde se pierde tiempo, qué errores se repiten y cuál sería una mejora observable. Después se identifica el flujo principal: la secuencia mínima que debe funcionar de punta a punta para producir valor.
También hay que definir usuarios, permisos, datos de entrada, resultado esperado, restricciones técnicas y situaciones excepcionales. Una primera versión puede resolver un solo flujo y un solo tipo de usuario. Eso es distinto de construir una demo descartable o dejar decisiones importantes para después.
Los factores que más cambian el presupuesto
La siguiente tabla sirve para ordenar una conversación inicial. No reemplaza un relevamiento, pero ayuda a detectar por qué dos pedidos que suenan parecidos pueden terminar en alcances diferentes.
| Factor | Qué conviene definir |
|---|---|
| Reglas y permisos | Roles, aprobaciones, estados, cálculos y excepciones. |
| Integraciones | APIs disponibles, límites, errores, reintentos y responsables externos. |
| Datos | Origen, volumen, calidad, migración, duplicados e historial necesario. |
| Experiencia | Dispositivos, accesibilidad, flujos críticos y nivel de validación. |
| Seguridad | Tipo de información, permisos, auditoría, backups y recuperación. |
| Continuidad | Horarios de uso, impacto de una caída, soporte y monitoreo. |
| Pruebas y ambientes | Datos de prueba, homologación, aceptación y salida a producción. |
La cantidad de pantallas puede orientar el trabajo de interfaz, pero no explica por sí sola la complejidad. Una pantalla con reglas de crédito, permisos y sincronización contable puede demandar más trabajo que varias vistas informativas.
Ejemplo hipotético: una distribuidora argentina
Supongamos que una distribuidora recibe pedidos por WhatsApp y correo. El equipo consulta una lista de precios, revisa el límite de cada cliente, confirma disponibilidad y vuelve a cargar la información en una planilla. El problema no es solamente crear un formulario: hay reglas comerciales, datos existentes y decisiones que deben quedar trazadas.
Precio cerrado, definición inicial o capacidad mensual
La modalidad comercial también distribuye el riesgo. No existe una opción correcta para todos los casos: depende de cuánto se conoce al comenzar y de cuánto necesita aprender el producto durante la construcción.
| Modalidad | Cuándo puede servir | Qué exige |
|---|---|---|
| Precio cerrado | Alcance estable y criterios de aceptación claros. | Supuestos, exclusiones y mecanismo de cambios por escrito. |
| Etapa de definición | Hay un problema concreto, pero faltan decisiones para cotizar la construcción. | Entregables útiles: mapa del proceso, alcance, riesgos y propuesta técnica. |
| Capacidad mensual | El producto necesita iterar y priorizar con aprendizaje continuo. | Responsable de producto, prioridades frecuentes y control del trabajo entregado. |
Qué conviene aclarar en una propuesta en Argentina
Además del alcance técnico, la propuesta debe explicar las condiciones comerciales. Esto evita que una comparación aparente oculte costos que aparecerán durante el proyecto.
- Moneda de cotización y moneda efectiva de pago.
- Impuestos incluidos o no incluidos.
- Vigencia de la propuesta y mecanismo de actualización.
- Hitos de pago y condición para iniciar cada etapa.
- Servicios de terceros facturados en moneda extranjera.
- Titularidad de hosting, dominios, cuentas, repositorios y credenciales.
- Alcance de la garantía, mantenimiento y soporte posterior.
El tratamiento impositivo y contractual depende de cada empresa. Estos puntos sirven para formular preguntas; la validación fiscal o legal corresponde a profesionales de esas áreas.
Cómo comparar dos presupuestos
Compará primero el alcance y recién después el total. Una propuesta más baja puede dejar afuera diseño, migración, pruebas, documentación o soporte. Otra puede incluir tareas que el equipo interno ya puede resolver.
- Objetivo, usuarios y flujo principal incluidos.
- Funciones y escenarios explícitamente excluidos.
- Entregables y criterios de aceptación.
- Responsables del cliente y del proveedor.
- Propiedad del código, los datos y las cuentas.
- Infraestructura, monitoreo, backups y seguridad.
- Documentación, capacitación y transferencia.
- Procedimiento para cambios y salida ordenada.
Cómo reducir inversión sin construir algo frágil
Reducir alcance funciona cuando se recorta amplitud, no calidad básica. Conviene empezar con un flujo, un tipo de usuario, una fuente principal de datos y la integración más importante. Las funciones secundarias pueden esperar si el núcleo queda preparado para evolucionar.
También ayuda que la empresa designe a una persona con capacidad de decisión, prepare ejemplos reales, depure datos y responda dudas operativas con rapidez. Muchas demoras no provienen del código, sino de decisiones que llegan tarde o se contradicen.
- Priorizá el resultado que querés verificar.
- Separá necesidad operativa de preferencia visual.
- Reutilizá servicios maduros cuando no aporten diferenciación.
- No postergues permisos, auditoría o recuperación si el proceso los necesita.
Checklist antes de pedir una propuesta
No hace falta redactar un documento técnico. Con esta información alcanza para iniciar una conversación productiva:
- Qué ocurre hoy y por qué genera un problema.
- Quiénes participan y quién toma las decisiones.
- Qué datos y herramientas ya existen.
- Qué resultado debería poder observarse.
- Qué fecha o restricción condiciona el proyecto.
- Qué parte sería valiosa en una primera versión.
- Qué riesgos no pueden aceptarse.
Nota editorial
Esta guía ofrece criterios para evaluar propuestas. No constituye una cotización ni asesoramiento fiscal o legal.
Siguiente paso