Cómo cotizar un desarrollo de software y comparar propuestas

En resumen: Para cotizar un desarrollo de software y poder comparar, envía a todos los proveedores el mismo brief escrito: problema, proceso actual, usuarios y roles, volumen de datos, integraciones, lo que no entra, plazo y criterio de éxito. Luego compara alcance, supuestos, entregables, mantenimiento y propiedad del código, no solo el precio final.

Pediste tres cotizaciones para el mismo sistema y te llegaron tres números que no se parecen en nada. Uno es el triple del otro, y el tercero no incluye lo que los otros dos sí. No es que alguien te esté tomando del pelo: lo más probable es que cada proveedor haya entendido un proyecto distinto.

¿Por qué las cotizaciones de software no se pueden comparar?

No se pueden comparar porque cada proveedor llena con sus propios supuestos lo que la solicitud no dice. Si pides "una aplicación para manejar pedidos", uno imagina dos roles y un reporte; otro, cinco roles, integración con la facturación y app para los vendedores.

Las diferencias suelen estar en estas preguntas que nadie respondió por escrito:

• ¿Cuántos usuarios y con qué permisos?
• ¿Hay que migrar datos de Excel o de otro sistema?
• ¿Se conecta con la contabilidad, la facturación electrónica o WhatsApp?
• ¿Incluye capacitación, documentación y soporte después de la entrega?
• ¿Quién paga y administra la infraestructura?

Cada respuesta distinta mueve el precio. Si no las defines tú, las define cada proveedor a su manera, y terminas comparando proyectos diferentes con el mismo nombre. Por eso el trabajo empieza antes de pedir la cotización: con un buen brief.

¿Qué debe incluir un brief de proyecto de software?

Un brief útil describe el problema y el contexto, no la solución. Estos son los ocho elementos que no deberían faltar:

1. El problema. Qué está pasando hoy y cuánto cuesta en tiempo, errores o plata. "Los pedidos se pierden entre WhatsApp y Excel" es más útil que "necesitamos un CRM".
2. El proceso actual. Cómo se hace hoy, paso a paso, con qué herramientas y quién interviene en cada paso. Si tienes el Excel o los formatos que usan, adjúntalos.
3. Usuarios y roles. Cuántas personas lo van a usar, con qué cargos y qué debe poder ver o hacer cada una.
4. Volumen de datos. Cuántos clientes, productos, pedidos al mes o documentos manejas. No hace falta precisión; basta el orden de magnitud.
5. Integraciones. Con qué herramientas debe conectarse: contabilidad, facturación electrónica, correo, WhatsApp, pasarela de pagos.
6. Lo que NO entra. Tan importante como lo que sí. Escribirlo evita que un proveedor cotice de más y otro de menos.
7. Plazo y restricciones. Si hay una fecha que importa y por qué, y cualquier restricción técnica o de presupuesto.
8. Criterio de éxito. Cómo vas a saber que el proyecto funcionó. Por ejemplo: "el informe semanal de ventas sale sin que nadie lo arme a mano".

Si tienes un presupuesto de referencia, decirlo también ayuda. No es para que te cobren eso, sino para que te propongan un alcance realista en lugar de un sistema soñado que no puedes pagar.

Plantilla de brief para cotizar software

Puedes copiar esta plantilla, llenarla en una o dos páginas y enviarla igual a todos los proveedores:

BRIEF DE PROYECTO DE SOFTWARE

1. Empresa y contexto
   - A qué se dedica la empresa y cuántas personas son.

2. Problema
   - Qué pasa hoy y cuánto nos cuesta (tiempo, errores, plata).

3. Proceso actual
   - Paso a paso, herramientas que se usan y responsables.
   - Anexos: archivos de Excel, formatos, capturas.

4. Usuarios y roles
   - Rol / número de personas / qué debe ver y hacer.

5. Volumen de datos
   - Registros actuales y crecimiento esperado.

6. Integraciones
   - Herramienta / qué información se envía o se recibe.

7. Fuera del alcance
   - Lo que este proyecto NO incluye.

8. Plazo y restricciones
   - Fecha objetivo, motivo y restricciones conocidas.

9. Criterio de éxito
   - Qué debe pasar para considerar que funcionó.

10. Lo que pedimos en la cotización
   - Alcance por módulo, supuestos, entregables, cronograma,
     costo de infraestructura y mantenimiento, propiedad del
     código y garantía.

El punto 10 es clave: le pide a cada proveedor que responda en el mismo formato, y eso hace posible la comparación.

¿Cómo leer una cotización de software?

Una cotización se lee buscando qué incluye, qué supone y qué deja por fuera, antes de mirar el precio. Revisa estos puntos en cada propuesta:

• Alcance escrito. La lista de funciones, pantallas, roles y reportes que se entregan. Si solo dice "módulo de inventario", pide el detalle.
• Entregables. Además del sistema funcionando: código fuente, documentación, manuales y capacitación.
• Supuestos. Lo que el proveedor da por hecho: "el cliente entrega los datos limpios", "máximo 20 usuarios". Un supuesto que no se cumple es un cobro adicional.
• Exclusiones. Lo que no está incluido. Compáralo con el punto 7 de tu brief.
• Cronograma y forma de pago. Si hay entregas intermedias y si los pagos están atados a ellas.
• Mantenimiento y soporte. Qué cuesta después de la entrega, qué cubre y qué tiempos de respuesta ofrece. Revisa cuánto cuesta mantener un software a medida para saber qué esperar.
• Infraestructura. Dónde va a correr el sistema, a nombre de quién y cuánto costará al mes.
• Propiedad del código y los datos. Debe decir por escrito que son tuyos. Lo explicamos en de quién es el código y cómo evitar quedar amarrado.
• Garantía. Por cuánto tiempo se corrigen errores sin costo después de la entrega.

¿Cómo comparar cotizaciones de software? Tabla de revisión

Compara criterio por criterio, no el total. Esta tabla sirve como lista de revisión; arma tu propia versión con una columna por proveedor.

Criterio	Qué preguntar	Señal de alerta
Alcance	¿Está escrito por módulo y por función?	"Sistema completo" sin detalle
Supuestos	¿Qué da por hecho el proveedor?	No menciona ninguno
Entregables	¿Incluye código, documentación y capacitación?	Solo "el sistema funcionando"
Cronograma	¿Hay entregas intermedias funcionales?	Una sola entrega al final
Forma de pago	¿Los pagos van atados a entregas?	Anticipo grande sin hitos
Mantenimiento	¿Cuánto cuesta y qué cubre?	No se menciona
Infraestructura	¿Dónde corre, a nombre de quién y cuánto al mes?	"Nosotros lo alojamos" sin más detalle
Propiedad	¿El código y los datos son del cliente?	No lo dice o queda ambiguo
Garantía	¿Cuánto tiempo y qué cubre?	Sin garantía escrita

Si después de esta revisión una cotización sigue siendo mucho más barata, pregunta qué dejó por fuera. Muchas veces la respuesta explica la diferencia completa.

¿El precio más bajo es la mejor opción?

No necesariamente. El precio más bajo suele venir con menos alcance, supuestos más optimistas o sin mantenimiento, y esas diferencias aparecen después como cobros adicionales.

Compara el costo a 12 meses, no solo el de construcción: desarrollo, infraestructura, mantenimiento y lo que tendrías que pagar por lo que quedó excluido. Si quieres entender de dónde sale cada número, revisa cuánto cuesta desarrollar software a medida.

También vale la pena mirar cómo está partido el proyecto. Una propuesta por módulos, con alcance y precio propios, te deja empezar por lo más urgente y comparar fase por fase. En CodeLess Co no publicamos precios por esa misma razón: cada proyecto se cotiza aparte, después de entender el proceso, y se divide en módulos para que elijas qué entra primero.

¿Cuándo no vale la pena pedir varias cotizaciones?

No vale la pena cuando todavía no sabes con claridad qué problema quieres resolver. Si el brief no se puede llenar, las cotizaciones que recibas van a ser tan distintas como tus respuestas vagas.

En estos casos es mejor otro camino:

• El proceso no está claro. Primero hace falta levantar cómo se trabaja de verdad. Un diagnóstico tecnológico deja claro el proceso real y qué conviene pedir, cotices con quien cotices.
• El proyecto es muy pequeño. Para un ajuste de pocas horas, el esfuerzo de comparar tres propuestas puede costar más que la diferencia de precio.
• Ya tienes un proveedor que conoce tu operación. Si el trabajo anterior salió bien, preparar el brief con el mismo rigor y negociar sobre él suele ser más eficiente.

Antes de firmar, también ayudan las preguntas antes de contratar una empresa de software: cómo trabaja, quién va a estar en el proyecto y qué pasa si algo sale mal.

La idea de fondo

Una cotización solo es tan buena como la solicitud que la originó. Si todos los proveedores reciben el mismo brief y responden en el mismo formato, la comparación se vuelve simple y la decisión deja de ser una apuesta.

Si quieres, revisamos contigo qué debería decir el brief de tu proyecto. La primera conversación es gratis: cuéntanos qué te está costando tiempo.

Preguntas frecuentes

¿Cuántas cotizaciones de software debo pedir?

Con dos o tres cotizaciones suele bastar para tener referencia, siempre que todas partan del mismo brief escrito. Pedir más aumenta el trabajo de comparar sin mejorar mucho la decisión. Más que el número de propuestas, importa que respondan en el mismo formato: alcance por módulo, supuestos, entregables, cronograma, mantenimiento, propiedad del código y garantía.

¿Qué es un documento de requerimientos de software?

Es un documento que describe qué debe hacer un sistema: procesos que cubre, usuarios y roles, reglas de negocio, reportes e integraciones. Es más detallado que un brief y suele construirse junto con el proveedor, a partir de reuniones y del proceso real. El brief sirve para pedir cotizaciones; los requerimientos detallados sirven para construir sin malentendidos.

¿Es normal cobrar por el levantamiento de requerimientos?

Sí, en proyectos medianos o grandes es habitual que el levantamiento detallado se cobre, porque requiere varias sesiones de trabajo y deja un documento útil aunque cambies de proveedor. Una primera conversación para entender el problema, en cambio, suele ser gratuita. Lo importante es que quede claro desde el inicio qué se cobra y qué recibes a cambio.

¿Qué garantía debe tener un desarrollo de software?

Una garantía razonable cubre la corrección de errores del sistema, sin costo, durante un periodo definido después de la entrega. Debe quedar por escrito cuánto dura, qué se considera error y qué se considera una función nueva, porque esto último normalmente se cobra aparte. La garantía no reemplaza un plan de mantenimiento.