Cómo contratar un estudio de ingeniería de software: checklist definitiva

Contratar el estudio de ingeniería equivocado es uno de los errores más caros que puede cometer una empresa no-técnica en 2026. No porque el desarrollo en sí sea caro, sino porque un mal encaje cuesta seis meses y un producto que hay que reconstruir.

Esta checklist resume las preguntas, señales y cláusulas que deberías revisar antes de firmar.

Antes de hablar con nadie: tu propia claridad

Antes de evaluar proveedores, conviene tener claro internamente:

• Qué problema estás resolviendo, no solo qué software quieres.
• Quién va a ser dueño del producto a nivel de negocio.
• Qué presupuesto orientativo tienes (al menos una horquilla).
• Qué plazo es real y qué plazo es deseable.
• Qué nivel de riesgo puedes asumir.

Sin estas cinco respuestas, cualquier comparación entre proveedores será imprecisa.

Las 12 preguntas que separan buenos de malos proveedores

1. ¿Cuántos proyectos activos tenéis ahora mismo?

Respuestas concretas con número, no “varios”. Muchos estudios que se venden como “boutique” tienen 20 proyectos activos con equipos diluidos.

2. ¿Quiénes van a trabajar en el mío? Nombres, seniority, dedicación.

Si no te pueden dar nombres hasta después de firmar, es un problema. Los mejores estudios asignan el equipo como parte de la propuesta.

3. ¿Puedo hablar con un cliente actual —no pasado— que esté en mitad de proyecto?

Los testimonios cerrados y pulidos de la web ayudan poco. Una conversación de 20 minutos con un cliente vivo revela más que cinco páginas de casos de estudio.

4. ¿Me enseñáis código real que habéis escrito?

Un estudio serio no tiene problema en mostrar fragmentos de código —con permiso del cliente— para que evalúes calidad técnica.

5. ¿Cómo gestionáis cambios de alcance?

Respuestas tipo “ajustamos presupuesto” son vagas. Busca: “Los cambios pequeños entran en iteración. Los cambios grandes se evalúan con X proceso y se re-priorizan contra el backlog.”

6. ¿Qué tests automatizados escribís por defecto? ¿Cuál es vuestro CI/CD estándar?

Si la respuesta es “depende del proyecto”, en la práctica significa “cuando sobra tiempo”. Un estudio maduro tiene valores por defecto claros.

7. ¿Cómo documentáis decisiones?

ADRs (Architecture Decision Records), Notion, wiki viva, commits autoexplicativos. Da igual la herramienta, pero debería haber un sistema.

8. ¿Qué hacéis si descubrís que algo está técnicamente mal pensado a mitad de proyecto?

Un buen estudio plantea el problema, propone alternativas y deja la decisión al cliente. Un mal estudio ejecuta la mala idea “porque es lo que se pidió”.

9. ¿Cómo trabajáis la seguridad?

Autenticación, gestión de secretos, cifrado, revisión de dependencias, tratamiento de datos sensibles. Si no hay proceso definido, asume que está mal.

10. ¿Qué propiedad intelectual queda para mí?

El código debería ser tuyo sin reservas al cerrarse el proyecto. Cualquier matiz aquí —licencias, librerías propias no liberables, IP compartida— debe estar por escrito desde el inicio.

11. ¿Qué pasa si necesito desvincularme a mitad?

Cláusulas de salida razonables, documentación entregable, traspaso técnico. Un estudio confiado en su producto no tiene miedo a que te vayas.

12. ¿Cuánto cuesta el primer año de mantenimiento?

Si no lo tienen calculado desde el principio, probablemente no han pensado en el día después del lanzamiento.

Banderas rojas

Elementos que, casi sin excepciones, correlacionan con proyectos que terminan mal:

• Presupuesto redondo sin desglose.
• Plazos demasiado cortos para el alcance.
• Promesa de “precio cerrado” sin haber hecho descubrimiento.
• Comunicación solo a través de comercial durante todo el proyecto.
• Sin Tech Lead o arquitecto identificado.
• “Podemos hacer cualquier cosa en cualquier tecnología” — señal de equipo no especializado.
• Rechazo a hablar con clientes actuales activos.
• Subcontratación opaca a terceros no conocidos.

Uno solo de estos puede explicarse. Dos o más, no compensa el riesgo.

Señales verdes

Lo contrario también es cierto. Buenas señales:

• Hacen preguntas incómodas antes de ofertar.
• Te dicen honestamente “eso no deberías construirlo todavía”.
• Tienen opinión técnica con argumentos, no solo lista de tecnologías.
• Proponen fases de descubrimiento antes de desarrollar.
• Se implican en métricas y objetivos de negocio, no solo en entregables.
• Comparten cómo trabajan: rituales, cadencias, ejemplos reales.

Cláusulas contractuales clave

Si el presupuesto y la conversación van bien, el contrato es donde se juega lo que no se habla. Revisa explícitamente:

• Titularidad del código y la propiedad intelectual al 100%.
• Confidencialidad bidireccional.
• Cláusula de no competencia razonable si aplica.
• SLA y tiempos de respuesta si hay soporte.
• Penalizaciones y compensaciones en caso de incumplimiento.
• Condiciones de salida y transferencia de conocimiento.
• Condiciones de cambio de alcance.
• Protección de datos si manejáis datos personales (RGPD, DPA firmado).

Estos puntos no están para desconfiar, están para proteger a ambas partes cuando las cosas inevitablemente se tuerzan.

Cómo evaluar el encaje humano

Más allá de lo técnico y lo contractual, hay un factor decisivo: ¿vas a disfrutar trabajando con ellos seis meses?

• ¿Te sientes escuchado o vendido?
• ¿Preguntan antes de proponer o proponen sin preguntar?
• ¿Explican las cosas técnicas hasta que las entiendes o te hacen sentir torpe?
• ¿Dicen “no” cuando toca o solo asienten?
• ¿Se implican en tu negocio o solo en sus entregables?

La respuesta a estas preguntas predice más sobre el éxito del proyecto que cualquier comparativa técnica.

---

En Everglow nos gusta que los clientes nos hagan todas estas preguntas —y muchas otras— antes de trabajar juntos. Si quieres empezar esa conversación con nosotros, escríbenos.