Qué es realmente una fábrica de software (y qué no deberías esperar de ella)
El término se usa para todo, desde un equipo de dos personas hasta una maquiladora de código. Aquí está la definición útil y honesta.
«Fábrica de software» es de esos términos que se usan para todo. Lo dice un desarrollador que trabaja solo desde su casa, lo dice una empresa de cincuenta ingenieros y lo dice también un intermediario que subcontrata en otro país y te pone su logo encima. Los tres cobran distinto, entregan distinto y fallan de forma distinta.
Si estás por contratar desarrollo a la medida, esa ambigüedad te cuesta dinero. No porque te vayan a estafar —eso pasa menos de lo que se cree— sino porque vas a comprar una cosa esperando otra, y esa distancia entre lo que imaginaste y lo que llega es el origen de casi todos los proyectos que terminan mal.
Este artículo pone el término en su lugar: qué es realmente el modelo, en qué se diferencia de las alternativas, qué es razonable esperar y qué no, y cuáles son las señales que deberían hacerte desconfiar antes de firmar.
Sumario
- 01Qué define a una fábrica de software
- 02Los cuatro modelos, comparados sin diplomacia
- 03Qué sí deberías esperar
- 04Qué no deberías esperar
- 05Cuánto tarda de verdad
- 06Siete banderas rojas al contratar
Qué define a una fábrica de software
La palabra «fábrica» despista, porque sugiere una línea de producción donde el software sale en serie. No es eso. Cada sistema a la medida es distinto, igual que cada edificio es distinto aunque el oficio de construir sea el mismo.
Lo que define al modelo no es el producto: es el proceso repetible y el equipo estable. Una fábrica de software es una organización que tiene una manera propia y probada de llevar un proyecto de la idea a producción, y que la aplica sin importar quién sea el cliente. En la práctica eso significa cuatro cosas concretas.
Hay alguien que analiza, alguien que construye, alguien que prueba y alguien que responde por el proyecto. Pueden ser tres personas con varios sombreros, pero los roles existen.
Control de versiones, ambientes separados, pruebas, revisión de código y despliegue documentado. Si alguien se enferma, el proyecto sigue.
Ves funcionando pedazos del sistema cada pocas semanas, no un archivo comprimido el último día.
Existe un esquema de soporte y evolución. El software no se acaba cuando se entrega: apenas empieza a vivir.
Pregunta cómo se despliega a producción. Si la respuesta es «lo sube Fulano desde su compu», estás contratando a una persona con ayudantes, no a una fábrica de software. Eso puede estar bien para tu caso —pero conviene saberlo antes, no después.
Los cuatro modelos, comparados sin diplomacia
Ninguno es mejor en abstracto. Cada uno gana en un escenario y se rompe en otro. Lo que sigue es la comparación que rara vez te van a hacer quienes te están cotizando.
| Modelo | Es fuerte en | Se rompe cuando | Costo relativo |
|---|---|---|---|
| Freelance | Proyectos chicos y acotados, prototipos, arreglos puntuales. Trato directo y rápido. | El proyecto crece, la persona consigue otro cliente mejor o simplemente desaparece. No hay quien lo cubra. | El más bajo por hora, el más alto en riesgo |
| Agencia digital | Sitios web, tiendas en línea, integraciones sobre plataformas ya hechas. | Necesitas lógica de negocio propia. El desarrollo a la medida no es su oficio central. | Medio |
| Fábrica de software | Sistemas a la medida de mediana complejidad, integraciones, proyectos de varios meses con evolución continua. | El alcance es diminuto —te cobra estructura que no necesitas— o gigantesco y estratégico. | Medio-alto, predecible |
| Equipo interno | Software que es tu negocio, no que lo apoya. Conocimiento que debe quedarse en casa. | Tardas meses en contratar, cuesta el doble de lo que crees y la rotación te devuelve al inicio. | El más alto en total |
Fábrica para arrancar y construir, con una o dos personas tuyas dentro del equipo desde el día uno. Cuesta un poco más al principio y te ahorra la dependencia total del proveedor al final. Si tu proyecto va a vivir años, es casi siempre la mejor decisión.
Qué sí deberías esperar
Estas no son cortesías: son parte de lo que estás pagando. Si no las estás recibiendo, hay algo que reclamar.
- ▪Un interlocutor con nombre. Alguien que responde por el proyecto, no una cuenta de correo genérica.
- ▪Ver el sistema funcionando cada dos o tres semanas. Aunque esté incompleto. Aunque sea feo todavía.
- ▪El código a tu nombre y en tu repositorio. Con acceso desde el primer commit, no al final.
- ▪Que te digan que no. Un buen proveedor discute el alcance cuando lo que pides va a costar diez veces lo que aporta.
- ▪Estimaciones en rangos, no en cifras mágicas. «Entre 10 y 14 semanas» es honesto. «12 semanas exactas» dicho en la primera llamada es marketing.
- ▪Documentación suficiente para que otro pueda continuar. Cómo se levanta, de qué depende, cómo se despliega.
Qué no deberías esperar
Que adivinen lo que tienes en la cabeza
Ningún proveedor, por bueno que sea, conoce tu operación mejor que tú. Si la definición del alcance no incluye horas de tu equipo explicando cómo funciona el negocio, el resultado va a ser un sistema técnicamente correcto y operativamente inútil.
Calcula entre 4 y 8 horas semanales de alguien de tu lado durante todo el proyecto. No es opcional y no es tiempo perdido: es el insumo principal.
Que salga más barato que un freelance
No sale. Estás pagando análisis, pruebas, revisión de código y continuidad, y todo eso son horas que un freelance simplemente no hace. La comparación honesta no es «precio por hora» sino costo total a tres años, incluyendo lo que cuesta rehacer algo mal hecho.
Que el sistema quede «terminado»
El software no se termina, se estabiliza. Cambian las reglas de tu negocio, cambia el SAT, cambian los proveedores con los que te integras, cambian los navegadores. Un sistema sin mantenimiento se degrada aunque nadie lo toque.
Entre 15% y 20% anual del costo de construcción, solo para mantenerlo vivo. Si nadie te mencionó esa cifra antes de firmar, va a aparecer como sorpresa después.
Que un precio cerrado te proteja de todo
El precio cerrado protege el presupuesto y castiga el cambio. Cuando a mitad del proyecto descubras algo que nadie previó —y siempre se descubre— vas a tener dos opciones: pagar una adenda o quedarte con un sistema que ya sabes que no es el correcto. Ambas son caras.
Cuánto tarda de verdad
Los tiempos que verás abajo son para un sistema interno de complejidad media: entre seis y doce pantallas, dos o tres integraciones, usuarios con permisos distintos. Es el proyecto más común en una PyME.
-
1Descubrimiento 2 a 4 semanas
Entender el proceso real, no el que está en el manual. Se define el alcance, se prioriza y se acuerda cómo sabremos que quedó bien. Es la etapa que más gente quiere saltarse y la que más proyectos salva.
-
2Primera entrega útil 6 a 10 semanas
Algo que alguien de tu equipo ya puede usar en su trabajo diario, aunque le falte la mitad. Si a las diez semanas no hay nada usable, hay un problema de método, no de esfuerzo.
-
3Construcción por ciclos 3 a 6 meses
Entregas cada dos o tres semanas, con tu equipo probando y corrigiendo el rumbo. Aquí es donde el alcance cambia, y está bien que cambie: para eso se entrega por partes.
-
4Estabilización y traspaso 3 a 6 semanas
Migración de datos, capacitación, documentación, ajustes de los primeros días reales. Se define quién da soporte y bajo qué tiempos de respuesta. Esta etapa casi nunca se presupuesta y siempre ocurre.
La causa número uno de que un proyecto se alargue no es la programación: son las decisiones pendientes del lado del cliente. Una definición que tarda dos semanas en resolverse frena a todo el equipo esos días. Nombra a una persona con autoridad para decidir y el calendario se cumple solo.
Siete banderas rojas al contratar
Ninguna es prueba de mala fe. Todas son motivo para hacer una pregunta más antes de firmar.
Revisa esto antes de firmar
Imprimir o guardar como PDF- Preguntaron por el negocio antes que por las pantallas Si la primera junta fue solo de requerimientos técnicos, van a construir lo que pediste, no lo que necesitas
- No cotizaron un precio cerrado en la primera llamada Cotizar sin descubrimiento significa que el margen de error ya está cargado al precio, o va a aparecer como adenda
- El código queda a tu nombre y tienes acceso al repositorio desde el día uno Debe estar escrito en el contrato, no prometido en un correo
- Mencionaron pruebas, ambientes separados y plan de reversa sin que preguntaras Si nadie habla de cómo se prueba, es porque no se prueba
- Te presentaron un equipo con nombres, no «recursos disponibles» Pregunta quién específicamente va a estar y cuánto tiempo de su semana
- Existe un plan de salida documentado Qué pasa si mañana quieres cambiar de proveedor: qué te entregan y en cuánto tiempo
- Los tiempos que te dieron incluyen tus tiempos de validación Un calendario que asume que respondes en 24 horas es un calendario que no se va a cumplir
Con cinco de siete puedes avanzar con confianza. Con menos de cuatro, vale la pena pedir una segunda propuesta antes de decidir.
La pregunta que resume todo
Si tuvieras que quedarte con una sola pregunta para hacerle a cualquier proveedor, sería esta: «cuéntame de un proyecto que les haya salido mal y qué cambiaron después».
Quien lleva años haciendo esto tiene esa historia y la cuenta sin problema, porque el aprendizaje ya está incorporado en cómo trabaja hoy. Quien te dice que nunca ha tenido un proyecto complicado, o no ha hecho suficientes, o no te está diciendo la verdad. Las dos posibilidades te cuestan lo mismo.
Contratar desarrollo a la medida no es comprar un producto: es elegir con quién vas a resolver problemas que todavía no conoces.
¿Estás por contratar desarrollo y quieres una segunda opinión?
Somos fábrica de software y también revisamos propuestas ajenas. Te ayudamos a definir el alcance real antes de que firmes, o construimos el sistema con un equipo con nombres, entregas cada dos semanas y el código a tu nombre desde el primer día.
- —Fábrica de software y desarrollo a la medida
- —Automatización de procesos e integraciones
- —Modernización de sistemas .NET heredados
- —Soporte y evolución continua del software