Cómo elegir una empresa de desarrollo de software: 12 preguntas antes de firmar

Cómo elegir una empresa de desarrollo de software en España: las preguntas que separan a un buen proveedor de uno que alarga el proyecto y lo encarece.

Equipo de Viuzi

6 de agosto de 2026 · 11 min de lectura · Actualizado el 4 de octubre de 2026

Lo esencial

Antes de hablar con nadie conviene escribir una página con el problema, los usuarios, los sistemas actuales y el resultado esperado, para comparar propuestas sobre la misma base.
Las doce preguntas se agrupan en cuatro bloques: el equipo, el método de trabajo, el dinero y lo que queda en tus manos al terminar.
Una buena propuesta nombra a las personas del equipo, enseña avances cada dos semanas y pone por escrito el impacto de cada cambio en plazo y precio.
Según la Ley de Propiedad Intelectual, la cesión de derechos sobre el software tiene que constar por escrito y, si no fija plazo ni territorio, se limita a cinco años y a España.
Un presupuesto cerrado sin preguntas, plazos imposibles o evasivas sobre el código son señales para descartar una propuesta aunque sea la más barata.

Elegir proveedor es la decisión que más pesa en el éxito de un software a medida. Un buen equipo convierte un encargo poco definido en un producto útil. Uno inadecuado convierte un buen proyecto en meses de retrasos y facturas inesperadas. Las webs de casi todas las empresas de desarrollo prometen lo mismo, así que la diferencia hay que buscarla en las respuestas que dan a preguntas concretas.

Las doce preguntas que siguen se agrupan en cuatro bloques: el equipo, el método, el dinero y lo que queda en tus manos al terminar. Para cada una se explica qué respuesta esperar. Al final hay una tabla para comparar propuestas, un método de puntuación y las señales que deberían hacerte descartar una oferta.

Antes de hablar con nadie, define el problema

Las mejores conversaciones con un proveedor empiezan con un documento de una página escrito por ti. Cuenta qué proceso quieres mejorar, quién lo usa, qué sistemas existen hoy y qué resultado esperas. No hace falta lenguaje técnico. Con ese documento podrás comparar propuestas sobre la misma base, y verás enseguida qué empresa lo ha leído con atención y cuál responde con una plantilla.

El problema. Qué proceso falla hoy y cuánto cuesta en horas, errores o clientes perdidos.
Los usuarios. Quién usará el software, cuántas personas y desde qué dispositivos.
Los sistemas. Qué programas existen y con cuáles tendría que conectarse.
El resultado. Qué tendría que ser distinto dentro de un año para considerar que el proyecto salió bien.
Las restricciones. Fechas que no se pueden mover, presupuesto orientativo y obligaciones legales como Verifactu o el RGPD.

Sobre el equipo

1. ¿Quién va a trabajar en mi proyecto?

Pregunta por las personas concretas, su experiencia y su dedicación. Desconfía de las propuestas en las que solo hablas con un comercial y el equipo técnico aparece después de firmar. En las empresas grandes es frecuente vender con un equipo y ejecutar con otro.

2. ¿Con quién hablaré cada semana?

Necesitas una persona de referencia que entienda tu negocio y tome decisiones técnicas. Si cada consulta pasa por varios intermediarios, el proyecto se ralentiza y las respuestas llegan diluidas.

3. ¿Habéis resuelto problemas parecidos?

El proveedor no necesita conocer tu sector al detalle. Sí debería haber trabajado con integraciones, volúmenes de datos o requisitos legales comparables a los tuyos. Pide que te expliquen cómo lo hicieron y, si es posible, que te pongan en contacto con ese cliente.

Sobre el método

4. ¿Cómo será el proceso desde hoy hasta el lanzamiento?

Una empresa seria te describe sus fases y te explica qué recibes al terminar cada una y qué decisiones te corresponden. Si la respuesta es vaga, el proyecto también lo será. En cómo trabajamos puedes ver un ejemplo de proceso por fases.

5. ¿Cada cuánto veré avances reales?

Lo razonable es ver una versión funcional cada dos semanas en un entorno de pruebas que puedas usar. Esperar meses a una entrega final es la forma más segura de descubrir tarde que algo no era lo que necesitabas. La guía de Scrum fija los sprints en un mes como máximo. La mayoría de equipos trabaja con ciclos de dos semanas.

6. ¿Cómo se gestionan los cambios?

Los cambios van a aparecer en cuanto el equipo use las primeras versiones. Es buena señal, porque significa que el software se está probando de verdad. Lo importante es que cada cambio tenga por escrito su impacto en plazo y precio antes de aprobarse.

Consejo

Pregunta también cómo se prueba la calidad. Una respuesta concreta habla de pruebas automáticas que se ejecutan con cada cambio, de revisiones de código entre compañeros y de criterios de seguridad como los del estándar ASVS de OWASP. Una respuesta genérica sobre «control de calidad» dice poco.

Sobre el dinero

7. ¿El presupuesto es cerrado?

Para un primer proyecto, un precio cerrado por fases te protege. Si el proveedor solo trabaja por horas, pide al menos una estimación por fase y un límite que no se pueda superar sin tu aprobación. En cuánto cuesta un software a medida explicamos cómo leer un presupuesto.

8. ¿Qué queda fuera del presupuesto?

Alojamiento, licencias de terceros, migración de datos y formación son los olvidos más habituales. Pide que la propuesta los nombre siempre, también cuando no estén incluidos. Un presupuesto que parece barato porque omite el alojamiento y la migración acaba costando más que uno completo.

9. ¿Qué pasa después del lanzamiento?

Pregunta por la garantía, por el mantenimiento y por los tiempos de respuesta ante una incidencia. Un software sin mantenimiento envejece rápido, sobre todo cuando cambian la normativa o los sistemas con los que se conecta. Lo razonable es una garantía de corrección de errores durante unos meses y un contrato de mantenimiento con tiempos de respuesta por gravedad.

Sobre lo que es tuyo

10. ¿De quién es el código?

La respuesta correcta es que el código fuente, la documentación y la propiedad intelectual son tuyos. Comprueba que el contrato lo diga y que tengas acceso al repositorio desde el primer día. La ley española hace que este punto sea más delicado de lo que parece, como se explica en el apartado siguiente.

11. ¿Podría continuar el proyecto otro equipo?

Si mañana cambias de proveedor, otro equipo debería poder retomar el trabajo con la documentación y los tests existentes. Si la respuesta es dudosa, el riesgo de dependencia es alto.

12. ¿Cómo cumplís con el RGPD?

Tu proveedor tratará datos personales de tus clientes o empleados, así que necesitas un contrato de encargado del tratamiento y medidas de seguridad claras. La AEPD publica unas directrices para redactar ese contrato. Lo detallamos en RGPD en el desarrollo de software.

Lo que dice la ley sobre la propiedad del código

Según la Ley de Propiedad Intelectual, el autor de un programa de ordenador es la persona que lo crea. Cuando lo crea un empleado en su trabajo, los derechos de explotación pasan a la empresa que lo contrata. Cuando lo crea un proveedor externo, los derechos siguen siendo del proveedor salvo que se cedan por contrato.

Esa cesión tiene reglas precisas. El artículo 45 exige que conste por escrito. El artículo 43 añade que la falta de mención del tiempo limita la cesión a cinco años. Si tampoco se menciona el ámbito territorial, la cesión se limita al país en el que se firma. Si no se concretan las modalidades de explotación, la cesión se reduce a lo indispensable para la finalidad del contrato.

Importante

Un contrato que solo dice «el código será propiedad del cliente» puede quedarse corto. Pide que el proveedor ceda en exclusiva los derechos de explotación del código, la documentación y los diseños, para todas las modalidades de explotación, en todo el mundo y por el máximo tiempo que permita la ley, incluido el derecho a modificarlo y a encargar su mantenimiento a terceros.

Las librerías de código abierto que el software use mantienen sus propias licencias, como ocurre en cualquier proyecto moderno. Lo que conviene pedir es una lista de esas librerías con su licencia, para comprobar que ninguna obliga a publicar tu código.

Una tabla para comparar propuestas

Pasa las respuestas de cada candidato a una tabla como esta. Al ponerlas una junto a otra se ve qué propuesta concreta más y cuál deja huecos que luego pagarás tú. La columna de la derecha resume lo que debería contener una buena propuesta en cada punto:

Criterio	Qué esperar de una buena propuesta
Equipo	Nombres, perfiles y dedicación de quienes construyen el proyecto
Interlocutor	Una persona de referencia con capacidad de decisión técnica
Proceso	Fases descritas, con lo que recibes al final de cada una
Avances	Una versión que puedes probar cada dos semanas
Cambios	Impacto en plazo y precio por escrito antes de aprobarlos
Precio	Cerrado por fase, con el IVA aparte y lo excluido nombrado
Después del lanzamiento	Garantía, mantenimiento y tiempos de respuesta
Propiedad	Cesión escrita de derechos y repositorio a tu nombre desde el primer día
Continuidad	Documentación y tests que permitan cambiar de proveedor
RGPD	Contrato de encargado del tratamiento y medidas de seguridad

Puntuar en lugar de intuir

Para decidir entre dos o tres propuestas parecidas ayuda puntuar cada criterio de 1 a 5 y darle un peso según lo que más te importa. Un reparto razonable para un primer proyecto da más peso al equipo, al proceso y a la propiedad que al precio, porque un precio bajo con un mal proceso sale caro.

Propuestas que conviene pedir: 3-5
Avances que deberías ver: Cada 2 semanas
Cesión sin plazo escrito: 5 años

Cómo hablar con las referencias

Los casos de éxito de una web están escritos por el propio proveedor. Una conversación de veinte minutos con un cliente anterior dice mucho más. Pide dos o tres contactos de proyectos parecidos al tuyo, en tamaño o en tipo de problema. Prepara las mismas preguntas para todos, así las respuestas se pueden comparar.

Las preguntas más útiles se refieren a los momentos difíciles. Pregunta si el proyecto terminó en el plazo y el precio previstos. Si no fue así, pide que te cuenten qué pasó y cómo se resolvió. Pregunta cómo reaccionó el equipo ante un error en producción y cuánto tardó en resolverlo. Pregunta si las personas que empezaron el proyecto fueron las mismas que lo terminaron. Y pregunta si volverían a contratarlo para el siguiente proyecto, que es la respuesta que mejor resume todas las demás.

Si el proveedor tiene un producto propio o un proyecto público, pide que te lo enseñe funcionando. Ver el software en uso, con sus pantallas reales y su velocidad, aporta más que cualquier presentación comercial.

Señales de alarma

Algunas respuestas deberían hacerte dudar de cualquier propuesta, por atractiva que sea en precio. Ninguna demuestra por sí sola que el proveedor sea malo, pero cada una anticipa un tipo de problema que suele aparecer a mitad del proyecto, cuando cambiar de equipo ya es caro:

Un presupuesto cerrado sin haber hecho preguntas sobre tu proceso.
Plazos muy cortos para un alcance amplio, sin explicar cómo se conseguirán.
Evasivas sobre la propiedad del código o el acceso al repositorio.
Ninguna mención a pruebas, seguridad o mantenimiento.
Prisa por firmar con descuentos que caducan en pocos días.
Ningún cliente anterior dispuesto a hablar contigo.

Proveedor local o remoto

Trabajar con un equipo en España tiene ventajas prácticas: el mismo horario, contratos bajo la ley española, facturación con IVA nacional y la posibilidad de reunirse en persona en los momentos importantes. También facilita los asuntos legales del propio software, como Verifactu o la factura electrónica, que un equipo de otro país puede no conocer. Un equipo remoto bien organizado también funciona, siempre que las respuestas a las doce preguntas sean igual de claras.

En resumen

Elegir empresa de desarrollo es comprobar cómo trabaja antes de firmar. Lleva tu problema por escrito, haz estas doce preguntas a cada candidato y compara las respuestas además de los precios. Revisa con especial cuidado la cesión de derechos del contrato. Si quieres ver cómo las respondemos nosotros, puedes escribirnos o pedir un presupuesto para tu proyecto.

Preguntas frecuentes

¿Cuántas propuestas conviene pedir?

Entre tres y cinco. Con menos de tres es difícil saber qué es normal en precio y plazo. Con más de cinco, el tiempo de comparar respuestas supera lo que aporta. Mandar a todas el mismo documento de una página permite comparar sobre la misma base.

¿Es mejor una empresa grande o un equipo pequeño?

Depende del proyecto. Una consultora grande aporta capacidad para proyectos muy amplios, aunque una pyme suele pesar poco en su cartera y el equipo puede cambiar a mitad del trabajo. Un equipo pequeño y especializado suele dar más atención y continuidad. Lo decisivo es que las personas que construyen el proyecto sean las mismas que viste en la propuesta.

¿Cómo compruebo las referencias de un proveedor?

Pide dos o tres clientes con proyectos parecidos al tuyo y habla con ellos. Pregúntales si se cumplieron los plazos, cómo se gestionaron los cambios, cómo reaccionó el proveedor ante un problema y si volverían a contratarlo. Si el proveedor puede enseñarte el producto funcionando, mejor que cualquier caso de éxito en su web.

¿Qué debe decir el contrato sobre la propiedad del código?

Que el proveedor cede a tu empresa en exclusiva los derechos de explotación del código, la documentación y los diseños, para todas las modalidades de explotación, en todo el mundo y por todo el tiempo que permita la ley. La Ley de Propiedad Intelectual exige que la cesión conste por escrito y limita a cinco años y al país de la firma la que no concreta plazo ni territorio.

¿Puedo empezar con un proyecto pequeño para conocer al proveedor?

Es una de las mejores formas de elegir. Una fase de descubrimiento de dos o tres semanas con un entregable concreto, como el documento de alcance y los prototipos, muestra cómo trabaja el equipo antes de comprometer el presupuesto completo. Si el resultado no convence, el documento te sirve para pedir otras propuestas.

¿Qué pasa si el proveedor desaparece a mitad del proyecto?

Si tienes el repositorio a tu nombre, la documentación al día y pruebas automáticas, otro equipo puede retomar el trabajo con un coste razonable. Si el código está en las cuentas del proveedor y nadie más lo entiende, tendrás que empezar casi de cero. Por eso el acceso al repositorio desde el primer día es una condición y no un detalle.

Fuentes

CompartirLinkedIn X

Quién escribe