Software house: cuándo contratar (y cuándo no) — la guía del fundador no técnico

La primera vez que me senté con un fundador al que una software house había dejado mal parado, me mostró un repositorio con once mil archivos, sin README, sin tests, y tres commits llamados final-final.zip. La empresa que había entregado todo aquello no respondía mensajes desde hacía cuatro meses. Había pagado R$ 320.000. Tenía un sistema que funcionaba. Casi. Y ya no quedaba nadie capaz de meterle mano.

La pregunta que me hizo, la misma que aparece en alguna versión en casi todas las primeras reuniones con fundadores no técnicos, fue esta: “¿vale la pena contratar una software house o tendría que haber hecho otra cosa?”

Vale la pena, en la mayoría de los casos. Pero la pregunta está mal planteada. Una software house no es una elección frente al freelancer ni frente al equipo interno. Es una de las cuatro opciones reales que tiene un fundador para construir software, y cada una tiene sentido en momentos distintos. El error que le costó al fundador R$ 320 mil no fue elegir software house. Fue elegir aquella software house por las razones equivocadas.

Esta guía trata sobre cómo decidir, y cómo decidir bien.

Qué es una software house, en la práctica

Una software house es una empresa que diseña y construye software a medida para otras empresas. La versión corta: un equipo multidisciplinar (producto, diseño, ingeniería) que entrega un sistema en producción, desde la concepción hasta el deploy, sin que la contratante tenga que armar un equipo de tecnología interno.

En la práctica, lo que distingue a una software house de otras formas de contratar ingeniería es el alcance del entregable. Una software house entrega el producto. Un freelancer entrega horas. Un equipo interno entrega un equipo. Las tres cosas cuestan dinero de maneras distintas, exigen una gestión distinta y producen resultados distintos.

Ese “entrega el producto” no es trivial. Significa que la software house es responsable del paquete completo: spec, decisiones de arquitectura, código, QA, infraestructura, y la documentación que permite que alguien continúe el trabajo después. Cuando la entrega es buena, el fundador termina el proyecto con un sistema funcionando, un repositorio legible, y la opción real de internalizar el equipo después. Cuando es mala, termina con once mil archivos sin dueño.

Las cuatro opciones reales (y qué hace bien cada una)

Antes de decidir contratar una software house, conviene poner las cuatro opciones que realmente tienes sobre la mesa. Cada una resuelve un conjunto de problemas y crea otro.

No-code. Bubble, Glide, Softr, Retool. Útil para validar una idea antes de pagar ingeniería de verdad. Se quiebra en la primera personalización que el roadmap del proveedor no previó. Tiene techo. La mayoría de los fundadores se queda seis a doce meses más de lo que debería.

Freelancer o dev solo. Barato por hora, caro en el acumulado. Excelente para un trozo pequeño y bien definido (un conector, un script, una feature aislada). Pésimo para construir un producto completo: sin code review, sin redundancia, sin nadie con quien discutir trade-offs de arquitectura. Si el dev se va, el sistema queda huérfano.

Equipo interno (CTO + dos o tres ingenieros). El mejor camino cuando el software es el negocio y la empresa tiene madurez para gestionar ingeniería. Caro de armar, lento de poner a ritmo, difícil de gestionar si no vienes del área. Si la empresa no llegó al estadio en el que el software es ventaja competitiva real, es demasiado pronto.

Software house. Entrega el producto y la documentación. Ramping rápido (semanas, no meses). Cara por hora, pero el costo total suele ser menor que el del equipo interno equivalente hasta la Serie A, porque pagas solo el ancho de banda que estás usando. El riesgo es depender de un proveedor para un activo central; la forma de mitigarlo está en el contrato y en a quién contratas, y los dos temas tienen su propia sección más adelante.

La regla práctica es esta: cuanto más central es el sistema para el negocio y cuanto más va a cambiar en los próximos doce meses, más se inclina la balanza hacia un equipo interno. Cuanto más complementario es el sistema y cuanto más necesita el fundador preservar foco en otros frentes (ventas, fundraising, regulación), más se inclina hacia una software house. Freelancer solo gana en recortes pequeños. No-code solo gana en validación.

El framework de cuatro preguntas

Uso cuatro preguntas con cualquier fundador antes de recomendarle contratar una software house, y antes de aceptar trabajar con un cliente nuevo. Si tres de las cuatro respuestas apuntan al mismo lado, la decisión es fácil. Cuando se dividen, vale la pena hablar más antes de firmar nada.

1. ¿Qué tan claro está el spec?

No es “tienes un documento de requerimientos.” Es “puedes explicar, en dos frases, qué problema resuelves y para quién”. Una software house es buena traduciendo una idea clara en sistema. No es buena (ni barata) ayudándote a descubrir cuál es la idea.

Si la respuesta es “todavía estoy validando el problema”, para. Haz discovery primero, contigo mismo y con los primeros clientes. Compra una suscripción de Bubble si hace falta. Vuelve a la software house cuando el spec esté firme. Cada hora que una software house gasta en descubrimiento de producto te cuesta cinco veces lo que costaría gastada en código.

2. ¿Qué tan central es el sistema para el negocio?

Hay sistemas que son el producto (toda la fintech corre sobre el core bancario) y sistemas que destraban la operación (el panel interno que liberó a tres personas del equipo de operaciones). Ambos merecen software bien hecho. Pero el tipo de relación contractual y el tipo de transición que quieres al final son distintos.

Para sistemas centrales, planea desde el día uno la internalización del equipo. La software house ideal aquí es la que te ayuda a contratar tus primeros ingenieros, transfiere contexto, y se va cuando ya no la necesitas. Para sistemas internos, una software house puede ser el equipo permanente. No tiene nada de malo mantener un partner de largo plazo cuidando las herramientas internas; solo tiene que estar acordado.

3. ¿En qué etapa estás y cuánto runway te queda?

Pre-seed y seed con runway corto: la velocidad lo es todo. Una software house entrega rápido porque el equipo ya está armado. Usar tres meses para contratar un CTO antes de empezar a construir son tres meses que no recuperas.

A partir de Serie A, con PMF claro y roadmap largo, la economía cambia. El equipo interno sale más barato en el acumulado, genera activo (talento que crece con la empresa) y crea continuidad. Ese es el punto natural de transición: software house para sacar la empresa del piso, equipo interno para escalar.

4. ¿Quién va a ser dueño del código en dieciocho meses?

Esa es la pregunta que separa a las software houses serias del resto. Pregunta explícitamente, antes de firmar: el repositorio está en el GitHub de mi empresa desde el día uno. La documentación es mía. Cuando contrate a mis primeros ingenieros, tu equipo se sienta con ellos, transfiere contexto y sale sin generar trauma.

Si la software house esquiva o condiciona la salida a algún tipo de licencia, royalty o soporte obligatorio, corre. Los contratos honestos son cortos en este punto. El código es tuyo. Siempre fue.

Cómo evaluar una software house sin fingir conocimiento técnico

Aquí es donde más fundadores no técnicos se traban. No tienes que evaluar el stack que proponen. Tienes que evaluar cómo piensan.

Pídeles el post-mortem del proyecto que peor les fue. Una software house seria tiene uno. Una que dice “nunca tuvimos un problema” o miente o lleva poco tiempo en el mercado. Lo que importa no es el error; es el nivel de detalle y autocrítica en la respuesta.

Pide referencias y llámalas con la cámara cerrada. Los ex-clientes que terminaron el proyecto hace seis meses o más son la mejor muestra. Pregunta cosas concretas: ¿se respetó el presupuesto? ¿quién mantenía el sistema cuando ustedes ya no estaban? ¿los volverían a contratar? Cuando una referencia duda, estás escuchando la verdad.

Pide conocer a quien va a trabajar en tu proyecto, no solo al sales. Una software house seria te deja hablar con el tech lead que va a liderar el equipo. Una mala mantiene una atención comercial muy buena y esconde al equipo que entrega.

Pide una propuesta con alcance, no con horas. “Vamos a cobrar 1.200 horas a R$ 250” no es una propuesta. Es un cheque en blanco. “Vamos a entregar el módulo X por R$ Y, en Z semanas, con criterios de aceptación escritos” sí lo es. Una software house que solo vende horas te está diciendo que no confía en su propio alcance.

Mira el portfolio con escepticismo. Lindo en Behance no es sinónimo de bueno en producción. Pregunta cuál de esos proyectos sigue en producción, cuál fue descontinuado, cuál se llevó el cliente a otro proveedor. La historia después del lanzamiento es lo que cuenta.

Cuánto cuesta contratar una software house

Hay un rango razonable y hay extremos peligrosos. Los promedios siguientes son para proyectos de producto digital de complejidad moderada, con equipo pequeño (2 a 5 personas asignadas), en San Pablo, Río u otras capitales con mercado tech maduro.

Hora-hombre promedio en el mercado BR (2026): R$ 180 a R$ 350 la hora para equipos seniors, R$ 100 a R$ 180 para equipos mixtos con más juniors. Por debajo de R$ 100, sospecha. Por encima de R$ 400, estás pagando una marca, y eso puede valer la pena o no.

Proyecto de MVP (3 a 4 meses): R$ 250 mil a R$ 600 mil es la franja en la que suelen caer los proyectos honestos. Por debajo, o el alcance es minúsculo, o alguien va a recortar ángulos. Por encima, o la complejidad es real (regulación, integraciones pesadas, ML aplicado), o estás pagando overhead.

Squad asignado mensual (2 a 3 personas, continuo): R$ 80 mil a R$ 180 mil al mes, según seniority.

Compara con el equipo interno equivalente: un CTO pleno y dos ingenieros sénior en San Pablo, con cargas, herramientas y equipos, cuestan entre R$ 90 mil y R$ 130 mil al mes, y tardan tres a seis meses hasta entregar al ritmo. Una software house cuesta más por hora pero empieza a entregar en la semana tres.

No tomes esa decisión en planilla. Tómala en runway. ¿Cuánto tiempo tienes hasta necesitar un producto andando, y cuánta de tu banda quieres quemar gestionando gente en ese intervalo?

La conversación del contrato

Antes de firmar, exige explícitamente:

• Propiedad del código. El repositorio es de tu empresa, en el GitHub o GitLab de tu empresa, desde el primer commit. Sin licencias, sin cláusulas que limiten el uso futuro, sin dependencia de la plataforma propietaria del proveedor.
• Cláusula de salida sin trauma. ¿Cómo termina, si una de las partes decide que no va más? Aviso previo, transición asistida, transferencia de conocimiento documentada. Todo escrito.
• SLA de comunicación, no solo de uptime. ¿En cuánto tiempo responden? ¿Quién es tu punto de contacto? ¿Qué pasa cuando el tech lead se va de vacaciones?
• Criterios de aceptación por entrega. Qué cuenta como “hecho” para cada módulo. Concreto, medible.
• Tope al scope creep. Los cambios de alcance generan un anexo, con plazo y costo recalculados. No generan bola de nieve.

Aquí es donde más relaciones se agrian, y se agrian por algo básico: nadie escribió cómo iba a ser la salida. Firma con salida clara.

Señales de alerta a mitad de proyecto

Algunas relaciones con software house empiezan bien y se agrian. Las señales aparecen antes de la entrega final.

La demo semanal pasa a ser mensual. Una software house seria muestra trabajo todas las semanas. Cuando el ritmo de demos cae, es porque cayó el ritmo de entrega, o porque hay algo que el equipo no quiere mostrar.

El tech lead cambia sin aviso. La gente se va, es normal. Lo que no es normal es enterarte tres sprints después de que quien lidera tu proyecto ya no es el que entrevistaste. Una software house sólida comunica de inmediato un cambio de personas clave.

Los pedidos de cambio de alcance se vuelven tabú. Cambias algo, lo aceptan sin renegociar plazo. Cinco cambios después, la entrega está tres meses atrasada y nadie sabe por qué. Un cambio de alcance debería generar fricción saludable; cuando no la genera, alguien está acumulando deuda invisible.

Los commits se vuelven genéricos. “fix bug”, “ajustes”, “WIP” como mensaje de commit del día entero. Es el equivalente en código del “ya te explico después”.

Cuando dos de esas señales aparecen juntas, pide una conversación franca, con agenda escrita, sin el sales en la sala. La mayoría de las relaciones agrias puede repararse si la conversación pasa en el mes tres. Casi ninguna puede repararse en el mes ocho.

La elección no es entre proveedores; es entre futuros

Toda contratación de software house es, en realidad, una apuesta sobre qué tipo de empresa quieres ser dentro de dieciocho meses. Una software house barata y descomprometida te entrega un sistema que funciona hasta la próxima ronda y después se traba. Una seria te entrega un sistema, un manual y una transición limpia para el equipo que vas a contratar más adelante.

La diferencia de precio entre las dos es menor de lo que parece. La diferencia de destino es el resto de la empresa.

Si te cuesta decidir entre opciones, vuelve a las cuatro preguntas. Qué tan claro está el spec, qué tan central es el sistema, en qué etapa estás y quién es dueño del código en dieciocho meses. En general, tres de las cuatro respuestas apuntan al mismo lugar. Cuando lo hacen, ve. Cuando no, espera una semana más y habla con un cliente más de la software house antes de firmar.

La decisión correcta no es la más barata, ni la más sofisticada. Es la que te deja durmiendo sabiendo quién está construyendo qué y por qué.