Cómo cotizamos un software a medida

Antes de dar un número, necesitamos cuatro insumos. No son burocracia: son las cuatro preguntas cuya ausencia convierte cualquier precio en un chiste con firma. Si algo no lo sabes, dilo: un alcance que declara “esto no está definido” vale más que uno que finge saberlo.

Con eso, la primera respuesta útil no es un precio: es un borrador de alcance para revisarlo juntos. El precio llega al final del documento, nunca al inicio. Los rangos públicos de referencia están en cuánto cuesta un software a medida en Lima.

• El proceso a digitalizar, con sus excepciones reales (no las del manual, las de la práctica).
• Los sistemas actuales: qué se usa hoy, aunque sea Excel, WhatsApp o un software olvidado.
• Plazo objetivo y fecha fija si existe (cierre, temporada, inversión).
• Rango de presupuesto en soles: sin piso, no hay forma de recortar con criterio.
• Quién decide: un dueño de producto con facultad de aprobar, no un comité.

El documento de alcance es el núcleo de cualquier cotización. Para una empresa de desarrollo de software, estructurar el desarrollo de sistemas requiere transparencia. Un alcance serio de Bytes tiene entre 3 y 10 páginas y responde siempre las mismas seis preguntas, con nombre propio y sin ambigüedad:

La sección de “fuera de alcance” es la más valiosa del documento y la que los clientes agradecen tarde: es lo que evita el “pensé que también incluía”. Si un proveedor no te muestra un alcance escrito antes de darte precio, no está cotizando un proyecto: está pujando.

Lo que casi nunca trae un mal documento de alcance —y lo que nos toca discutir en cada revisión— es lo invisible: dónde van a vivir las credenciales de las integraciones, quién administra los ambientes de prueba, qué se hace con los datos cuando el proyecto se detiene, y quién responde un sábado cuando la emisión se cae. Un alcance que no menciona esos cuatro puntos no es un alcance de tres páginas: es una lista de deseos.

• Qué se construye: módulos, pantallas y reglas de negocio, por escrito.
• Qué no se construye: el fuera de alcance explícito.
• Con qué se integra: sistemas de terceros, credenciales y ambiente de prueba de cada uno.
• Dónde corre: nube, dominio, bases de datos, respaldos, costos de licencias.
• Cómo se prueba: criterios de aceptación por módulo y quién los firma.
• Qué significa “terminado”: la definición que desemboca el último hito.

Son tres modelos de riesgo, no tres formas de escribir el mismo número. En el proyecto cerrado el riesgo del estimado lo carga el proveedor; en las horas abiertas, lo cargas tú; por hitos, se reparte. Nosotros preferimos precio por hito (diseño, MVP, integración, salida a producción) porque ambas partes saben qué se paga, cuándo, y qué pasa si algo se mueve.

La estimación detrás de cada hito usa prácticas públicas y auditables: descomposición del alcance, puntaje por complejidad y una reserva de contingencia explícita, en lugar de un número “de panza”. La guía de estimación de Atlassian documenta el método que adaptamos.

Y una advertencia sobre el extremo barato del mercado: una tarifa por hora por debajo del costo real de un desarrollador senior en Lima no la subsidia la generosidad del proveedor; la subsidia tu proyecto, con juniors sin supervisión o con el abandono en el mes cuatro. En Perú es legal y común contratar equipos remotos de bajo costo; lo que no existe es calidad barata sostenida en el tiempo, por más que el pitch diga lo contrario.

Toda cotización honesta tiene una letra chica. Lo profesional no es escondarla, es escribirla. Un proveedor serio debe declarar: las supuestos sobre tus datos y accesos, qué pasa si el tercero (banco, courier, operador) cambia o se cae, qué licencias y servicios se pagan aparte (nube, mapas, SMS, APIs de IA), y qué se excluye del precio de construcción.

En seguridad, el estándar mínimo debería estar explícito en el alcance, no ser un extra sorpresa: desarrollo alineado al OWASP Top 10 para aplicaciones web, gestión de accesos por rol, respaldos probados y cifrado de datos personales. Si la palabra “seguridad” no aparece en la cotización, alguien va a pagarla después, más cara.

Y una exclusión que declaramos desde el día uno y que muchos no: nosotros no asumimos el criterio contable ni tributario de tu operación. Lo integramos; lo que se decide con el contador se decide en tu mesa.

La nube se estima con calculadoras públicas antes de la primera línea de código, no con facturas sorpresa al tercer mes. Usamos la AWS Pricing Calculator con tus supuestos de usuarios concurrentes, volumen de datos y retención de backups, y el resultado va como tabla aparte en la propuesta: costo mensual estimado y qué lo hace subir.

Las licencias y servicios se listan uno por uno con su precio y su dueño: correo, SMS/WhatsApp, mapas, facturador, APIs de IA si el proyecto las lleva. Son contratos tuyos, no nuestros; esa regla evita el secuestro de proveedor que sufren las empresas que heredan sistemas sin nombre.

Si el proyecto incluye una web que debe posicionarse, el trabajo de SEO se estima contra criterios públicos de Google Search Central: estructura indexable, velocidad, contenido y datos estructurados. Lo que no entra en ese marco no es SEO, es humo; y lo que es humo no se factura.

Que cambia, cambia. Es lo único seguro de todo proyecto de software. La diferencia entre un cambio manejable y una guerra está en si el contrato define cómo se factura: cambio de alcance sin precio recalculado es deuda oculta, para ambas partes.

Nuestra regla es simple: si cambia el texto del alcance, cambia el precio y la fecha, y te lo mostramos antes de ejecutarlo. Los cambios pequeños que caben en la reserva del sprint no se recotizan; los que mueven hitos generan una adenda de media página con su nuevo número. Cero sorpresas al cierre.

Por eso preferimos partir los proyectos: un MVP o integración primero, con precio cerrado y aprendible, y el siguiente tramo con el conocimiento en la mano —y con precio— sobre lo que el primero reveló. Así el presupuesto grande se firma informado, no sobre un PowerPoint.

¿Y si el cambio no es de alcance sino de contexto? Pasa más de lo que uno cree: entra un nuevo gerente con otra prioridad, sale una norma de SUNAT que toca el diseño, o el proveedor del sistema que íbamos a integrar desaparece. Un buen contrato de hitos prevé esas tres situaciones con reglas de pausa y reanudación: qué se factura de lo avanzado, qué se conserva y cómo se retoma. Nadie puede prometer que el contexto no cambia; sí puede prometer que el cambio no se convierte en litigio.