Cómo elegir una software house: 10 criterios esenciales en 2026

Contratar la software house equivocada puede salir muy caro: meses de retraso, retrabajo, dinero quemado y un sistema que nadie usa. En más de 20 años desarrollando proyectos para empresas de todos los portes, vimos los mismos errores repetirse en casi todos los fracasos.

En esta guía, listamos los 10 criterios que separan una buena software house de una trampa cara. Use como checklist en su próxima contratación, y si la empresa que está evaluando falla en más de 3 de ellos, considere buscar otra.

Por qué la elección equivocada cuesta tanto

Un proyecto de software mal contratado raramente fracasa de una vez. Se pudre en cámara lenta: los plazos se empujan, el alcance cambia sin explicación, los bugs se acumulan, y cuando se da cuenta ya invirtió un presupuesto entero en algo que necesita rehacerse desde cero. Lo peor es que muchos solo descubren el tamaño del problema cuando el competidor lanza primero.

Los costos invisibles suelen ser mayores que el presupuesto original:

• Tiempo de sus gestores: reuniones interminables tratando de descubrir qué pasa en el proyecto
• Costo de oportunidad: mientras su sistema se atrasa, el competidor lanza y captura mercado
• Deuda técnica: código mal escrito se convierte en pesadilla para mantenimiento
• Erosión de confianza interna: los equipos desisten de la tecnología después de una mala experiencia

"Ya rehicimos sistemas caros, cobrados por otras empresas y entregados sin funcionar. El cliente perdió el dinero, pero lo peor fue perder 18 meses de mercado."
Alexandre Rosa, fundador de Reiko

Los 10 criterios esenciales

Antes de firmar cualquier contrato, valide la software house con este checklist. Son los puntos que más veces vimos diferenciar a quien entrega de quien solo promete.

1. Portafolio con casos reales y medibles

No basta con ver una lista de logos. Pregunte: ¿qué problema resolvió cada proyecto? ¿Cuánto ahorró o generó en ingresos? ¿Cuánto tiempo llevó? Una software house seria habla en métricas concretas, no en adjetivos vagos. Pida al menos 3 casos detallados en su industria.

2. Stack tecnológico moderno y justificado

Pregunte por qué eligieron React en lugar de Vue, Node en lugar de PHP, AWS en lugar de Azure. La respuesta debe tener sentido para su caso, no solo para el de ellos. Cuidado con empresas que solo saben trabajar con un único stack: lo forzarán a usarlo incluso cuando no sea la mejor opción.

3. Proceso de descubrimiento antes del presupuesto

Quien cierra precio por WhatsApp no vende software, vende lotería. Software house seria hace descubrimiento: entiende su negocio, mapea procesos, prototipa pantallas, valida hipótesis, y solo entonces presupuesta con precisión. Este trabajo lleva 1 a 3 semanas y generalmente se cobra aparte.

4. Equipo propio, no freelancers tercerizados

Pregunte exactamente quién trabajará en su proyecto. ¿Son empleados? ¿Contratistas exclusivos? ¿Freelancers remotos? La diferencia es enorme en calidad, compromiso, continuidad y capacidad de soporte futuro. Software houses que tercerizan a freelancers sin que usted sepa son una de las mayores fuentes de problemas.

Señales técnicas que separan el grano de la paja

Además de los criterios comerciales, hay cinco señales técnicas que distinguen software house madura de principiante:

• Versionado de código (Git): todo código debe estar en GitHub, GitLab o similar, con historial revisable
• Tests automatizados: sistemas serios tienen cobertura mínima de 60% en código crítico
• CI/CD (despliegue automatizado): nada de "subir" manualmente a producción vía FTP
• Documentación técnica: README claro, arquitectura dibujada, decisiones registradas
• Monitoreo y observabilidad: cuando hay problema en producción, deben saber antes de que usted reclame

Lo que NO contratar

Algunos patrones garantizan dolor de cabeza. Huya si la software house se encaja en cualquiera de estos:

• Tiene menos de 3 años de actividad, especialmente para proyectos críticos
• Se niega a entregar el código fuente al final del contrato
• No acepta contrato con cláusulas de SLA, multa por atraso y propiedad intelectual
• Promete todo, da descuento enorme solo para cerrar y tiene equipo demasiado pequeño

Recuerde: lo barato sale caro, principalmente en software. Un sistema mal hecho cuesta 3 a 5 veces más para rehacer que para hacer bien la primera vez.

Cómo evaluar la propuesta

En vez de perseguir un número suelto, mira cómo fue construida la propuesta. Son tres puntos que separan una propuesta seria de un tiro al aire:

• Composición por etapa: descubrimiento, diseño, desarrollo, QA e infraestructura presupuestados por separado, con entregables y horas por etapa en vez de un valor único sin explicación
• Qué está incluido y qué no: migración de datos, capacitación, documentación técnica, ambiente de homologación y cada integración citada por su nombre, con lo que queda fuera dicho por escrito
• Garantía y lo que viene después: plazo de garantía post-lanzamiento, qué cuenta como corrección (sin costo) y qué cuenta como evolución (presupuestada aparte), además del modelo de mantenimiento y del costo de operación mensual

Una propuesta que llega como un número redondo, sin composición ni entregables, está pidiendo confianza ciega. Quien cobra muy por debajo de los competidores está economizando en calidad, equipo o ambos. Quien cobra muy por encima necesita explicar exactamente por qué.

Cómo conducir el proceso de selección

Si es serio en la contratación, siga este proceso de 5 pasos. Tomar 2 semanas más aquí economiza 12 meses después:

1. Defina el problema, no la solución: escriba 1 página describiendo qué necesita resolver, sin decir "cómo"
2. Seleccione 3 a 5 candidatas: una referencia no es suficiente. Compare propuestas para entender el mercado
3. Haga call técnica con el equipo: no hable solo con vendedor. Pida hablar con el tech lead real
4. Pida referencias y llame: 3 clientes anteriores como mínimo. Pregunte si contratarían de nuevo
5. Empiece con alcance piloto pago: antes de cerrar proyecto grande, contrate un sprint de descubrimiento pago

Conclusión

Contratar una software house es una de las decisiones más caras que su empresa tomará en los próximos años. El costo total de la elección equivocada supera fácilmente el triple del presupuesto original.

Use este checklist en sus próximas evaluaciones. Si quiere una segunda opinión sobre un presupuesto, o si busca quien entrega sistemas web a medida con previsibilidad, hable con nuestro equipo. Análisis inicial es gratuito.

Preguntas frecuentes sobre elegir una software house

¿Cuánto cobrar una software house es razonable?

Lo importante no es el número absoluto, es cómo el número se compone. Software house seria muestra presupuesto separado por etapa (descubrimiento, diseño, desarrollo, QA, infra) y dice qué está incluido en cada una. Compara propuestas por la composición y por los entregables, no por el total: precio muy por debajo de los competidores casi siempre significa cortar QA, diseño o seniority del equipo, y eso se vuelve retrabajo después. El valor de tu caso sale en la propuesta, cuando el alcance esté claro.

¿Puedo elegir la software house más barata y que funcione?

Técnicamente es posible, pero la probabilidad es baja y el costo del error es alto. La mayoría de las software houses que cobran la mitad del mercado hace una de estas: (a) usa freelancers sin que usted sepa, (b) corta etapas de QA y diseño, (c) entrega el mínimo del contrato y cobra extra por todo lo que quedó "fuera de alcance". El resultado práctico es desperdicio: usted paga caro para recibir algo que no atiende, y después paga de nuevo para que otra empresa lo rehaga. Vale la pena pagar el precio de quien entrega de verdad.

¿Cómo saber si el portafolio es real y no maquillaje?

Pida contacto de 2 a 3 clientes recientes y llame. Pregunte: ¿plazo cumplido? ¿Bug en producción? ¿Cómo fue la comunicación en el proyecto? ¿La software house aún da soporte hoy? Cliente real responde con detalles; caso maquillado tiene 1 frase genérica y el teléfono del "cliente" cae en alguien de la propia empresa. También observe si los proyectos del portafolio están en línea y funcionan: enlace roto o "sitio en mantenimiento" son red flag clásicos.

¿Es mejor contratar software house local o puede ser de otro estado?

Para proyectos a medida con necesidad de inmersión (ERP, marketplace, SaaS complejo), local o al menos del mismo huso horario ayuda mucho en los primeros 2 a 3 meses: reuniones presenciales aceleran alineación. Para proyectos medianos bien documentados, remoto Brasil (cualquier estado) funciona bien siempre que tenga disciplina de reunión semanal por video y demo cada sprint. Off-shore (India, Vietnam, Argentina) solo vale para proyectos grandes con PM bilingüe dedicado de su lado, caso contrario el costo escondido (huso, idioma, jurídico) supera el ahorro.

¿Cómo el contrato protege el código fuente y la propiedad intelectual?

Cláusula explícita de cesión total de derechos de autor del código entregado al contratante, depósito del código en repositorio que usted accede (GitHub/GitLab privado de su empresa, no de la software house), entrega de documentación técnica y ambiente de producción bajo sus credenciales cloud (AWS/Google Cloud en la cuenta de su empresa, no de la proveedora). Sin eso usted queda rehén: en caso de conflicto la proveedora puede retener deploy o dificultar transición a otra empresa.