Guía
Cómo elegir una empresa de desarrollo de software
¿Cómo elegir una empresa de desarrollo de software sin saber programar? Fijándote menos en lo que promete y más en lo que puedes comprobar. Aquí tienes nueve criterios verificables, las señales de alarma, las preguntas para la primera reunión y cuándo encaja un freelance, una agencia o una empresa pequeña especializada.
Cómo elegir una empresa de desarrollo de software: la respuesta corta
Para elegir una empresa de desarrollo de software, fíjate en cómo trabaja antes de firmar, porque así trabajará después: que pregunte por tu negocio antes de hablar de tecnología, que proponga un diagnóstico, que te dé el alcance y el presupuesto por escrito, que deje claro de quién son el código y los datos, que te enseñe avances cada poco tiempo, que use tecnología que otro equipo pueda mantener y que tenga un plan para después de la entrega. Y valora mucho que te diga «esto no te compensa» cuando sea verdad.
Casi todo eso se ve en las dos primeras reuniones y en la primera propuesta, sin necesidad de saber programar. Abajo tienes cada criterio con la forma de comprobarlo, las señales de alarma más habituales, una lista de preguntas para la primera reunión y una comparación honesta entre freelance, agencia y empresa pequeña especializada.
Nueve criterios para elegir proveedor de software (y cómo comprobarlos)
Un portafolio vistoso no garantiza que tu proyecto salga bien: lo que decide el resultado es cómo trabaja el proveedor. Estos criterios valen igual para una empresa de desarrollo de software a medida grande o pequeña, y todos se pueden verificar.
1. Entienden tu negocio antes de hablar de tecnología
Un buen proveedor pregunta primero qué quieres resolver, quién lo va a usar, cómo se hace hoy y qué pasa cuando algo sale mal. Si en la primera reunión te habla de plataformas, de la nube o de inteligencia artificial antes de entender tu proceso, está vendiendo una solución que ya traía pensada.
Cómo comprobarlo: al final de la reunión, pídele que resuma tu problema con sus palabras. Si el resumen es fiel, incluidas las excepciones que mencionaste, te ha escuchado.
2. Proponen un diagnóstico previo
Antes de presupuestar algo serio hay que ver cómo trabajáis: documentos, programas, datos y casos raros. El diagnóstico sirve para eso y para descubrir si lo que pides es lo que necesitas; a veces hace falta menos, o algo distinto, de lo que pensabas.
Cómo comprobarlo: pregunta qué necesitan ver antes de darte precio. Si la respuesta es «nada, con esto nos basta» y el proyecto no es trivial, desconfía.
3. Alcance y presupuesto por escrito
El documento que firmas debe describir qué se construye, qué queda fuera, con qué programas se conecta, qué se da por supuesto, los plazos y cómo se gestionan los cambios. Lo que no está escrito se discute después, y casi siempre a tu costa.
Cómo comprobarlo: busca en la propuesta el apartado de lo que «no incluye». Si no existe, pide que lo añadan. Qué debe llevar un buen presupuesto y cómo comparar varios lo contamos en cuánto cuesta una aplicación a medida.
4. Propiedad del código y de los datos
Que el software se haga para ti no significa que sea tuyo si el contrato no lo dice: la cesión de derechos tiene que constar por escrito, como explicamos en ese mismo artículo sobre el precio. Además, pide acceso al repositorio donde se guarda el código, a los servidores y a una exportación completa de tus datos en un formato legible.
Si el proveedor va a tratar datos personales de tus clientes o empleados, actúa como encargado del tratamiento, y el Reglamento General de Protección de Datos exige que esa relación se regule en un contrato por escrito (artículo 28). La AEPD tiene una guía con lo que debe incluir.
Cómo comprobarlo: pregunta «si mañana dejamos de trabajar juntos, ¿qué me llevo y cómo?». La respuesta debería ser concreta: código, accesos, documentación y datos.
5. Entregas frecuentes y acceso a versiones de prueba
Si no ves nada hasta el final, descubrirás los malentendidos cuando ya estén construidos. Lo sano es recibir avances cada una o dos semanas en una versión de prueba que puedas usar tú, con tus casos, y no solo ver una demostración guiada.
Cómo comprobarlo: pide el calendario de entregas y pregunta en qué fecha podrás probar algo por tu cuenta por primera vez.
6. Tecnología estándar que otro pueda mantener
No necesitas saber de tecnología para hacer la pregunta clave: ¿otro equipo podría mantener esto si vosotros desaparecéis? Con lenguajes y bases de datos muy extendidos hay muchos profesionales capaces de retomar el proyecto; un «framework propio» o una plataforma que solo conoce el proveedor te ata a él.
Cómo comprobarlo: pide la lista de tecnologías y busca cada nombre. Si hay abundante documentación y ofertas de empleo que la piden, es estándar. Pregunta también qué documentación técnica te entregan.
7. Un plan para después de la entrega
El software necesita actualizaciones de seguridad, copias, ajustes cuando cambian los programas con los que se conecta y mejoras con el uso. Pregunta quién se encarga, en qué plazo responden si algo falla y cuánto cuesta, aunque se contrate aparte. Lo detallamos en mantenimiento de software a medida.
Cómo comprobarlo: pide por escrito qué cubre la garantía, qué cubre el mantenimiento y por qué vía se avisa de una incidencia.
8. Honestidad cuando algo no compensa
Es el criterio más difícil de fingir. Un proveedor que te dice «esto lo resuelve un programa del mercado», «esta parte no merece la pena automatizarla» o «aquí la IA no va a ser fiable» está renunciando a facturarte algo, y esa es la mejor prueba de que sus recomendaciones buscan tu interés. Si dudas entre desarrollar o comprar, tienes criterios en software a medida o estándar.
Cómo comprobarlo: pregunta directamente «¿qué parte de lo que te pido no harías?». Si la respuesta es «ninguna», sospecha.
9. Referencias que puedas verificar
Los logotipos en una web y los testimonios sin apellido no demuestran mucho. Pide ver algo funcionando: un proyecto parecido al tuyo en una demostración real, aunque sea con datos ficticios, y, si es posible, hablar con algún cliente. Muchos clientes piden confidencialidad, así que no es mala señal que un caso se cuente sin nombre, siempre que puedan enseñártelo y explicarte qué hicieron, qué costó más de lo previsto y qué aprendieron.
Cómo comprobarlo: además de las referencias, confirma que la empresa existe y quién la administra; con su NIF puedes pedir una nota informativa del Registro Mercantil.
Señales de alarma al contratar un desarrollo
Ninguna es definitiva por sí sola, pero si se juntan dos o tres, sigue buscando:
- Dicen que sí a todo, sin preguntas ni matices, y todo les parece sencillo.
- Solo hablas con el comercial. Antes de firmar deberías conocer a quien va a construir tu proyecto, o al menos a quien lo dirige.
- No sabes quién programa. Subcontratar no es malo, pero debes saberlo. Y si esos terceros van a acceder a datos personales, el RGPD exige tu autorización previa por escrito.
- Prisa por firmar: descuentos que caducan esta semana o presión para empezar sin cerrar el alcance.
- La tecnología antes que el problema: te ofrecen IA, una app nativa o una plataforma concreta antes de entender qué necesitas.
- Una plataforma propia y cerrada en la que solo ellos pueden tocar nada.
- Piden accesos de administrador a todo «por si acaso», en lugar de accesos con los permisos justos para cada tarea.
- No saben explicarlo sin jerga. Si no pueden contarte lo que van a hacer en palabras llanas, tampoco sabrán explicarte qué ha fallado cuando algo falle.
Las señales propias del presupuesto, como un precio cerrado sin haber visto nada, una propuesta de una línea o el pago completo por adelantado, las repasamos en el artículo sobre el precio de una aplicación a medida.
Preguntas antes de contratar un desarrollo: la lista para la primera reunión
No hace falta hacerlas todas. Lo que importa es cómo responden: concreto y sin rodeos es buena señal; vago y lleno de «depende» sin explicar de qué, mala.
Sobre tu proyecto
- ¿Qué necesitáis ver de nuestro proceso antes de darnos un presupuesto?
- ¿Qué parte de lo que pedimos no haríais, o haríais de otra manera?
- ¿Qué meteríais en una primera versión con lo imprescindible?
- ¿Qué riesgos veis: integraciones difíciles, datos desordenados, dependencias de terceros?
Sobre cómo trabajáis
- ¿Quién trabajará en el proyecto y con quién hablaré durante el desarrollo?
- ¿Cada cuánto veré avances y cuándo podré probar algo por mi cuenta?
- ¿Cómo se gestiona un cambio de alcance a mitad del proyecto?
- ¿Con qué tecnologías lo construiríais y por qué esas?
- ¿Subcontratáis alguna parte?
Sobre lo que pasa después
- ¿De quién serán el código y los datos, y cómo accedo a ellos?
- ¿Qué cubre la garantía y qué cubre el mantenimiento?
- ¿Qué costes recurrentes tendré: servidor, licencias, uso de IA?
- Si dejamos de trabajar juntos, ¿qué me entregáis y cómo?
- ¿Puedo ver funcionando algún proyecto parecido?
Y lleva tus deberes hechos: qué problema quieres resolver, quién usará el software, con qué programas debe hablar y algunos ejemplos reales, como documentos, hojas de cálculo o capturas. Dale a cada proveedor la misma información; si no, compararás propuestas de proyectos distintos.
¿Freelance o empresa de software? Tres opciones comparadas
No hay una opción mejor en abstracto: cada una encaja con un tipo de proyecto. Te lo contamos siendo parte interesada, porque somos una empresa pequeña especializada, así que juzga tú:
| Freelance | Agencia o consultora grande | Empresa pequeña especializada | |
|---|---|---|---|
| Trato | Directo con quien programa | A través de un responsable de cuenta | Directo, con pocas personas |
| Capacidad | La de una persona | Alta: varios perfiles y equipos | Media: un equipo reducido |
| Continuidad | Depende de una sola persona | Alta, aunque el equipo puede rotar | Depende de pocas personas |
| Estructura que pagas | Mínima | Comercial, gestión y oficinas | Ligera |
| Encaja con | Proyectos acotados o mejoras sobre algo que ya existe | Proyectos grandes, muchos departamentos, requisitos corporativos | Pymes con un proceso concreto que resolver de principio a fin |
Cuándo encaja un freelance
Un buen freelance es una opción excelente para un proyecto acotado, para ampliar algo que ya funciona o si tienes a alguien dentro que pueda supervisarlo. Su riesgo es la dependencia de una persona: vacaciones, una baja o un cliente más grande. Mitígalo con el código en un repositorio a tu nombre, documentación y una pregunta directa: «¿quién te cubre si no puedes?».
Cuándo encaja una agencia grande
Si el proyecto implica a muchos departamentos, necesitas varios perfiles a la vez o tu empresa exige procesos formales de compras y seguridad, una estructura grande tiene sentido. El riesgo para una pyme es ser un cliente pequeño en su cartera: comprueba quién llevará de verdad tu proyecto y si esa persona estará en las reuniones.
Cuándo encaja una empresa pequeña especializada
Cuando tienes un problema concreto que quieres resolver de principio a fin, desde entender el proceso hasta mantener la solución, y valoras hablar con quien la construye. Su límite es la capacidad: pregunta cuántos proyectos llevan a la vez y cómo cubren una ausencia. Y desconfía de la que dice hacerlo todo; la especialización es precisamente su ventaja.
La mejor prueba: empezar por un encargo pequeño
Por muchas preguntas que hagas, la forma más fiable de saber cómo trabaja alguien es trabajar con él. Si el proyecto es grande, divídelo: empieza por el diagnóstico o por una primera versión acotada, con su propio alcance y presupuesto, y decide después si seguís.
En ese primer tramo verás lo que ninguna reunión enseña: si cumplen los plazos que dan, cómo reaccionan a un cambio, si avisan de los problemas antes de que los descubras tú y si lo que entregan funciona con tus casos reales. Si no encaja, habrás arriesgado poco. Un proveedor seguro de su trabajo no debería tener problema en empezar así.
Decide con tus casos, no con la demostración. Antes de dar por buena una entrega, pruébala con ejemplos reales de tu día a día, incluidos los raros: el pedido con veinte líneas, el cliente con dos direcciones, la factura rectificativa. Ahí se ve la diferencia entre un proveedor y otro.
Cómo trabajamos nosotros, por si quieres compararnos
Ya que te hemos dado una lista para examinar a cualquier proveedor, lo justo es contarte cómo respondemos nosotros:
- Diagnóstico. Vemos cómo trabajáis hoy y dónde se pierde el tiempo. Si un programa del mercado lo resuelve o no compensa desarrollar, te lo decimos.
- Diseño de la solución. Definimos qué construir, con qué tecnología y qué resultado esperar, con el alcance y el presupuesto por escrito.
- Desarrollo e integración. Entregas desde la primera semana, conectadas con las herramientas que ya usáis.
- Puesta en marcha y mejora. Pruebas con casos reales, seguimiento y, si lo necesitas, mantenimiento como cuota mensual.
Usamos tecnología estándar y muy extendida (React, TypeScript, Node.js, Python, PostgreSQL) y trabajamos en remoto con empresas de toda España. Entre lo que hemos construido están una plataforma que genera cursos de prevención de riesgos laborales a partir de evaluaciones de riesgos, un sistema que registra solos los pedidos y albaranes que recibe un mayorista hortofrutícola y el CRM con el que gestionamos nuestra propia empresa. En desarrollo de aplicaciones a medida tienes qué hacemos y cómo. Y si hablamos, haznos las preguntas de la lista: es la mejor forma de saber si encajamos.