¿Qué diferencia real hay entre una consultora de software, una fábrica y staff augmentation?
La consultora vende criterio, la fábrica vende un entregable y staff augmentation vende perfiles que trabajan bajo tu dirección. La diferencia no es el precio, es quién responde por el resultado.
Las fuentes que revisamos no establecen una definición única de estas tres etiquetas, y no son categorías legales. Muchos proveedores mezclan modelos bajo el mismo nombre, así que compara qué te entregan y quién dirige, no cómo se llama la empresa.
| Modelo | Qué vende | Quién dirige | Riesgo principal |
|---|---|---|---|
| Consultora | Diagnóstico, arquitectura, definición de alcance y backlog | Tú y la consultora, en conjunto | Terminar con buenos documentos y ningún software |
| Fábrica de software | Un entregable con alcance, equipo y PM del proveedor | El proveedor, con tu validación en cada entrega | Alcance mal definido que se paga como adicional |
| Staff augmentation | Perfiles individuales por horas | Tú | Un equipo caro sin rumbo si nadie prioriza |
Pregúntate a quién vas a reclamarle si el sistema no sirve. Con la consultora, a quien definió mal; con la fábrica, a quien prometió el entregable; con staff augmentation, suele ser a ti, porque tú dirigiste. El detalle del modelo por horas está en nuestra guía de staff augmentation en México.
¿Cuál me conviene según cómo está hoy mi área de TI?
Si no tienes un líder técnico interno que priorice un backlog, necesitas consultora o fábrica con PM asignado. Si ya tienes CTO, backlog y procesos de QA, staff augmentation te permite sumar capacidad sin pagar la gestión de un proveedor.
La investigación que revisamos no trae una tarifa de mercado verificable para México en ninguno de los tres modelos, así que no afirmamos cuál sale más barato en pesos. La lógica sí es clara: en staff augmentation no pagas la capa de gestión del proveedor, pero tú la absorbes. Si no tienes quién la haga, el ahorro es aparente.
| Tu situación | Modelo que suele encajar | Por qué |
|---|---|---|
| Sin líder técnico y sin alcance claro | Consultora primero, fábrica después | Necesitas definir antes de construir |
| Sin líder técnico, pero con alcance documentado | Fábrica con PM asignado | El proveedor gestiona y tú validas entregas |
| Con CTO, backlog y QA propios | Staff augmentation | Tú ya sabes qué construir y en qué orden |
| Con líder técnico, pero el alcance cambia cada mes | Bolsa de horas o equipo dedicado | Un precio cerrado convertiría cada cambio en adicional |
Un error frecuente es contratar perfiles por hora porque la tarifa se ve baja, sin nadie que decida qué se hace primero. Tres desarrolladores sin dueño de producto producen funciones, no un sistema. Antes de elegir, escribe el nombre de la persona que va a priorizar y probar cada entrega. Si no puedes, ese es tu primer problema, y ningún modelo lo resuelve.
¿Precio cerrado o bolsa de horas? Cómo elegir sin pagar de más
Precio cerrado solo cuando el alcance está documentado y no va a cambiar: integraciones, migraciones o módulos acotados. Si el producto aún se está definiendo, conviene una bolsa de horas con tope por sprint y entregables revisables.
La razón es cómo se reparte el riesgo. En precio cerrado el proveedor asume el costo de equivocarse en la estimación, por eso cotiza con margen y cobra cada cambio como adicional. En horas, tú asumes la variación, pero pagas lo que se trabaja. Un acuerdo publicado de staff augmentation, el de CAI para el estado de Nuevo México, establece el pago por horas aprobadas por el cliente conforme a tarifas pactadas; es un ejemplo, no una regla universal.
El riesgo de fondo está en los datos. El CHAOS Report 2020, en el resumen de budgetoverrun.com, reporta esta distribución:
| Resultado del proyecto | Porcentaje |
|---|---|
| Exitosos | 31 % |
| Con problemas (exceden plazo o presupuesto, o entregan menos funciones) | 50 % |
| Fallidos (cancelados) | 19 % |
Son cifras de una fuente secundaria: no pudimos confirmarlas en una página oficial del Standish Group, y 2020 es la última edición completa que localizamos. Úsalas como orden de magnitud, no como garantía.
No tienes que elegir un solo esquema para todo el proyecto. Lo que mejor funciona es dividir:
- Descubrimiento por horas o a precio corto y acotado, para dejar alcance y criterios de aceptación por escrito.
- Construcción por módulos a precio cerrado para lo ya definido.
- Bolsa de horas con tope mensual para lo que sigue evolucionando.
- Un proceso de cambios escrito: quién solicita, quién estima y quién aprueba.
Las entregas cortas con demostración te permiten detectar a tiempo que el proyecto va hacia ese 50 % con problemas.
¿No sabes si esto aplica a tu empresa? Haz el diagnóstico gratuito de 3 minutos.
¿Qué entra en el costo además de la tarifa por hora?
La tarifa por hora es la parte visible: el costo total suma descubrimiento, diseño, QA, DevOps e infraestructura, gestión de proyecto, las horas de tu propia gente validando y el soporte posterior a la salida a producción, que suele presupuestarse en cero y nunca lo es.
No encontramos una fuente verificable que cuantifique cada concepto, así que no inventamos porcentajes. Pide que cada cotización los desglose o explique por qué no los incluye; para armar la comparación, revisa nuestra guía de costos de desarrollo de software en México. Pregunta uno por uno por descubrimiento, diseño de experiencia de usuario, pruebas, infraestructura en la nube (y quién paga la factura de Azure o AWS), gestión de proyecto, soporte tras el lanzamiento y mantenimiento anual.
Las horas internas son el costo que más se olvida. Si suponemos que tu gerente de operaciones dedica 5 horas a la semana durante 16 semanas a revisar entregas, son 80 horas de alguien que sigue cobrando su sueldo y dejando de hacer otra cosa. Es un supuesto, pero explica por qué un proyecto sin dueño interno con tiempo asignado se retrasa.
Hay un punto fiscal que conviene fijar en el contrato. El SAT identifica el CFDI 4.0 como la versión vigente desde el 1 de enero de 2022 y permite indicar la moneda de la operación. Si el proveedor cotiza en dólares, el Anexo 20 contempla el tipo de cambio FIX del último día del mes, de la fecha de emisión o del día del corte del CFDI. Define cuál aplica para no discutirlo en la primera factura.
¿Cómo valido que una consultora puede entregar y no solo vender?
Pide un caso con nombre y dominio parecido al tuyo, entrevista al líder técnico que estará asignado (no al que vende), revisa un entregable real y define criterios de aceptación medibles antes de firmar.
En la venta participa gente distinta a la que construye, y un caso de referencia solo vale si puedes verificarlo. Por ejemplo, ITECHDEV publica casos con nombre, como Certior, donde convertimos una metodología propia del sector transporte en un sistema a la medida sobre Azure, o CAINTRA, un portal de proveedores y cotizaciones. Aplica la misma exigencia a cualquier proveedor, incluidos nosotros.
- Pide dos o tres casos publicados o referencias que puedas llamar, con alcance parecido al tuyo.
- Entrevista a quien será líder técnico del proyecto, no solo al ejecutivo comercial.
- Pide ver documentación o un entregable real: un manual, un diagrama de arquitectura o un repositorio de ejemplo.
- Escribe criterios de aceptación por entrega antes de firmar.
- Pregunta cómo se mide el avance: demos cada una o dos semanas, no un solo entregable al final.
Para armar tu lista de candidatos, nuestra comparativa de empresas de desarrollo de software en México es un punto de partida, y la guía para contratar una empresa de software detalla el proceso de selección. Es señal de alerta que no te dejen hablar con el equipo técnico o que todo caso previo sea «confidencial».
¿Qué cláusulas no pueden faltar en el contrato?
Propiedad intelectual del código a tu nombre, entrega periódica de repositorios y accesos, criterios de aceptación por hito, nivel de servicio de soporte, cláusula de migración de datos y de reversión, y un plan de transferencia de conocimiento si cambias de proveedor.
Las fuentes que consultamos no confirmaron cláusulas obligatorias específicas para estos servicios en México. Lo siguiente es práctica de implementación, no requisito legal, y tu abogado debe revisarlo.
- Propiedad y ubicación del código: a nombre de tu empresa, en un repositorio de tu organización y con documentación incluida.
- Aceptación por hito: cada pago ligado a criterios medibles escritos desde antes.
- Soporte posterior: cuánto dura, qué cubre y qué tiempos de respuesta aplica.
- Salida ordenada: entrega de datos, accesos y una sesión de transferencia.
- Facturación: moneda, tipo de cambio y CFDI 4.0, que se timbra con un PAC autorizado por el SAT.
La que más duele cuando falta es la del repositorio: si el código vive solo en el equipo del proveedor, tu margen de negociación es cero el día que quieras cambiar.
¿Qué errores salen más caros al contratar un proveedor de software?
Los cuatro más caros son elegir por la tarifa más baja sin comparar el equipo asignado, no nombrar un dueño del producto interno, pagar hitos sin criterios de aceptación escritos y no reservar presupuesto para los meses posteriores al lanzamiento.
- Tarifa baja, equipo distinto. Con la misma tarifa por hora pueden llegar perfiles de experiencia muy diferente. Pide nombres y rol de quienes trabajarán en tu proyecto.
- Nadie decide del lado del cliente. Si cada área opina y nadie prioriza, el alcance crece solo. Nombra a una persona con autoridad y tiempo.
- Hitos sin criterios. Un entregable «terminado» sin definición de terminado se discute al final, cuando ya pagaste.
- Presupuesto cero después del lanzamiento. Los ajustes y correcciones siempre llegan; cotízalos por separado desde el inicio y compáralos entre propuestas.
A esto se suma empezar a programar sin alcance escrito. El CHAOS Report cuenta como proyecto con problemas al que excede plazo o presupuesto, o entrega menos funciones de las previstas. Un alcance escrito no elimina esa posibilidad, pero te da con qué medirla.
¿Cuándo NO necesitas una consultora de software a la medida?
Si tu necesidad se resuelve configurando un ERP o un SaaS estándar, lo que conviene es un implementador especializado, no desarrollo a la medida. Y si es una automatización puntual, empieza por integrar lo que ya tienes antes de construir algo nuevo.
La regla práctica: si un producto existente cubre cerca del 80 % de tu proceso con configuración, se configura y lo restante se resuelve con una integración o un módulo pequeño. Construir a la medida algo que ya existe como producto es de los errores más caros, porque además heredas el mantenimiento. ITECHDEV implementa Odoo, SAP y Salesforce; antes de aceptar una cotización de desarrollo propio, pide a cualquier proveedor que confirme por escrito si un producto existente cubre tu proceso.
El desarrollo a la medida sí tiene sentido cuando tu proceso es el diferenciador del negocio, ninguna herramienta lo modela y vas a operarlo muchos años. Un ejemplo publicado es Certior, donde se modeló el sistema sobre la forma real de operar de una metodología propia del sector transporte, sobre Azure.
Fuentes
- Standish CHAOS Report by Year: Every Edition 1994 to 2020 — https://budgetoverrun.com/studies/chaos-report-by-year
- CHAOS Report — why this study about IT project management is so unique — https://thestory.is/en/journal/chaos-report/
- SAT, Servicio gratuito — https://www.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461175192578&ssbinary=true
- SAT, Anexo 20 — https://www.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173536663&ssbinary=true
- CAI, State of New Mexico Supplier Agreement — https://www.cai.io/media/documents/msp/nm/CAI_New_Mexico_Supplier_Agreement_v.04-01-2024.pdf
Si ya sabes quién va a decidir del lado de tu empresa y qué quieres construir, conoce cómo trabaja nuestra fábrica de software o haz el diagnóstico gratuito para saber qué modelo te conviene.