Cómo elegir una empresa de software: 12 preguntas clave

En resumen: Para elegir una empresa de desarrollo de software no basta comparar precio y portafolio. Pregunta quién queda dueño del código, a nombre de quién quedan las cuentas, cómo se manejan los cambios de alcance, cada cuánto verás avances, cuánto cuesta operar el sistema al mes y qué pasa si la relación termina. Las respuestas concretas y por escrito son la mejor señal.

Contratar desarrollo de software se parece a contratar una obra: la cotización dice poco de cómo va a ser el proceso. Dos propuestas con el mismo precio pueden terminar muy distinto. Una deja un sistema que tu equipo usa y controla; la otra, un proyecto que se alarga y un proveedor del que no te puedes soltar. Estas 12 preguntas sirven para ver la diferencia antes de firmar.

¿Qué hay que preguntarle a una empresa de software antes de contratarla?

Hay que preguntar por cuatro cosas: propiedad, forma de trabajo, costos después de la entrega y qué pasa cuando algo sale mal. El precio y el portafolio importan, pero muchos problemas en proyectos de software vienen de temas de los que nadie habló al inicio.

Da igual si buscas un proveedor de software en Colombia o afuera: las preguntas son las mismas. En cada una verás por qué importa y cómo distinguir una respuesta buena de una floja.

Propiedad y control: ¿el sistema va a ser tuyo?

Estas tres preguntas definen si el sistema será realmente tuyo o si vas a depender de otro.

1. ¿Quién es dueño del código fuente y de los datos?

Por qué importa: si el código no es tuyo, cualquier cambio futuro depende de ese proveedor, al precio que él defina.

• Buena respuesta: "El código y los datos son tuyos. El repositorio queda a nombre de tu empresa y tienes acceso desde el primer día."
• Mala respuesta: "El código es nuestro, pero te damos licencia de uso", sin explicar qué significa eso ni qué pasa si dejas de pagar.

Lo desarrollamos en detalle en qué pedir por escrito sobre la propiedad del código y los datos.

2. ¿A nombre de quién quedan el servidor, el dominio y las cuentas?

Por qué importa: puedes ser dueño del código y aun así no poder moverlo si la nube, el dominio o la base de datos están en la cuenta personal del proveedor.

• Buena respuesta: las cuentas de infraestructura se crean a nombre de tu empresa, con un correo de tu empresa, y el proveedor entra como invitado.
• Mala respuesta: "No te preocupes, eso lo manejamos nosotros."

3. ¿Qué pasa si ustedes cierran o si decidimos cambiar de proveedor?

Por qué importa: los proveedores cambian, los equipos rotan y las relaciones se terminan. Un buen acuerdo planea la salida desde la entrada.

• Buena respuesta: hay documentación técnica, el código está en tu repositorio y existe un periodo de transición definido para entregarle el sistema a otro equipo.
• Mala respuesta: un silencio incómodo, o "eso no va a pasar".

Forma de trabajo: ¿cómo va a avanzar el proyecto?

Estas cuatro preguntas muestran si el proyecto avanzará con visibilidad o a ciegas.

4. ¿Cómo manejan los cambios de alcance?

Por qué importa: el alcance siempre cambia. Cuando tu equipo ve las primeras pantallas aparecen cosas que nadie pensó. La pregunta es cómo se decide y cómo se cobra.

• Buena respuesta: cada cambio se estima por separado, tú lo apruebas antes de que se haga y queda registrado. Si algo no cabe, se cambia por otra cosa del mismo tamaño o pasa a una fase siguiente.
• Mala respuesta: "Todo cabe" (y luego no cabe), o una cotización cerrada que penaliza cualquier ajuste.

5. ¿Cada cuánto veo avances funcionando?

Por qué importa: un proyecto que muestra resultados cada tres meses acumula malentendidos durante tres meses.

• Buena respuesta: entregas cortas, cada una o dos semanas, con algo que tu equipo puede probar. No un informe de avance: algo que funcione.
• Mala respuesta: "Te mostramos todo al final para que lo veas completo."

6. ¿Quién va a trabajar en mi proyecto y quién es mi contacto?

Por qué importa: la persona que vende no siempre es la que construye. Saber quién responde evita que tus preguntas se pierdan.

• Buena respuesta: un nombre concreto como responsable y claridad sobre quién desarrolla.
• Mala respuesta: "El equipo", sin nombres.

7. ¿Cómo entienden mi proceso antes de cotizar?

Por qué importa: si te cotizan sin preguntar cómo trabajas hoy, están cotizando lo que imaginan, no lo que necesitas.

• Buena respuesta: piden hablar con quien hace el trabajo, quieren ver los archivos reales y a veces proponen hacer menos de lo que pediste.
• Mala respuesta: una cotización detallada después de una sola llamada de veinte minutos.

Costos: ¿cuánto pagas después de la entrega?

Estas tres preguntas evitan las sorpresas que aparecen cuando el proyecto ya se pagó.

8. ¿Cuánto cuesta operar el sistema al mes?

Por qué importa: construir se paga una vez; operar, todos los meses: servidores, base de datos, almacenamiento, servicios de terceros.

• Buena respuesta: una estimación mensual desglosada y qué la haría subir.
• Mala respuesta: "Eso depende", sin ningún número de referencia.

9. ¿Cobran por usuario?

Por qué importa: si el sistema se cobra por cada persona que lo usa, el costo crece con tu equipo aunque el software no cambie. Lo explicamos en por qué las licencias por usuario crecen más rápido que tu empresa.

• Buena respuesta: el precio depende de lo que se construye, no de cuántas personas entran.
• Mala respuesta: un cobro por usuario escondido en la letra pequeña o en una "tarifa de plataforma".

10. ¿Qué incluye el mantenimiento y cuánto cuesta?

Por qué importa: todo software necesita algo de mantenimiento: actualizaciones de seguridad, ajustes cuando cambia una herramienta conectada, correcciones menores. Si no se habla antes, aparece como sorpresa. Más detalle en cuánto cuesta mantener un software a medida.

• Buena respuesta: qué está incluido, qué se cobra aparte y cómo, y la posibilidad de que el mantenimiento lo haga otro equipo si así lo decides.
• Mala respuesta: un contrato de mantenimiento obligatorio sin detalle de qué cubre.

Soporte: ¿qué pasa cuando algo falla?

Las dos últimas preguntas muestran con qué respaldo cuentas después de la entrega.

11. ¿Qué garantía dan y quién hace el soporte?

Por qué importa: después de la entrega aparecen errores que no se vieron en pruebas. Necesitas saber por cuánto tiempo se corrigen sin costo, por qué canal los reportas y en cuánto tiempo responden.

• Buena respuesta: un periodo de garantía definido, un canal claro (correo, WhatsApp o un sistema de tickets) y tiempos de respuesta según la gravedad del problema.
• Mala respuesta: "Nos escribes cuando necesites", sin ningún compromiso.

12. ¿Entregan documentación y capacitan al equipo?

Por qué importa: un sistema que solo entiende quien lo construyó es un riesgo. Y uno que el equipo no sabe usar vuelve al Excel en un mes.

• Buena respuesta: manual de uso, documentación técnica básica (cómo está armado, cómo se publica una nueva versión) y sesiones de capacitación con las personas que lo van a usar.
• Mala respuesta: "Es muy intuitivo, no necesita manual."

¿Cuáles son las señales de alerta al contratar desarrollo de software?

Las señales de alerta más claras son la prisa, la vaguedad y la resistencia a poner las cosas por escrito. Si notas varias de estas, vale la pena frenar:

• Cotizan el sistema completo sin haber visto cómo trabajas.
• Te presionan a firmar rápido con descuentos "solo por esta semana".
• No quieren poner por escrito la propiedad del código ni la de las cuentas.
• Solo muestran avances al final.
• No saben decirte cuánto costará operar el sistema al mes.
• Te dicen que sí a todo. Un proveedor serio hace preguntas y pone límites.

¿Cómo comparar varias propuestas?

Compara con la misma plantilla: las 12 preguntas en filas y cada proveedor en una columna. Un ejemplo resumido:

Tema	Proveedor A	Proveedor B
Dueño del código	El cliente, por escrito	Licencia de uso
Cuentas de infraestructura	A nombre del cliente	A nombre del proveedor
Entregas	Cada dos semanas	Al final
Costo mensual de operación	Estimado y desglosado	"Depende"
Cobro por usuario	No	Sí, desde el usuario 10
Garantía	Definida por escrito	No mencionada

Una propuesta más barata con varias casillas débiles puede salir más cara a dos años. Para que las cotizaciones se puedan comparar, ayuda pedirlas con la misma estructura: lo explicamos en cómo pedir una cotización de software que sirva para comparar.

¿Cuándo no hace falta un proceso tan riguroso?

No hace falta para todo. Si vas a contratar algo pequeño, como una automatización puntual entre dos herramientas o un formulario, basta con tener claras tres cosas: de quién son las cuentas, cuánto cuesta al mes y a quién llamas si falla.

Tampoco aplica igual si vas a comprar un software comercial estándar. Ahí las preguntas cambian: qué pasa con tus datos si cancelas, cómo sube el precio con el tiempo y qué tan fácil es exportar la información.

Y una advertencia honesta: estas preguntas no garantizan un buen proyecto. Ayudan a descartar malas señales, pero la relación se prueba en las primeras entregas. Por eso preferimos proyectos que empiezan con un módulo pequeño: si algo no funciona, lo sabes en semanas y no después de meses. Lo contamos en por qué conviene desarrollar por módulos.

Nuestras respuestas a esta misma lista

Nos parece justo responder nuestra propia lista. En CodeLess Co el código y los datos son del cliente, se paga por módulo y no por usuario, y trabajamos con entregas cortas y funcionales desde las primeras semanas. Cada sistema se entrega documentado y con el equipo capacitado. Precios no publicamos: cada proyecto se cotiza aparte, después de entender el proceso. Si quieres ver cómo trabajamos, está en desarrollo de software a medida.

Si estás comparando proveedores, revisamos tu caso sin compromiso. La primera conversación es gratis: cuéntanos qué quieres construir.

Preguntas frecuentes

¿Es mejor contratar un freelancer o una empresa de desarrollo de software?

Depende del tamaño y del riesgo del proyecto. Un freelancer puede servir para trabajos pequeños y acotados. Una empresa suele ofrecer más continuidad: si una persona se va, el proyecto sigue. En ambos casos aplican las mismas preguntas básicas: quién es dueño del código, a nombre de quién están las cuentas y qué pasa si la relación termina.

¿Qué debe incluir un contrato de desarrollo de software?

Como mínimo: alcance y entregables, pagos por etapas, propiedad del código y de los datos, a nombre de quién quedan las cuentas de infraestructura, manejo de cambios de alcance, garantía, soporte y condiciones de salida. Esto es orientación práctica, no asesoría legal: lo recomendable es que un abogado revise el contrato antes de firmarlo.

¿Cuánto tiempo toma desarrollar un software a medida?

Depende del alcance, pero si el proyecto se parte en módulos, un primer módulo útil suele poder entregarse en semanas, no en trimestres. Más que la fecha final, importa ver algo funcionando pronto. Desconfía de plazos de muchos meses sin entregas intermedias que tu equipo pueda probar con datos reales.

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

Pide hablar con clientes anteriores, verifica que responda por escrito las preguntas de propiedad y costos, y fíjate en cómo pregunta por tu proceso antes de cotizar. Una empresa confiable dice lo que no sabe, pone límites al alcance y a veces recomienda hacer menos de lo pedido. La prisa por firmar y las respuestas vagas son malas señales.