---
title: "Cómo elegir empresa de desarrollo de software a medida"
description: "Qué preguntar antes de contratar un desarrollo a medida: propiedad del código, alcance, mantenimiento, equipo real y señales de alarma en la propuesta."
canonical: "https://aullando.com/blog/como-elegir-empresa-desarrollo-software-a-medida"
last-updated: "2026-08-22"
---

# Cómo elegir empresa de desarrollo de software a medida

Elegir empresa de desarrollo a medida se parece más a contratar a un socio que a comprar una herramienta. Vas a compartir con ellos procesos internos, datos de clientes y decisiones que afectan a cómo trabaja tu equipo durante años. Esta guía es la lista con la que nosotros mismos evaluaríamos a un proveedor si estuviéramos al otro lado de la mesa.

## Primero define qué tipo de proveedor necesitas

No todos hacen lo mismo, aunque todos digan "desarrollo a medida".

| Perfil | Encaja cuando | Riesgo principal |
| --- | --- | --- |
| Freelance | Alcance pequeño y muy definido, presupuesto ajustado | Disponibilidad y continuidad si desaparece |
| Estudio pequeño (3-15 personas) | Producto o sistema interno con criterio de negocio | Capacidad limitada si tu proyecto crece mucho de golpe |
| Consultora grande | Cumplimiento estricto, integración con sistemas corporativos | Coste, capas de gestión, equipo rotatorio |
| Fábrica de software offshore | Alcance cerrado y especificado al detalle | Distancia con el negocio, coste oculto de coordinación |

Si tu problema es entender el proceso y decidir qué construir, necesitas criterio, no volumen de manos. Si el problema ya está resuelto sobre el papel, puedes optimizar por precio.

## Las diez preguntas que separan el grano de la paja

1. **¿Quién va a escribir mi código, con nombre y apellidos?** Pide conocer al equipo real, no al comercial. Si el perfil que te enseñan en la propuesta no es el que aparece en la primera reunión de trabajo, mala señal.
2. **¿Qué habéis entregado que se parezca a esto y qué salió mal?** La segunda parte importa más. Un proveedor que no recuerda ningún error o no ha entregado nada difícil o no está siendo sincero.
3. **¿Cómo trabajáis el descubrimiento?** Si empiezan a picar código sin haber visto tu proceso funcionando, vas a pagar dos veces.
4. **¿De quién es el código?** Debe ser tuyo, en tu repositorio, desde el primer commit. Sin condiciones.
5. **¿Dónde se despliega y quién tiene las llaves?** Cuentas de infraestructura a tu nombre, con el proveedor invitado. No al revés.
6. **¿Qué pasa si os dejo de contratar mañana?** La respuesta correcta incluye documentación, traspaso y un periodo de acompañamiento. Si la respuesta es vaga, estás firmando una dependencia.
7. **¿Cómo se factura el cambio de alcance?** Que exista un mecanismo claro y barato para cambiar de opinión, porque vas a cambiar de opinión.
8. **¿Qué mantenimiento ofrecéis y con qué tiempos de respuesta?** Por escrito, con horario y canal.
9. **¿Cómo lleváis la protección de datos?** Contrato de encargado de tratamiento, dónde viven los datos, quién accede y con qué registro.
10. **¿Qué me vais a decir que no?** Un proveedor que acepta cualquier idea sin discutirla no te está aportando criterio.

## Cómo leer una propuesta

Una propuesta útil tiene alcance, supuestos, fases, entregables, precio por fase y lo que queda fuera. Ese último apartado es el que más información da. Si no existe, todo está dentro hasta que descubras que no.

Presta atención a los supuestos. Frases como "se asume que el cliente proporciona acceso a la API del ERP en la primera semana" son las que después explican los retrasos. Si un supuesto no lo puedes cumplir, dilo antes de firmar.

## Prueba pequeña antes de comprometer todo

La mejor forma de evaluar a un proveedor es trabajar dos semanas con él. Un bloque corto y pagado, con un entregable real: un prototipo navegable, una integración funcionando, una migración de prueba. Ahí ves lo que ningún portfolio te enseña.

- Cómo preguntan cuando algo no está claro.
- Si avisan de los problemas pronto o el viernes a última hora.
- La calidad de lo que entregan cuando nadie está mirando el detalle.
- Si tu equipo entiende lo que dicen.

Si esas dos semanas van bien, la decisión grande deja de ser una apuesta.

## Banderas rojas

- Presupuesto sin desglose y descuento inmediato al dudar.
- Cero preguntas sobre tu proceso en la primera reunión.
- Prometen plazos antes de saber qué integraciones hay.
- Se niegan a que el repositorio sea tuyo.
- Todo el conocimiento vive en una persona a la que no puedes hablar.
- Referencias que no puedes llamar.

## Banderas verdes

- Te reducen el alcance de la primera versión.
- Te enseñan un proyecto que se torció y qué aprendieron.
- Explican en tu idioma, sin jerga, y tu jefe de operaciones lo entiende.
- Escriben decisiones en documentos cortos que después puedes releer.
- Te dan acceso al trabajo en curso desde la semana uno.

## Qué necesitas tener tú preparado

Elegir bien también depende de lo que llevas a la reunión:

- Una persona de tu lado con capacidad de decidir y una hora semanal libre.
- El proceso descrito en una página, aunque sea a mano.
- Quién administra cada sistema que hay que integrar.
- Qué considerarías un éxito a los tres meses, con un número.

Con eso, cualquier proveedor decente te puede dar una horquilla realista. Las horquillas del mercado español están en [cuánto cuesta un software a medida](/blog/cuanto-cuesta-software-a-medida), y lo que conviene cerrar por contrato lo detallamos en [mantenimiento y propiedad del código](/blog/mantenimiento-y-propiedad-del-codigo).

## Cómo trabajamos nosotros

Somos un estudio pequeño. Eso significa que hablas con quien construye y que decimos que no cuando un proyecto no encaja. Empezamos con una llamada de descubrimiento, seguimos con un documento de alcance con lo que queda fuera y entregamos por bloques de dos semanas con algo usable al final de cada uno. El código es tuyo desde el primer día.

Puedes ver ejemplos en [desarrollos a medida](/a-medida) o contarnos tu caso en [contacto](/contacto).

## Preguntas frecuentes

**¿Es mejor un freelance o un estudio?** Un freelance encaja en alcances pequeños y muy definidos. Para sistemas que van a durar años, la continuidad de un equipo pesa más que el precio hora.

**¿Cuánto debería durar la selección?** Dos o tres semanas. Tres conversaciones, dos propuestas comparables y, si puedes, una prueba pagada de dos semanas.

**¿Hay que exigir el código fuente?** Sí, siempre. En tu repositorio y con licencia de uso plena, desde el primer commit.

**¿Y si el más barato es el que más me convence?** Adelante, siempre que el desglose sea creíble y el alcance sea el mismo que el de los demás. Barato con alcance distinto no es barato.