Cómo elegir una empresa de desarrollo de software (sin quemarte)
La mayoría de los proyectos de software que fracasan se eligieron mal desde el inicio. Esta guía entrega los criterios reales, las señales de alerta y las preguntas exactas que tienes que hacer antes de firmar.
Respuesta rápida
Para elegir bien una empresa de desarrollo de software, prioriza cinco criterios no negociables: seniority real del equipo asignado (no solo del vendedor), dirección técnica con arquitecto involucrado, propiedad clara del código y los datos, proceso con entregas incrementales verificables y casos de éxito que puedas contactar. Las señales de alerta más comunes son precios anormalmente bajos, promesas de plazos imposibles y propuestas sin arquitectura.
Lo esencial
- El error #1 es elegir por precio: el más barato suele costar el doble al rehacerlo.
- Los 7 criterios que importan: seniority real, dirección técnica, propiedad del código, proceso, comunicación, casos verificables y plan post-entrega.
- Red flags clásicas: 'lo hacemos en 3 semanas', sin arquitecto, sin code reviews, sin tests, contrato que no te deja el código.
- Freelance, agencia y partner estratégico resuelven cosas distintas — no son intercambiables.
- En la primera reunión, 10 preguntas concretas separan a un proveedor serio de uno que improvisa.
La mayoría de los proyectos de software que fracasan no lo hacen por mala suerte: se eligieron mal desde el inicio. Y la decisión de con quién construir suele tomarse con la información equivocada — comparando precios, plazos prometidos y demos brillantes, en vez de evaluar lo que realmente determina si un proyecto va a llegar a producción y a aguantar el paso del tiempo.
Esta guía entrega los criterios reales que usamos al recomendar partners técnicos a empresas que están eligiendo con quién construir, las señales de alerta más comunes y las preguntas concretas que tienes que hacer antes de firmar.
Por qué la mayoría se equivoca al elegir
Los proyectos que terminan mal casi siempre tienen los mismos síntomas previos: el equipo vendedor era senior pero el equipo que construyó era mucho más junior; no había arquitecto ni code reviews; los plazos eran demasiado buenos para ser ciertos; la propuesta era una sola línea por módulo sin alcance explícito; y el contrato no decía claro de quién era el código.
Esos síntomas son evitables — pero solo si sabes mirarlos antes de firmar. Casi nadie los mira porque la conversación se concentra en precio y plazo, las dos variables que más se pueden manipular en una propuesta y menos te dicen sobre el resultado real.
Los 7 criterios que sí importan
Si tuviéramos que reducir la evaluación a una lista corta, estos son los siete criterios que mejor predicen si un proyecto va a salir bien:
- Seniority real del equipo asignado: pide los CV y el % de dedicación de quienes realmente van a construir, no del vendedor.
- Dirección técnica: ¿hay un arquitecto o líder técnico involucrado en el día a día, o solo developers ejecutando?
- Propiedad del código y los datos: el contrato debe dejar claro que el código, el diseño, los repositorios y los datos son tuyos.
- Proceso con entregas incrementales: software funcionando cada 2-4 semanas en un ambiente que puedas ver, no un big bang al final.
- Comunicación: stand-ups o demos regulares, canal directo con el líder técnico, no solo con el comercial.
- Casos de éxito verificables: pide 2-3 clientes a los que puedas llamar. Si esquivan, mala señal.
- Plan post-entrega: garantía, soporte y modelo de evolución claro — no 'lo vemos después'.
6 red flags que tienes que saber detectar
Algunas señales son tan consistentes que valen como casi-rechazo automático:
- Precio muy por debajo del mercado: si los demás cotizan USD 60K y este USD 18K, el problema no es eficiencia, es alcance subdimensionado o equipo junior sin dirección.
- Plazos imposibles ('lo hacemos en 3 semanas'): plazos comprimidos artificialmente garantizan deuda técnica y reescrituras.
- Propuesta sin arquitectura: si no hay diagrama, stack ni decisiones explicadas, no hay diseño — solo intención.
- Sin code reviews, sin tests, sin observabilidad: significa que no hay calidad estructural, solo código que 'funciona en la demo'.
- Contrato que no te deja el código: si no eres dueño del repositorio, estás alquilando tu propio producto.
- Equipo vendedor senior, equipo de ejecución desconocido: el clásico 'bait and switch' del mundo de fábricas de software.
Freelance vs agencia vs partner estratégico
Los tres modelos resuelven cosas distintas y elegir el equivocado es una decisión cara. Como guía rápida:
- Freelance: bueno para piezas acotadas (una integración, un fix, un módulo aislado). Mal para construir el core operativo del negocio: sin arquitecto, sin redundancia, alto riesgo si la persona se va.
- Agencia / fábrica de software: bueno para proyectos definidos con alcance cerrado. Riesgo: el equipo asignado puede rotar y la atención se diluye entre muchos clientes paralelos.
- Partner estratégico: bueno cuando necesitas dirección técnica + construcción + evolución sostenida en el tiempo. Más caro por hora, mucho más barato por resultado cuando el problema es el core del negocio.
10 preguntas que tienes que hacer en la primera reunión
Estas diez preguntas, hechas explícitamente, separan a un proveedor serio de uno que improvisa:
- ¿Quién específicamente va a trabajar en mi proyecto y con qué dedicación?
- ¿Hay un arquitecto o líder técnico involucrado, o solo developers?
- ¿Cómo es el proceso de entregas? ¿Cada cuánto veo software funcionando?
- ¿De quién es el código, los repositorios y los datos? ¿Quedan a mi nombre desde el día uno?
- ¿Hacen code reviews? ¿Tests? ¿Qué cobertura mínima manejan?
- ¿Qué pasa si quiero cambiar de proveedor en 12 meses? ¿Está todo documentado?
- ¿Pueden darme 2-3 clientes para llamar?
- ¿Cómo manejan los cambios de alcance durante el proyecto?
- ¿Qué incluye la garantía post-entrega y por cuánto tiempo?
- Si el proyecto se atrasa, ¿cómo lo manejan en términos de costo y plazos?
Cómo evaluar una propuesta técnica
Una propuesta seria se reconoce rápido. Estas son las partes que tienen que estar — si faltan dos o más, devuelve la propuesta y pide más detalle antes de comparar precios:
- Alcance funcional por módulo, con lo que está dentro y lo que está fuera explícito.
- Arquitectura propuesta, stack y justificación de las elecciones.
- Integraciones específicas y supuestos sobre APIs externas.
- Equipo con roles, seniority y dedicación.
- Plan de entregas en sprints o hitos verificables.
- Modelo de cobro y cómo se manejan los cambios de alcance.
- Cláusulas de propiedad del código, datos y diseño.
- Plan post-entrega: garantía, soporte y evolución.
Cómo trabajamos en Loken
En Loken proponemos siempre una fase corta de descubrimiento técnico antes de cualquier propuesta de construcción. Eso ordena el alcance real, identifica riesgos y nos permite entregar un plan donde el equipo, la arquitectura y los entregables están claros desde el día uno.
El código, los datos y los repositorios son del cliente desde el inicio. Trabajamos con dirección técnica senior en cada proyecto, code reviews, tests y entregas en producción cada 2-4 semanas — porque es la única forma honesta de demostrar que el proyecto avanza.