Cómo cotizar software sin morir en el intento: números, riesgo y paz mental

Son las 10:47 pm. Traes la laptop ya medio vieja, el ventilador sonando como dron y 17 pestañas abiertas: docs, WhatsApp, una hoja de cálculo y el backlog que empezaste y nunca acabaste.

El cliente manda el último mensaje del día: “¿Me lo puedes cotizar para mañana? Pero bien detallado, ¿eh? Y si se puede baratito.”

Ahí te pega esa mezcla rara: orgullo porque te están buscando… y pánico porque si te equivocas, lo pagas tú. Con noches, con estrés, con un deploy tarde a production y con tu reputación.

Cotizar software no es “adivinar horas”. Es vender claridad en un terreno donde el alcance se mueve, salen bugs y el negocio cambia de idea a media semana.

Qué vas a sacar de aquí

• Convertir “quiero una app” en un alcance cotizable sin inventarte el futuro.
• Tres formas reales de cobrar (y cuándo te conviene cada una): fixed, time & materials y por fases.
• Meter riesgo, buffers y costos invisibles sin verte gandalla.
• Un método para estimar con números defendibles (y cómo explicarlo a alguien de negocio).
• Qué escribir en la propuesta para evitar el clásico: “pero yo pensé que incluía…”.

La cotización es un contrato emocional (y si falla, truena todo)

La mayoría de pleitos no arrancan en el código. Arrancan en expectativas mal alineadas.

En México y LATAM se pone más rudo por cosas como:

• Presupuesto apretado y comparación con “mi primo lo hace en WordPress”.
• Pagos a 30/45/60 días mientras tú pagas renta, nómina o el súper.
• Cambios estilo: “ya que estamos, métele pagos, notificaciones y un panel para mi tía”.

Si cotizas bajo por miedo a perder el deal, lo ganas… pero compras un proyecto que te va a comer vivo. Si cotizas alto sin justificar, te dicen que estás caro. El punto medio es un método que se pueda defender.

Método para cotizar sin suicidarte (y sin regalarte)

1) No cotices “la app”: cotiza resultado + alcance

Antes de hablar de horas, obliga una mini definición. No es grosería: es higiene.

Checklist de discovery (15–30 min por llamada):

• ¿Objetivo de negocio? (vender, reducir soporte, controlar inventario, etc.)
• ¿Quién lo usa? (roles, permisos, frecuencia)
• ¿Qué datos entran y salen? (formularios, reportes, exportaciones)
• ¿Qué integra? (Stripe/Mercado Pago, SAT/facturación, WhatsApp, Google Sheets, ERPs)
• ¿Qué es MVP y qué va “después”? (esto salva vidas)

Tip de guerra: si el cliente no puede decir qué es “listo”, tú tampoco puedes cotizar “listo”. Pide criterios de aceptación: “Se considera entregado cuando puedo registrar X, aprobar Y y ver Z en un reporte”.

2) Elige el modelo de cobro correcto (no prometas magia)

No hay modelo perfecto. Hay modelo que te deja dormir.

A) Fixed price (precio fijo)

• Sirve cuando el alcance está muy claro y el cliente necesita certeza.
• Riesgo: si el alcance cambia, tú lo pagas.
• Regla de supervivencia: fixed solo con alcance cerrado y control de cambios.

B) Time & Materials (por hora/semana/sprint)

• Sirve cuando hay incertidumbre (casi siempre) o el producto va aprendiendo.
• Riesgo: el cliente siente “taxímetro” y se pone a la defensiva.
• Antídoto: reportes semanales, demos y backlog visible.

C) Por fases (la opción más sana para la mayoría)

• Fase 0: Descubrimiento y diseño (pagado).
• Fase 1: MVP (pagado, entregable usable).
• Fase 2: mejoras y escalamiento.
• Ventaja: negocio ve progreso y tú reduces riesgo.

Decisión práctica: si te exigen “precio cerrado” pero no hay claridad, ofrece precio fijo por fase. No por todo el universo.

3) Descompón en entregables, no en tareas sueltas

Una cotización que dice “Backend 40 hrs” no vende y tampoco protege.

Una que dice “Alta de productos + inventario + roles + auditoría básica” ya aterriza el valor.

Estructura útil por feature:

• Módulo/feature
• Qué incluye (y qué no)
• Supuestos
• Criterios de aceptación

Ejemplo de feature bien amarrada:

• Login + roles
  • Incluye: registro/invitación, reset de password, roles Admin/Operador, bloqueo por intentos.
  • No incluye: SSO corporativo (Okta/Azure AD) ni biometría.
  • Aceptación: admin puede invitar, operador solo ve pantalla X, pruebas de permisos pasan.

4) Estima con triangulación y llévalo a dinero

No te avientes una cifra “porque así se siente”. Arma una estimación defendible.

Método rápido (pero serio):

1. Para cada feature, piensa 3 escenarios: optimista, realista, pesimista.
2. Usa fórmula tipo PERT:
   • Estimación = (O + 4R + P) / 6
3. Suma todo y agrega:
   • Overhead (juntas, comunicación, reviews, deploys): 15–30%
   • Riesgo (integraciones, requisitos borrosos): 10–25%
   • Buffer de soporte post-release: 5–15%

Ejemplo mini (números inventados, lógica real):

• Catálogo + CRUD: O 12h / R 20h / P 40h → (12 + 80 + 40)/6 = 22h
• Roles + permisos: O 10 / R 18 / P 30 → 18.7h
• Integración Mercado Pago: O 14 / R 28 / P 60 → 31h
  Subtotal: 71.7h
  Overhead 20%: +14.3h → 86h
  Riesgo 15%: +12.9h → 99h
  Soporte 10%: +9.9h → 109h

Luego viene la pregunta incómoda: ¿cuánto vale tu hora?

Tarifa = (costo real + margen + impuestos + riesgo de no pago) / horas facturables

• Si eres freelance: no son 160h al mes facturables. Entre ventas, admin, follow-ups y apagar fuegos, igual y son 80–120.
• Si tienes equipo: suma nómina + herramientas + management + rotación + tiempos muertos.

Reality check mexa: si te pagan a 45 días, tu tarifa tiene que sobrevivir ese gap. Si no, te vuelves banco gratis.

5) Empaqueta como propuesta que negocio entienda

Negocio no compra “horas”. Compra: qué recibe, cuándo, cuánto le va a costar y qué pasa si cambian cosas.

Estructura recomendada:

• Resumen ejecutivo (1 párrafo sin jerga)
• Alcance por módulos (con incluye/no incluye)
• Timeline por fases (con hitos)
• Precio y forma de pago
• Supuestos y exclusiones
• Proceso de cambios (change requests)
• Garantía/soporte

Pagos que te evitan sufrir:

• 40% anticipo / 40% al entregar MVP / 20% al cierre
• O por sprints: pago semanal/quincenal por avance

Tip con colmillo: si te dicen “no damos anticipo”, tómalo como red flag. Puedes negociar: anticipo más bajo, pero entregables más chicos, o acceso limitado hasta que caiga el pago. No es castigo: es control de riesgo.

6) Control de cambios: lo que evita pleitos y burnout

La frase “solo es un cambio chiquito” ha reventado más proyectos que un bug en production.

Pon reglas simples, con workflow claro:

• Cambios se documentan en 1–2 renglones (qué cambia y por qué).
• Se estima impacto (tiempo/costo).
• Se aprueba por escrito (correo o WhatsApp, pero que quede).

Plantilla de change request (copiable):

• Cambio: ___
• Motivo: ___
• Impacto: +___ hrs / +___ semanas
• Costo adicional: $___
• Aprobado por: ___ (fecha)

7) Lo que siempre se te olvida cobrar (y luego haces de gratis)

Si no lo pones, se asume. Y si se asume, lo terminas absorbiendo tú.

Incluye explícitamente:

• Ambientes (dev/staging/prod), dominios, SSL
• Deploy (CI/CD, app stores si aplica)
• Observabilidad mínima: logs, errores, uptime
• Seguridad básica: roles, backups, rate limiting
• Documentación mínima + handoff
• Soporte post-release (ej. 2 semanas para bugs)

Caso real típico: “Es una web sencilla” → termina siendo: hosting, DNS, correos, CDN, backups, cookies banner, analytics, SEO básico, performance… y alguien tiene que sacarlo.

Screenshots sugeridos

• Captura de un backlog en Notion/Jira/Trello con módulos y criterios de aceptación.
• Ejemplo de tabla de estimación (O/R/P, PERT, overhead, riesgo).
• Pantalla de un documento de propuesta con “incluye/no incluye”.
• Ejemplo de change request aprobado por mensaje.
• Timeline por fases (Fase 0/1/2) con fechas tentativas.

Errores comunes (y cómo salir de ahí)

Error 1: Cotizar sin discovery

Síntoma: cada semana aparece una “sorpresa”.
Solución: cobra una Fase 0 (workshop + documento de alcance). Si se niegan, reduce alcance y cotiza solo lo mínimo.

Error 2: Prometer fecha sin entender integraciones

Síntoma: “Mercado Pago/SAT/WhatsApp es rápido” y luego se vuelve pantano.
Solución: pon integraciones como módulos con riesgo, sandbox, pruebas end-to-end y tiempo de soporte.

Error 3: Cobrar barato para “ganar experiencia”

Síntoma: trabajas noches, te da pena cobrar cambios, quemas tu nombre.
Solución: si necesitas portafolio, baja alcance, no precio. Un MVP más chico pero bien hecho vale más que un monstruo a medias.

Error 4: No poner exclusiones

Síntoma: “pero incluye app iOS y Android, ¿no?”
Solución: lista NO incluye con calma: “Para evitar malentendidos, esto no está considerado…”.

Error 5: Dejar pagos al final

Síntoma: entregas y luego persigues pagos como si fuera tu segundo trabajo.
Solución: pagos por hitos, anticipo y cláusula de pausa: “si no hay pago, se detiene el trabajo”.

Checklist final (para mandar una cotización con dignidad)

• Objetivo de negocio definido en 1–2 frases.
• Alcance por módulos con incluye/no incluye.
• Supuestos claros (stack, acceso a info, responsables del cliente).
• Estimación con rangos (O/R/P) + overhead + riesgo.
• Modelo de cobro elegido y explicado (fixed/T&M/fases).
• Timeline por fases con hitos y entregables.
• Plan de pagos que no te deje sin oxígeno.
• Proceso de cambios documentado.
• Soporte post-release definido (qué cubre y cuánto dura).
• Criterios de aceptación mínimos por feature crítico.

FAQ

1) ¿Conviene cobrar por hora o por proyecto?

Depende de la incertidumbre. Por hora (T&M) es más justo cuando el alcance se va a mover. Por proyecto funciona si el alcance está cerrado y tienes control de cambios.

2) ¿Cómo defiendo una tarifa “alta” frente a alguien más barato?

Con entregables claros, proceso, mitigación de riesgos y soporte. Lo barato suele esconder costos: retrabajo, bugs en producción, cero documentación y dependencias eternas.

3) ¿Qué hago si el cliente insiste en “precio cerrado” pero no define nada?

Ofrece precio fijo por Fase 0 y después cotizas el MVP con más precisión. Si aun así no, cotiza un MVP ultra acotado con exclusiones fuertes.

4) ¿Cuánto “buffer” es normal agregar?

Overhead 15–30% es común. Riesgo 10–25% según integraciones y claridad. Si te da pena, no lo llames buffer: sepáralo como gestión, QA, deploy, soporte.

5) ¿Cómo evito que me pidan cambios gratis todo el tiempo?

Con change requests y una frase estándar: “Claro, lo metemos. Te confirmo impacto en tiempo/costo y lo aprobamos antes de moverlo.”

Siguiente episodio

El día que ya cotizaste y ganaste… empieza el verdadero juego: cómo negociar alcance y decir “no” sin perder al cliente.

Scripts, límites y tácticas para que tu workflow no se convierta en telenovela en production y para que un rollback no sea tu plan de negocios.