Elegir una empresa de desarrollo de software es una decisión con la que vas a convivir 2-5 años. Un buen partner te ahorra tiempo y dinero. Uno malo te deja una deuda técnica que acaba costando más que el propio proyecto. Los datos del sector apuntan a que el 37% de los proyectos IT fracasa por haber elegido mal al proveedor, no por problemas técnicos.
Este artículo te da 10 criterios concretos que recomendamos para evaluar a un partner de desarrollo. Nada de consejos abstractos del tipo «comprueba su reputación», sino preguntas, métricas y señales de alarma concretas. Y un checklist para la decisión final.
10 criterios para elegir una empresa de desarrollo de software
Qué comprobar: abre 3-5 proyectos del portfolio y mira si siguen funcionando (el 30% de los proyectos de portfolio del mercado están muertos). Pásalos por Google PageSpeed Insights. Una puntuación de 90 o más significa que la parte técnica está en orden. Si sale 40-60, piénsatelo dos veces.
Señal de alarma: una empresa que «trabaja con todo»: React, Angular, Vue, PHP, Python, Java, Go, C# y encima WordPress. Un equipo de 10 personas no puede ser igual de bueno en 8 stacks. La especialización es señal de experiencia.
Un buen proceso incluye demos periódicas (cada 1-2 semanas), acceso al gestor de tareas (Jira, YouTrack, Linear), informes semanales de avance, registro transparente de horas (si trabajas en T&M), y code review y pruebas integrados en el proceso.
Pide a la empresa que te enseñe un tablero real de su gestor de tareas (con los nombres de los clientes ocultos). Te dice más de su proceso que cualquier presentación comercial.
Señal de alarma: en la preventa hablas con una persona (un comercial) y, en cuanto firmas, te pasan a otra (un account manager) que no sabe nada del proyecto. O peor, a un desarrollador que no habla tu idioma y se comunica a golpe de Google Translate.
Hay dos modelos de precio. Precio cerrado (un único precio para todo el proyecto): funciona cuando el alcance está definido y es poco probable que cambie. Time & Material (pagas por horas): funciona cuando el proyecto es iterativo y los requisitos van a evolucionar. Precio cerrado no significa más barato: el proveedor mete los riesgos en el precio (normalmente un +20-30%).
La regla de los tres presupuestos: pide presupuesto a 3-5 empresas. Descarta el más barato (recortan en calidad o no han entendido el proyecto) y el más caro (sobreestiman o inflan el precio). Elige entre los del medio.
Otras fuentes: el perfil de la empresa en Clutch.co, las valoraciones en plataformas del sector como GoodFirms y los casos publicados con cifras reales.
Señal de alarma: «en tu proyecto trabajará un equipo de 15 personas» para un proyecto de 13.500 €. Eso significa que cada una le dedicará 2 horas a la semana, no que 15 personas vayan a trabajar en él a tiempo completo.
Checklist para elegir una empresa de desarrollo
Imprímelo y úsalo para evaluar a cada candidato.
Portfolio y experiencia
[ ] Al menos 3 proyectos parecidos al mío
[ ] Los proyectos del portfolio están en línea y accesibles
[ ] Puntuación de PageSpeed superior a 80 en los proyectos del portfolio
[ ] El stack encaja con mi proyecto
[ ] Especialización clara (no «hacemos de todo»)
Proceso y comunicación
[ ] Un proceso de desarrollo claro (Scrum/Kanban)
[ ] Demos periódicas (cada 1-2 semanas)
[ ] Acceso al gestor de tareas
[ ] Responden dentro de la jornada
[ ] Hacen preguntas para aclarar (en lugar de dar un precio a la primera)
Contrato y dinero
[ ] Transferencia del código fuente y de los derechos
[ ] Periodo de garantía (1-3 meses)
[ ] Pagos por etapas (sin 100% por adelantado)
[ ] Precios transparentes (precio cerrado, o T&M con informes)
[ ] Un NDA si hace falta
Equipo y soporte
[ ] Conozco a las personas concretas que harán el trabajo
[ ] Hay un QA dedicado
[ ] Hay un SLA de soporte
[ ] Hay documentación y transferencia de conocimiento
[ ] He llamado a 1-2 clientes y recomiendan la empresa
Tipos de partner de desarrollo: quién encaja con tu proyecto
Freelance
Tarifa: normalmente unos 25-90 € la hora. Encaja en: tareas pequeñas (una landing, una mejora, una integración), tareas con una especificación clara, presupuestos de menos de 9.000 €.
Ventajas: barato, arranque rápido. Inconvenientes: sin respaldo (si se pone enfermo, el proyecto se para), sin proceso (la calidad depende de cómo se levante ese día), sin garantías legales reales (un contrato con un freelance protege poco), sin soporte después del proyecto.
Estudio pequeño (5-15 personas)
Tarifa: normalmente unos 45-135 € la hora. Encaja en: proyectos medianos (9.000-90.000 €), MVP de startups, webs y aplicaciones corporativas.
Ventajas: hay proceso, pero flexible (sin burocracia), el equipo se conoce, y el CEO o el CTO suele implicarse personalmente en el proyecto. Inconvenientes: capacidad limitada (1-3 proyectos en paralelo), un stack acotado (que también puede ser una ventaja).
Empresa grande (más de 50 personas)
Tarifa: normalmente unos 90-225 € la hora. Encaja en: proyectos grandes (más de 90.000 €), soluciones enterprise, contratos a largo plazo.
Ventajas: procesos formales y SLA, una amplia cantera de especialistas, estabilidad. Inconvenientes: burocracia (una aprobación para cada detalle), los gestores van y vienen (rotación), tu proyecto es uno de los 20-30 que llevan en paralelo.
El mejor partner no es ni el más grande ni el más barato. Es aquel para el que tu proyecto importa: lo bastante pequeño para dedicarle atención de verdad y con la experiencia suficiente para no cometer errores de principiante.
5 errores al elegir una empresa de desarrollo
Error 1: elegir por precio
El proveedor más barato acaba saliendo el más caro. Ahorrar 5.400 € en desarrollo se convierte en perder 13.500 € en rehacer trabajo cuando el proyecto se entrega con errores y un código ilegible. Busca el equilibrio entre precio, calidad y proceso, no el precio más bajo.
Error 2: no revisar el portfolio
Capturas bonitas en una web ≠ proyectos reales. Abre las webs del portfolio. Comprueba su velocidad, si funcionan siquiera, la versión móvil. Si la mitad de los proyectos están caídos o dan errores, eso ya te dice algo.
Error 3: empezar sin especificación
«Empecemos y ya iremos definiendo los requisitos sobre la marcha» es la receta para un desastre de presupuesto. Sin una especificación de requisitos detallada no hay forma de estimar el coste, el plazo ni las expectativas. Los proyectos sin especificación acaban costando un 30-50% más.
Error 4: no implicarte
«Ya he pagado, que trabajen ellos». No. El desarrollo es un trabajo conjunto. Si te saltas las demos, no das feedback sobre las maquetas y no revisas los resultados intermedios, tendrás un producto que técnicamente funciona pero no resuelve tu problema de negocio.
Error 5: no pensar en el después
El desarrollo es el 50% de la historia. Tras el lanzamiento necesitas soporte, mejoras y escalado. Si la empresa no ofrece soporte, o lo cobra a precio de oro, acabarás con un producto bonito que empieza a caerse a pedazos seis meses después.
Cómo trabajamos en March Code
Somos un estudio de más de 10 especialistas y aceptamos proyectos desde 8.900 €. Nuestro cliente típico es un CEO o CTO que necesita un partner fiable de desarrollo de software a medida, no «una web en 3 días».
Nuestro proceso: una consulta gratuita (30 min) → una propuesta con un rango de precio → una especificación detallada (se paga aparte y se descuenta del proyecto) → desarrollo en sprints de 2 semanas con demos → lanzamiento → 30 días de soporte en garantía → un SLA para el soporte continuo.
Un ejemplo de nuestro trabajo: el caso ProControl, un sistema de gestión de la producción que construimos en 4 meses, desde el análisis de los procesos de negocio hasta la puesta en producción.
Preguntas frecuentes
¿Cuántas empresas debería valorar?
Con 3-5 basta. Menos te da pocos datos para comparar. Más alarga la selección durante meses. Pide propuestas a 5 empresas, ten 3 llamadas en detalle y elige un finalista. Todo el proceso lleva 2-3 semanas. No dediques a elegir más tiempo del que llevaría el primer sprint de desarrollo.
Precio cerrado o Time & Material: ¿cuál elijo?
El precio cerrado funciona cuando el alcance está definido, la especificación está lista y los cambios son poco probables. Ejemplo: una landing, una web corporativa con un diseño claro. Time & Material funciona cuando el proyecto es iterativo y los requisitos van a evolucionar. Ejemplo: el MVP de una startup, un CRM para un proceso de negocio complejo. Una opción híbrida: la primera fase (especificación + diseño) a precio cerrado y después el desarrollo en T&M con un presupuesto mensual. Así se reduce el riesgo para ambas partes.
¿Cómo controlo al proveedor durante el desarrollo?
Tres herramientas: 1) una demo cada 2 semanas, para ver avances reales y no informes abstractos; 2) acceso al gestor de tareas, para ver quién trabaja en qué y cuánto tiempo lleva; 3) acceso al repositorio (GitHub/GitLab), para que tu persona técnica pueda revisar la calidad del código. Si el proveedor se niega aunque sea a una de las tres, es una señal de alarma.
¿Qué hago si el proveedor no cumple los plazos?
Primero, averigua por qué. Si el alcance creció (añadiste funciones), no es culpa del proveedor. Si la causa es cómo se organiza el trabajo, déjalo por escrito y exige un plan de recuperación concreto: no «intentaremos ir más rápido», sino «estas son las tareas, estas las fechas y este el responsable». Si los retrasos son sistemáticos (3 o más sprints seguidos), es motivo para rescindir el contrato. Por eso importan los pagos por etapas: nunca pagas de más por trabajo que no se ha hecho.
¿Necesito una persona técnica de mi lado?
Es muy recomendable en proyectos de más de 27.000 €. Puede ser un CTO interno, un consultor técnico externo o un CTO as a Service. Su trabajo: revisar las decisiones de arquitectura, hacer code review, controlar la calidad y participar en la aceptación. A un consultor le bastan unas pocas horas a la semana: un seguro barato frente a un código que parece bueno pero no funciona.
¿Puedo cambiar de proveedor a mitad de proyecto?
Técnicamente, sí. En la práctica, es doloroso y caro. Un proveedor nuevo pasará 2-4 semanas entendiendo el código de otro (y te dirá que «hay que reescribirlo todo», lo que en el 70% de los casos es una exageración). Cambiar cuesta un 20-40% del presupuesto restante del proyecto. Para reducir el riesgo: asegúrate de que el contrato cubre la entrega del código y la documentación, exige un código limpio y comentado y no pagues nunca el 100% por adelantado.
