Cómo elegir una empresa de desarrollo de software confiable para tu proyecto

Contratar una empresa de desarrollo de software se parece más a contratar un constructor que a comprar un producto: pagas por adelantado, el resultado tarda meses en verse y, si algo sale mal, te enteras cuando ya invertiste. Esta guía reúne lo que conviene revisar antes de firmar, escrita desde el lado del proveedor. Eso significa que también sirve para evaluarnos a nosotros.

No hay aquí una lista de “los mejores proveedores”. Hay preguntas concretas y las respuestas que debería dar una empresa seria.

¿Cómo saber si una empresa de software es seria?

Una empresa seria se reconoce por lo que puedes verificar sin pedirle nada:

Existe legalmente. Tiene razón social, NIT y una fecha de constitución que coincide con lo que dice en su sitio. En Colombia puedes consultar la matrícula mercantil en el RUES (rues.org.co) con el nombre o el NIT.
Tiene trabajo público. No capturas de pantalla, sino sistemas que puedas usar o ver en operación, o clientes que puedas contactar.
Tiene personas identificables. Nombres reales, perfiles de LinkedIn y un equipo que coincide con el tamaño que declara. Una empresa que dice tener 50 personas y muestra cinco perfiles te está contando dos historias.
Dice lo que no hace. Un proveedor que acepta cualquier proyecto sin preguntar es una señal peor que uno que te dice “eso no es lo nuestro”.

Si algo de esto no cuadra, no significa que la empresa sea deshonesta. Significa que todavía no tienes evidencia, y la evidencia es lo que debe reemplazar a la confianza en esta etapa.

¿Qué debería entregar antes de empezar?

Antes de escribir código, una empresa seria te entrega un documento que responde cinco preguntas:

Alcance. Qué incluye la primera versión y qué queda fuera a propósito.
Arquitectura. Cómo se conecta con lo que ya usas y dónde se va a desplegar.
Fases y entregables. Qué vas a recibir, cuándo, y cómo se decide que cada entrega está aceptada.
Presupuesto. Por fase, con lo que incluye y lo que se cobra aparte (licencias, infraestructura, soporte).
Riesgos. Qué puede salir mal y qué se hará si ocurre.

Ese documento suele salir de una consultoría inicial. Algunas empresas la cobran y otras no; lo importante no es el precio sino que exista. Una cotización entregada sin haber entendido cómo funciona hoy tu operación es un número inventado, y un proveedor que la da sin preguntar está cotizando lo que cree que quieres oír.

¿Cómo validar experiencia real?

Pide tres cosas y verifica cada una por tu cuenta:

Un sistema en operación que puedas ver funcionando. Si el proveedor desarrolló una app pública, descárgala. Si construyó una plataforma para una entidad, busca la noticia o el documento oficial que la mencione.
Un cliente al que puedas llamar. No un testimonio en el sitio web, sino una persona con nombre y cargo que acepte una conversación de diez minutos. Pregúntale qué salió mal durante el proyecto y cómo lo manejó el proveedor. Todos los proyectos tienen algo que sale mal; lo que importa es la respuesta.
Un proyecto parecido al tuyo. No en el sector necesariamente, sino en el tipo de problema: integrar sistemas que no se hablan, digitalizar un proceso manual, construir un asistente que trabaje con documentación interna.

Desconfía de la experiencia “en todos los sectores”. La experiencia real es específica y tiene nombres.

¿Qué debe quedar por escrito?

Todo lo que después podría discutirse. Como mínimo:

Tema	Qué debe decir el contrato o el anexo técnico
Alcance	Lista de módulos y funcionalidades de la primera versión. Lo que no está en la lista no está incluido.
Entregas	Fechas o hitos, y criterios de aceptación de cada entrega.
Cambios	Cómo se piden, cómo se estiman y cómo se aprueban los cambios de alcance.
Propiedad	Quién es dueño del código, de los diseños, de la documentación y de las cuentas de infraestructura.
Accesos	Qué credenciales tendrá el proveedor, quién las administra y cómo se revocan al terminar.
Confidencialidad	Qué información se considera confidencial, quién puede verla y qué pasa con ella al finalizar.
Garantía y soporte	Cuánto dura la garantía sobre lo entregado, qué cubre y cuánto cuesta el soporte después.
Salida	Qué recibes si terminas la relación: código, documentación, exportación de datos, transferencia de dominios y cuentas.

Si el proveedor se resiste a poner alguno de estos puntos por escrito, esa resistencia es la información más valiosa que te va a dar antes de firmar.

¿Quién es dueño del código?

La respuesta correcta es tu empresa, y debe estar en el contrato. En la práctica eso significa:

El repositorio está en una cuenta de tu empresa, o el proveedor te transfiere la propiedad al terminar cada fase.
Las cuentas de infraestructura (nube, dominios, certificados, tiendas de aplicaciones) están a nombre de tu empresa, aunque el proveedor las administre.
La documentación técnica (cómo se instala, cómo se despliega, cómo se configura) se entrega junto con el código.

Hay una excepción razonable: si el proveedor usa componentes propios que ya existían antes de tu proyecto, puede conservar la propiedad de esos componentes y darte una licencia de uso. Eso es aceptable siempre que esté listado y no impida que otro equipo mantenga el sistema.

Lo que no es aceptable es descubrir al final que el código “es del proveedor” y que cambiar de empresa implica empezar de cero.

¿Cómo se manejan accesos y credenciales?

Durante el proyecto el proveedor necesitará acceso a información y sistemas de tu empresa. Lo que conviene acordar:

Cuentas nominales, no compartidas: cada persona del proveedor con su propio usuario, para que quede rastro de quién hizo qué.
Mínimo privilegio: acceso solo a lo que el proyecto necesita, no al sistema completo.
Revocación al finalizar: una lista de todos los accesos otorgados, para cerrarlos al terminar.
Secretos fuera del código: contraseñas y claves de API en un gestor de secretos, nunca escritas en el repositorio.

Estas prácticas no son sofisticadas. Un proveedor que no las aplica por defecto probablemente tampoco las aplica en la infraestructura que va a construir para ti.

¿Qué señales deberían generar desconfianza?

Ninguna de estas es prueba de nada por sí sola. Dos o tres juntas sí lo son.

Te dan precio y plazo en la primera llamada, antes de entender tu operación.
Aceptan todo lo que pides sin cuestionar nada.
Las referencias son testimonios anónimos o con nombre de pila y sin cargo.
El portafolio muestra logos de clientes pero no describe qué se hizo para cada uno.
No pueden explicarte con quién vas a hablar durante el proyecto ni quién va a escribir el código.
Los números de la empresa no cuadran entre sí (más proyectos en una página que en otra, más empleados de los que aparecen en el equipo).
Evitan hablar de propiedad del código o dicen que “eso se ve después”.
La propuesta es una presentación con promesas de “transformación digital” y sin una lista concreta de entregables.

¿Cómo debe manejarse la confidencialidad?

Antes de compartir información sensible, deberías tener un acuerdo de confidencialidad (NDA) firmado. Es un documento corto y cualquier proveedor serio lo firma sin resistencia.

Si el proyecto involucra inteligencia artificial, hay dos preguntas adicionales que conviene hacer por escrito:

¿Mi información se usa para entrenar modelos de terceros? Los planes empresariales de los principales proveedores de modelos (OpenAI, Anthropic, Google) no usan los datos de la API para entrenamiento; los planes gratuitos o de consumidor, en general, sí pueden hacerlo. Pide que te digan qué plan usarán.
¿Dónde se despliega? Si tu política interna exige que los datos no salgan de tu infraestructura, el proveedor debería poder desplegar en tu propia cuenta de nube.

Un proveedor que no puede responder estas dos preguntas con precisión no ha operado un sistema de IA con información confidencial.

¿Qué pasa después de entregar el software?

El software no se termina; se entrega. A partir de ahí necesita al menos tres cosas:

Garantía: un periodo en el que los errores de lo entregado se corrigen sin costo. Debe estar en el contrato con su duración.
Soporte: un canal y un tiempo de respuesta acordados para cuando algo falle en producción.
Evolución: una forma de agregar funcionalidades cuando el negocio cambie, ya sea por proyecto o con un equipo dedicado.

Pregunta también quién te atenderá: si es la misma gente que construyó el sistema o un equipo de soporte que no lo conoce. La diferencia se nota la primera vez que algo se rompe un viernes a las cinco de la tarde.

¿Cómo evitar quedar amarrado a un proveedor?

Quedar cautivo de un proveedor casi nunca ocurre por mala intención. Ocurre por omisión: nadie pidió la documentación, las cuentas quedaron a nombre del proveedor, el código usa componentes que solo esa empresa conoce. Para evitarlo:

Código, cuentas y dominios a nombre de tu empresa desde el inicio.
Documentación de instalación y despliegue entregada con cada fase, no al final.
Tecnologías conocidas en el mercado, de modo que otro equipo pueda mantener el sistema. Si el proveedor propone algo poco común, que justifique por qué.
Una cláusula de salida que diga exactamente qué recibes si terminas la relación.

La prueba definitiva es una pregunta: “Si mañana cambio de proveedor, ¿qué necesitaría el siguiente para seguir trabajando?” La respuesta debería ser “el repositorio, la documentación y los accesos”, y todo eso deberías tenerlo ya.

Checklist para evaluar una empresa de desarrollo de software

Antes de firmar, deberías poder marcar todos estos puntos:

Identidad y experiencia

La razón social y el NIT existen y coinciden con lo que dice el sitio web.
Vi al menos un sistema del proveedor funcionando en operación real.
Hablé con al menos un cliente anterior, con nombre y cargo.
El equipo que aparece en el sitio coincide con el tamaño que declaran.

Propuesta

Hubo un levantamiento de mi operación antes de la cotización.
La propuesta lista módulos y entregables concretos, no promesas generales.
El presupuesto está dividido por fases e indica qué se cobra aparte.
Los riesgos del proyecto están identificados por escrito.

Contrato

El código, los diseños y la documentación quedan a nombre de mi empresa.
Las cuentas de infraestructura, dominios y tiendas están a mi nombre.
Hay criterios de aceptación para cada entrega.
El proceso de cambios de alcance está definido.
La garantía tiene duración y cobertura escritas.
Existe una cláusula de salida con lo que recibo al terminar.

Confidencialidad y accesos

Firmamos un NDA antes de compartir información sensible.
Los accesos son nominales y de mínimo privilegio, con lista para revocarlos.
Si hay IA, sé qué plan de API se usa y dónde se despliega.

Después de la entrega

Sé quién me atiende en soporte y con qué tiempo de respuesta.
Sé cómo se agregan funcionalidades después de la primera versión.

Si un proveedor cumple con todo esto, no tienes garantía de que el proyecto salga perfecto. Pero sí tienes garantía de algo más valioso: si algo sale mal, sabrás con quién hablar, qué dice el contrato y qué es tuyo.

Sobre GeekCorp. Somos GeekCorp S.A.S, empresa de desarrollo de software constituida en 2020, con sede en Córdoba y presencia en Montería y Barranquilla. Construimos Op-Tra y la app de Metrosinú, en operación en el transporte público de Montería, y otros casos que puedes revisar en el portafolio. Si estás estructurando un proyecto y quieres una segunda opinión sobre el alcance, cuéntanos el problema: la consultoría inicial no tiene costo y, si tu caso se resuelve con una herramienta que ya existe, te lo decimos.