¿Cómo elegir una empresa de desarrollo de software?
Según Mesterséges Intelligencia Központ Kft., empresa de desarrollo de software con sede en Budapest, una buena elección depende de tres preguntas: si el desarrollador entiende el objetivo, si su oferta es verificable y de quién serán el código y el sistema tras la entrega.
En resumen: describa primero el objetivo y los requisitos imprescindibles, y solo después pida ofertas. Conviene pedir ver trabajo que funcione, un proceso transparente y acceso al código; las ofertas deben compararse sobre la misma especificación detallada y, a ser posible, a partir del tamaño medido. En el contrato también deben quedar fijados el código fuente y los derechos de uso, la confidencialidad, la corrección de errores, la operación y la forma de salida.
Primero el objetivo: ¿qué tiene que hacer el software?
La mayoría de las malas elecciones no empiezan en el desarrollador, sino en un encargo poco claro. Si no está por escrito qué tiene que hacer el software, cada oferta significará algo distinto, y no habrá con qué medir ni el precio ni el trabajo terminado. No hace falta una especificación terminada (un buen desarrollador ayuda a redactarla), pero conviene pensar de antemano en algunas cosas:
- Objetivo: qué problema resuelve el software y en qué se notará que ha tenido éxito.
- Usuarios: quiénes lo utilizarán: empleados internos, clientes o socios.
- Requisitos imprescindibles: aquello sin lo que no puede ponerse en marcha, separado de los elementos del tipo «estaría bien que».
- Sistemas existentes: con qué tiene que conectarse (ERP, CRM, tienda online, programa de facturación, banco).
- Datos: qué datos trata, incluidos los datos personales.
- Condiciones: si hay un plazo fijo, normas internas o requisitos de alojamiento o de seguridad.
Conviene decidir también si hace falta un desarrollo a medida o si basta con un producto estándar, o quizá con un producto estándar junto con una extensión a medida. En ello ayuda el artículo ¿Software a medida o solución estándar?.
Lista corta: ¿a quién conviene dirigirse?
No hace falta dirigirse a muchas empresas; unos pocos candidatos elegidos con cuidado son mejores que muchas ofertas superficiales. Los criterios para acotar la lista:
- Trabajos similares: si ya ha construido un sistema de tamaño y naturaleza similares: software empresarial, una tienda online, una aplicación móvil, una integración de IA.
- Encaje tecnológico: si trabaja con las tecnologías a las que deben conectarse los sistemas existentes.
- Escala: si la capacidad de la empresa se ajusta al proyecto; un sistema grande requiere varias especialidades, y una tarea pequeña, menos.
- Idioma y disponibilidad: si puede coordinarse con ustedes en su idioma y en su franja horaria.
Comprobación de trabajos y referencias
La prueba más sólida es el software que funciona. Pida a los candidatos que muestren un sistema que se pueda probar y que expliquen con exactitud cuál fue su propia aportación. Muchos trabajos para clientes están protegidos por la confidencialidad, por lo que no siempre se pueden dar nombres; en ese caso, una descripción anonimizada, una demostración o los productos propios de la empresa también dicen mucho.
Si un antiguo cliente da referencias, conviene hacer preguntas concretas: si se respetó el alcance acordado, cómo se gestionaron los cambios y los errores, si recibió el código fuente y si siguen trabajando juntos. Un genérico «quedamos satisfechos» dice poco; que el cliente siga explotando el sistema con ellos después de la entrega dice mucho.
Conversación técnica
Conviene mantener una conversación técnica con cada candidato, a ser posible con la presencia de un técnico también por su parte. No importa lo seguras que suenen las respuestas, sino si el desarrollador hace preguntas y nombra los riesgos. Buenas preguntas:
- ¿Cómo lo abordarían y cuál sería la primera etapa?
- ¿Cómo conectarían nuestros sistemas existentes y qué necesitan saber de ellos?
- ¿Cómo hacen las pruebas y quién decide que una parte está terminada?
- ¿Quién trabajará en el proyecto y quién será nuestra persona de contacto?
- ¿Dónde funcionará el sistema y quién es responsable de las actualizaciones de seguridad?
- Si también habrá inteligencia artificial: ¿qué datos van adónde y qué ocurre si la IA se equivoca?
Es una señal de alarma que un candidato dé un precio y un plazo exactos sin hacer preguntas, ya después de la primera conversación.
Proceso y comunicación
En el desarrollo de software, las sorpresas rara vez nacen en el código, y mucho más a menudo en la comunicación. Por eso conviene preguntar cómo verá usted el avance sobre la marcha. Los rasgos de una buena práctica:
- Desarrollo por etapas: el trabajo se divide en etapas y, al final de cada una, se presenta software que funciona, no solo un informe.
- Acceso al código: el cliente ve el repositorio de código desde el primer día, y no lo recibe solo en la entrega.
- Lista de tareas trazable: las tareas, los errores y los cambios se ven en un registro común.
- Persona de contacto estable: hay una persona que conoce el proyecto y puede tomar decisiones.
- Gestión de cambios: la necesidad nueva o modificada se describe, se mide o se estima, y solo entra en el trabajo tras su aprobación.
Comparación de las ofertas
Dos ofertas solo pueden compararse si se refieren al mismo alcance. Por eso, todos los candidatos deben recibir la misma descripción detallada; pídales que indiquen para qué funciones y para qué tamaño han dado el precio. Si el desarrollador mide el tamaño funcional del software con un método normalizado, por ejemplo en puntos de función COSMIC, el tamaño puede verificarse a partir de la misma especificación; el método se presenta en el artículo ¿Qué es el punto de función COSMIC?.
Si hay una gran diferencia entre dos ofertas, conviene hacer estas preguntas:
| Pregunta | Qué revela |
|---|---|
| ¿Para qué tamaño y para qué funciones es el precio? | si han valorado el mismo alcance |
| ¿Qué figura como partida aparte? | si están incluidas la integración, la migración de datos, los gráficos y la operación |
| ¿Con qué requisitos no funcionales han contado? | rendimiento, seguridad, accesibilidad |
| ¿Cómo gestionan los cambios? | qué ocurre si surge una nueva necesidad sobre la marcha |
| ¿Cómo funciona la corrección de errores tras la entrega? | qué cubre la tarifa y qué se considera trabajo adicional |
| ¿De quién será el código fuente y qué derechos obtenemos? | si otro puede continuar con el sistema |
| ¿La facturación es a precio cerrado o según el esfuerzo? | quién asume el riesgo del alcance |
El precio cerrado funciona bien si el alcance está fijado punto por punto; la facturación según el esfuerzo es más flexible, pero el riesgo del alcance recae en el cliente. En ambos casos, lo importante es que el alcance sea medible y pueda seguirse. Cómo fijamos nosotros los precios se describe en la página Precios.
Los puntos esenciales del contrato
El contrato es lo que cuenta en caso de conflicto o de una situación imprevista. Lo que sigue es información, no asesoramiento jurídico: conviene que un abogado revise también el contrato.
Código fuente y derechos de uso
La ley húngara de derechos de autor (Ley LXXVI de 1999, en húngaro) protege los programas de ordenador, tanto en código fuente como en código objeto, como obras protegidas por derechos de autor (artículo 1, apartado 2, letra c)), y establece que los derechos patrimoniales sobre el software son transmisibles (artículo 58, apartado 3). Por tanto, el cliente o bien adquiere los derechos patrimoniales, o bien recibe una licencia de uso; las dos cosas no son lo mismo.
Algunas normas por las que importa una redacción precisa: el contrato de licencia de uso solo otorga un derecho exclusivo si así se estipula expresamente (artículo 43, apartado 1); si el contrato no especifica las modalidades y el alcance del uso, la licencia se limita a lo imprescindible para la finalidad del contrato (artículo 43, apartado 5); si el contenido no es inequívoco, debe adoptarse la interpretación más favorable al autor (artículo 42, apartado 3); y el licenciatario solo puede conceder una licencia a un tercero con el permiso expreso del autor (artículo 46, apartado 1). Por eso conviene dejar por escrito:
- la entrega del código fuente completo y de la documentación, también por etapas;
- si el cliente adquiere los derechos patrimoniales o qué alcance tiene la licencia que recibe: si es exclusiva, si permite modificaciones, si puede cederse a terceros;
- que el desarrollador dispone de los derechos sobre el código escrito por sus empleados y subcontratistas;
- la lista y las licencias de los componentes de código abierto y de terceros utilizados.
Confidencialidad (NDA)
Si la idea o los datos empresariales son confidenciales, conviene firmar un acuerdo de confidencialidad (NDA) antes de entrar en detalles. Deje fijado en él qué se considera información confidencial, quién puede conocerla, cuánto dura la confidencialidad y qué ocurre con los materiales al final del trabajo.
Corrección de errores y garantía
El contrato debe establecer qué se considera un error (una desviación respecto al requisito acordado), cómo se desarrolla la prueba de aceptación, qué niveles de gravedad existen y con qué rapidez reacciona el desarrollador en cada nivel. Deje fijado también durante cuánto tiempo corrige gratuitamente los errores que quedaron ocultos en la entrega y qué se considera ya evolución del sistema.
Operación y SLA
Si el desarrollador también se encarga de la operación del sistema tras la entrega, un acuerdo de nivel de servicio (service level agreement, SLA) establece las condiciones: la disponibilidad comprometida, la forma de notificar las incidencias, los tiempos de reacción y de resolución según la gravedad, las ventanas de mantenimiento, las copias de seguridad y los informes. Lo que no está por escrito no puede exigirse en caso de conflicto.
Plan de salida
El plan de salida responde a la pregunta de qué ocurre si no se continúa con el desarrollador, ya sea por insatisfacción o porque el desarrollador deja de existir. Sus elementos:
- documentación actualizada sobre la instalación, la arquitectura y la operación;
- el repositorio de código, el alojamiento, el dominio y las cuentas en la nube a nombre del cliente o, al menos, con acceso del cliente;
- un procedimiento ordenado para la entrega de las contraseñas y las claves de acceso;
- la posibilidad de exportar los datos en un formato estándar;
- la cooperación en el traspaso a un nuevo desarrollador.
Protección de datos: el contrato de encargo del tratamiento
Si el desarrollador accede a datos personales durante el trabajo (por ejemplo, porque se encarga de la operación del sistema o hace pruebas con datos reales), según el RGPD suele tener la condición de encargado del tratamiento, y con él hace falta un contrato de encargo del tratamiento por escrito (artículo 28 del RGPD). Este debe estipular, entre otras cosas, que trata los datos únicamente siguiendo las instrucciones documentadas del cliente, garantiza la confidencialidad y la seguridad, solo recurre a otro encargado con autorización, suprime o devuelve los datos al finalizar el servicio y permite las auditorías.
Prácticas de seguridad
La seguridad no puede añadirse al software a posteriori, por lo que conviene preguntar cómo trabaja el desarrollador con ella. Un buen punto de partida es el OWASP Top 10, la lista ampliamente conocida de los riesgos de seguridad más críticos de las aplicaciones web; la edición vigente es la OWASP Top 10:2025 (comprobado el 17 de octubre de 2026). En los tres primeros puestos figuran el control de acceso defectuoso, la configuración de seguridad incorrecta y los fallos de la cadena de suministro de software. Pregunte:
- ¿Cómo gestionan los permisos y cómo comprueban que un usuario solo vea sus propios datos?
- ¿Cómo actualizan las bibliotecas externas que utilizan y cómo saben si una de ellas es vulnerable?
- ¿Dónde guardan las contraseñas y las claves, y quién tiene acceso a ellas?
- ¿Hay revisión de código (code review) y pruebas automáticas?
- ¿Cómo se hacen las copias de seguridad y han probado ya a restaurar alguna?
¿Freelance o empresa de desarrollo?
Ambas opciones pueden ser una buena elección; la cuestión es lo grande que es la tarea y cuánto tiempo va a durar.
| Criterio | Freelance | Empresa de desarrollo |
|---|---|---|
| Comunicación | directa, con una sola persona | a través de una persona de contacto, con varios especialistas |
| Especialidades | los conocimientos de una persona | varias especialidades: interfaz, backend, móvil, operación, pruebas |
| Sustitución | en caso de enfermedad o marcha, el trabajo se detiene | el equipo puede asumir el trabajo de unos y otros |
| Capacidad | para tareas más pequeñas y bien delimitadas | para sistemas más grandes y trabajo en paralelo |
| Contrato | directamente con el profesional | con la empresa, que responde del trabajo del equipo |
| Operación a largo plazo | depende de la disponibilidad del freelance | puede asumirse de forma organizada |
Un freelance encaja bien con una tarea bien delimitada, sobre todo si el cliente tiene su propio responsable técnico, que dirige y recibe el trabajo. Si el sistema forma parte del funcionamiento diario de la empresa, requiere varias especialidades y va a funcionar durante años, la empresa de desarrollo supone por lo general un riesgo menor. El plan de salida y la entrega del código fuente son igual de importantes en ambos casos.
Señales de alarma
- Un precio y un plazo exactos ya después de la primera conversación, sin preguntas.
- No hay especificación escrita, o la oferta no dice a qué se refiere.
- El cliente no puede ver el código y solo lo recibiría en la entrega.
- Una respuesta vaga sobre quién trabajará en el proyecto.
- No está claro de quién será el código fuente ni qué derechos obtiene el cliente.
- Reticencia a firmar el contrato de encargo del tratamiento o el acuerdo de confidencialidad.
- No hay ningún trabajo que funcione y pueda mostrarse.
Lista de comprobación
| Pregunta | Correcto si |
|---|---|
| ¿Están por escrito el objetivo y los requisitos imprescindibles? | hay una descripción breve que todos entienden igual |
| ¿Hemos visto trabajo que funcione? | hemos probado al menos un sistema similar |
| ¿Entienden la tarea? | han hecho preguntas y han nombrado los riesgos |
| ¿Veremos el avance? | demostraciones por etapas, acceso al repositorio de código |
| ¿Es comparable la oferta? | se refiere al mismo alcance detallado, y las partidas aparte están a la vista |
| ¿Está resuelta la cuestión del código fuente y de los derechos? | el contrato establece la entrega y el alcance de los derechos |
| ¿Hay acuerdo de confidencialidad y contrato de encargo del tratamiento? | firmados donde hace falta |
| ¿Están fijadas la corrección de errores y la operación? | niveles de gravedad, tiempos de reacción, SLA |
| ¿Hay plan de salida? | documentación, accesos, exportación de datos |
| ¿Hemos preguntado por la seguridad? | respuestas concretas sobre permisos, actualizaciones y copias de seguridad |
Preguntas frecuentes
¿Freelance o empresa de desarrollo?
Para una tarea más pequeña y bien delimitada, un freelance con experiencia también puede ser una buena elección, sobre todo si la empresa tiene su propio responsable técnico. Si el sistema forma parte del funcionamiento diario, requiere varias especialidades y va a funcionar durante mucho tiempo, la empresa de desarrollo supone un riesgo menor, porque el trabajo no depende de una sola persona.
¿Cómo comparar dos ofertas?
Solo pueden compararse las ofertas hechas sobre la misma especificación detallada. Pregunte a ambos ofertantes para qué tamaño y para qué funciones han dado su precio, qué figura como partida aparte y cómo gestionan los cambios. Si el tamaño se ha medido con un método normalizado, por ejemplo en puntos de función COSMIC, puede verificarse a partir de la misma especificación.
¿Qué debe incluir el contrato?
El alcance (la especificación detallada), el precio y el calendario, la entrega del código fuente y el alcance de los derechos de uso, la confidencialidad, el procedimiento de aceptación y de corrección de errores, la operación y el SLA, el plan de salida y, si hay datos personales en juego, el contrato de encargo del tratamiento. Esto es información, no asesoramiento jurídico.
¿Qué ocurre si el desarrollador desaparece?
Si el código fuente, la documentación y los accesos están en manos del cliente, otro desarrollador puede hacerse cargo del sistema. Por eso conviene ver el repositorio de código desde el primer día, mantener el alojamiento y el dominio a nombre propio y fijar un plan de salida en el contrato. Si falta todo esto, continuar con el sistema puede resultar difícil y lento.
¿De quién será el código fuente?
De quien corresponda según el contrato: según la ley húngara de derechos de autor, los derechos patrimoniales sobre el software son transmisibles, pero no de forma automática. Conviene dejar fijado en el contrato que el cliente recibe el código fuente completo y qué derechos adquiere exactamente sobre él. También con nosotros, el código fuente y los derechos de uso se rigen por el contrato.
¿Cómo podemos ayudarle?
Así trabajamos: la primera consulta es gratuita, redactamos juntos la especificación, medimos el tamaño del software en puntos de función COSMIC y, a partir de él, se elaboran la oferta y el calendario. El desarrollo avanza por etapas, con una demostración al final de cada una; si lo solicita, firmamos un acuerdo de confidencialidad (NDA) y, tras la entrega, también nos encargamos de la operación y el mantenimiento. El código fuente y los derechos de uso se rigen por el contrato. Los pasos se describen en la página Cómo trabajamos, y el método de fijación de precios, en la página Precios.
Actualmente estamos desarrollando un gran sistema ERP y CRM; presentamos nuestros propios desarrollos, que pueden probarse, en la página Nuestros trabajos; sobre la empresa puede leer en la página Sobre nosotros, y las respuestas a las preguntas más habituales están en la página Preguntas frecuentes. Si busca un desarrollador, escríbanos a través de los datos de contacto que figuran en la página Contacto.