Cómo elegir una empresa de desarrollo de software a medida (y los errores que salen caros al contratar)

Para elegir una empresa de desarrollo de software a medida no basta con comparar precio, tecnologías y portfolio. Esas tres cosas se pueden enseñar en una reunión y dicen poco de lo que decide el resultado: si el proveedor va a entender el proceso que hay detrás de lo que pides o va a construir exactamente lo que le has dicho, aunque lo que le has dicho no resuelva el problema.

El error caro casi nunca es elegir un equipo que programa mal. Es elegir uno que programa bien la cosa equivocada: pantallas correctas sobre un proceso mal entendido, una integración que copia datos que nadie había decidido de dónde salen, un sistema que funciona el día de la entrega y que nadie más sabe mantener. Esta guía repasa qué mirar, en qué orden y qué señales conviene ver antes de firmar.

Antes de buscar proveedor: define qué problema quieres resolver

La pregunta que más ahorra no se le hace al proveedor, se la hace la empresa a sí misma: ¿qué está pasando hoy que no debería pasar?

«Queremos un software de gestión» no es un problema. «Cada pedido se teclea tres veces —en el correo, en el Excel de producción y en el programa de facturación— y una vez al mes alguien encuentra un pedido que no llegó a facturarse» sí lo es. Con la primera frase, cada proveedor imaginará un sistema distinto y los presupuestos no se podrán comparar. Con la segunda, ya se puede hablar de qué hay que conectar, qué hay que automatizar y qué no hace falta tocar.

No hace falta un documento técnico. Hace falta poder explicar en unos minutos qué proceso falla, quién lo sufre y qué pasaría si se resolviera. Si tienes eso, puedes evaluar proveedores. Si no lo tienes, cualquier proveedor te parecerá bueno, porque no tendrás con qué contrastarlo. Cómo ordenarlo sin escribir una especificación lo explicamos en la guía para preparar los requisitos antes de pedir presupuesto.

Lo que debería preguntarte una empresa de software antes de presupuestar

La primera conversación dice mucho más por las preguntas que te hacen que por lo que te cuentan. Un proveedor que va a construir algo que encaje con tu empresa necesita saber, como mínimo:

• Cómo se hace hoy el proceso, paso a paso, y no cómo debería hacerse en teoría.
• Quién interviene en cada paso y qué puede ver o decidir cada uno.
• Qué herramientas participan: ERP, CRM, hojas de cálculo, correo, la web, un programa del sector.
• Qué excepciones existen: el pedido urgente, el cliente con condiciones especiales, la devolución parcial. Suelen ser la mitad del trabajo.
• Qué datos hay ya y en qué estado están.
• Qué pasaría si no se hiciera nada: si la respuesta es «poco», quizá no compense construir.

Si en la primera reunión nadie pregunta por las excepciones ni por los sistemas que ya usas, y la conversación pasa enseguida a pantallas, colores y plazos, el presupuesto que llegue después estará calculado sobre suposiciones.

Cómo comprobar si entiende tu negocio

Entender el negocio no es conocer tu sector de oídas. Es ser capaz de devolverte el problema mejor explicado de lo que lo trajiste. Tres formas sencillas de comprobarlo:

1. Pide que te resuma lo que ha entendido, por escrito, antes de la propuesta. Si el resumen repite tus palabras, no ha añadido nada. Si señala una contradicción o una pregunta que no te habías hecho, va por buen camino.
2. Pregunta qué no haría. Un proveedor que entiende el problema sabe qué partes no merecen desarrollo propio: lo que una herramienta estándar ya resuelve bien, lo que todavía cambia cada semana, lo que se puede dejar para una segunda fase.
3. Pide un ejemplo de un proyecto parecido y de qué salió mal. Todos los proyectos tienen algo que se entendió tarde. Quien lo cuenta con naturalidad ha aprendido de ello; quien dice que nunca pasa nada probablemente no lo está contando.

El portfolio sirve para ver que el equipo ha entregado cosas reales, pero las capturas no enseñan si aquello resolvió algo. Si puedes, habla con un cliente actual y pregúntale cómo fue el primer mes después del lanzamiento, que es cuando se ve de verdad cómo trabaja un proveedor. Bolmia, por ejemplo, publica los trabajos que puede enseñar en casos de clientes.

Proyecto cerrado o relación tecnológica a medio plazo

Hay dos formas de plantear la contratación y conviene saber cuál estás comprando.

Proyecto cerrado: alcance definido, precio y plazo cerrados, entrega y fin. Funciona cuando el problema está muy acotado y es estable: una integración concreta entre dos sistemas, una herramienta interna con reglas claras. El riesgo es que cualquier cosa que no estaba en el alcance se convierte en una discusión, y en software casi siempre aparece algo.

Relación a medio plazo: se empieza por una primera versión acotada, se pone en uso y se amplía por fases con lo aprendido. Encaja mejor cuando el software toca el corazón de la operación, porque la empresa también cambia y el sistema tiene que cambiar con ella. El riesgo es el contrario: sin un alcance claro por fase, el proyecto no termina nunca.

Ninguna de las dos es mejor en abstracto. Lo que no funciona es mezclarlas sin decirlo: contratar un precio cerrado esperando que el proveedor se comporte como un socio que absorbe cada cambio, o firmar una relación abierta sin saber qué se entrega en cada fase.

Cómo debería plantearse la arquitectura

No hace falta que sepas de arquitectura de software para evaluar si el proveedor la ha pensado. Basta con hacer preguntas de negocio y escuchar si la respuesta es concreta:

• «Si dentro de un año cambiamos una regla —un descuento, un paso de aprobación—, ¿dónde se cambia y cuánto cuesta?» La respuesta buena dice que las reglas viven en un sitio identificable y que cambiarlas es un trabajo acotado.
• «¿Qué pasa si se duplica el volumen?» No se pide que el sistema esté preparado para todo, sino que alguien haya pensado hasta dónde llega.
• «¿Podemos empezar por una parte y añadir el resto después?» Si el planteamiento obliga a construirlo todo de golpe, el riesgo se concentra al final.
• «¿Dónde se aloja, quién lo vigila y cómo se hacen las copias de seguridad?» Es una pregunta de arquitectura aunque no lo parezca.

Si las respuestas se quedan en nombres de tecnologías, no te están explicando la arquitectura: te están diciendo con qué herramientas trabajan.

Integraciones: ERP, CRM, web, pagos y lo que ya funciona

La mayoría de los sistemas a medida no viven solos. Tienen que hablar con el ERP o el programa de facturación, con el CRM, con la web o la tienda online, con una pasarela de pagos, con el correo. Y es en esas costuras donde se van el tiempo y el dinero.

Antes de comparar propuestas, comprueba que cada proveedor ha preguntado:

• Qué sistemas hay que conectar y si tienen una forma documentada de hacerlo (una API) o solo exportaciones manuales.
• En qué sentido viaja cada dato y qué sistema manda cuando dos dicen cosas distintas. Es la misma decisión que explicamos para stock y precios entre la tienda y el ERP, y vale para clientes, pedidos o tarifas.
• Qué pasa cuando un sistema está caído: se encola, se avisa, se bloquea.
• Qué herramientas actuales se mantienen. Un buen planteamiento a medida no obliga a tirar lo que ya funciona: la contabilidad o las nóminas suelen estar bien resueltas por herramientas estándar, y lo propio se construye alrededor.

Si una propuesta dice «integración con el ERP» en una línea y sin más detalle, no está presupuestando la integración: está aplazando la conversación.

Propiedad del código, accesos y dependencia del proveedor

Es la parte que menos se mira al firmar y la que más pesa cuando la relación se acaba. No es una cuestión legal en primer lugar, sino práctica: si mañana tuvieras que cambiar de proveedor, ¿podrías?

Lo que conviene dejar claro por escrito, con el asesoramiento jurídico que cada empresa considere necesario para el contrato:

• Quién es el propietario del código desarrollado para ti y en qué condiciones. En un proyecto de empresa lo habitual es que el código y los datos sean del cliente, pero hay que confirmarlo y ver si hay componentes del proveedor que se licencian aparte.
• Acceso al repositorio: que el código viva en un repositorio al que tu empresa tenga acceso, no solo en el ordenador del proveedor.
• Infraestructura: a nombre de quién están el servidor, el dominio y los servicios en la nube, y quién paga cada cosa.
• Credenciales: que las cuentas críticas —alojamiento, bases de datos, pasarela de pago, correo— estén a nombre de la empresa, con acceso de administración para alguien de dentro.
• Documentación: cómo se instala, cómo se despliega, qué hace cada parte, qué decisiones se tomaron y por qué. Sin ella, el código es tuyo sobre el papel, pero en la práctica sigue dependiendo de quien lo escribió.

Depender de un proveedor no es malo en sí: si trabaja bien, es lo normal. Lo que hay que evitar es la dependencia sin salida, la de un sistema que solo una empresa en el mundo puede tocar porque solo ella tiene las llaves.

Mantenimiento después del lanzamiento

Un software a medida no se termina el día que se pone en marcha. Las primeras semanas de uso real sacan detalles que nadie vio en las pruebas, las librerías necesitan actualizaciones de seguridad, los sistemas con los que se integra cambian sus versiones y la empresa pide ajustes.

Pregunta antes de firmar:

• Qué incluye el periodo posterior al lanzamiento y cuánto dura.
• Qué cubre el mantenimiento después: actualizaciones, seguridad, copias de seguridad, vigilancia del sistema, pequeños ajustes.
• Cómo se piden y se priorizan los cambios nuevos, y cómo se presupuestan.
• Con qué rapidez se responde a una incidencia grave y quién lo hace.

Un proveedor que no habla del mantenimiento hasta que se lo preguntas está presupuestando un sistema que, en su cabeza, deja de ser su problema el día de la entrega.

Cómo evaluar un presupuesto sin comparar solo el precio

Dos presupuestos con importes muy distintos no suelen ser dos precios por lo mismo: suelen ser dos alcances distintos. Antes de mirar la cifra, ponlos uno al lado del otro y compara qué incluye cada uno. Si te falta una referencia de órdenes de magnitud, explicamos cuánto puede costar un software a medida y de qué depende.

Qué comparar	Pregunta que debería responder el presupuesto
Alcance	¿Qué procesos, roles y excepciones entran en esta fase, y cuáles quedan fuera?
Entregables	¿Qué se entrega exactamente: código, documentación, formación, manual de uso?
Integraciones	¿Con qué sistemas se conecta, en qué sentido y con qué nivel de detalle?
Calidad y pruebas	¿Cómo se prueba antes de entregar y quién valida que funciona con casos reales?
Infraestructura	¿Dónde se aloja, quién lo paga y está incluido o va aparte?
Mantenimiento	¿Qué pasa después del lanzamiento y en qué condiciones?
Soporte	¿A quién se llama cuando algo falla y en qué plazo responde?
Cambios	¿Cómo se gestiona lo que surja durante el proyecto?

El presupuesto más barato puede serlo porque deja fuera las integraciones, las pruebas o el mantenimiento. El más caro puede incluir una fase de análisis que los otros se ahorran y que luego se paga igual, en forma de cambios. Lo que permite comparar no es la cifra: es que los tres respondan a las mismas preguntas.

Señales de alarma antes de firmar

Ninguna de estas señales descarta por sí sola a un proveedor, pero cada una merece una pregunta antes de seguir:

• Presupuesto sin haber entendido los procesos. Si la cifra llega después de una llamada de veinte minutos, está calculada sobre una idea, no sobre tu operación.
• «Todo incluido» sin alcance escrito. Lo que no está escrito no está incluido, aunque en la reunión pareciera que sí.
• Un plazo prometido antes de cualquier análisis. Los plazos dependen de la complejidad del proceso; quien los da sin conocerla está adivinando.
• Dependencia absoluta del proveedor. El código solo en sus servidores, las cuentas a su nombre, ninguna intención de documentar.
• Ni repositorio ni documentación en el planteamiento.
• Una solución cerrada difícil de integrar: una plataforma propia del proveedor a la que tus datos entran y de la que no salen con facilidad.
• Hablar solo de pantallas. Si toda la conversación gira en torno a cómo se verá y nunca en torno a qué ocurre cuando entra un pedido, cambia un estado o falla algo, se está diseñando la parte visible de un problema que vive por debajo.
• Decir que sí a todo. Un proveedor que nunca propone hacer menos, aplazar algo o usar una herramienta existente está vendiendo horas, no resolviendo un problema.

Checklist: preguntas que hacer antes de contratar

Cópiala y úsala con cada proveedor. La respuesta útil es la que llega por escrito y es concreta.

1. ¿Qué has entendido de nuestro problema? Resúmelo en un párrafo.
2. ¿Qué parte no construirías a medida y por qué?
3. ¿Qué entra en la primera fase y qué queda fuera?
4. ¿Con qué sistemas te conectarías, en qué sentido y qué pasa si uno falla?
5. ¿Quién trabajará en el proyecto, con nombre, y quién responde si hay un problema?
6. ¿Cómo se prueba antes de entregar y cómo validamos nosotros que funciona?
7. ¿De quién será el código y dónde vivirá el repositorio?
8. ¿A nombre de quién estarán el alojamiento, el dominio y las cuentas críticas?
9. ¿Qué documentación entregas y cuándo?
10. ¿Qué incluye el mantenimiento y cómo se presupuestan los cambios?
11. Si cambiamos una regla de negocio dentro de un año, ¿qué hay que tocar?
12. ¿Qué proyecto parecido has hecho y qué aprendiste de lo que salió mal?

Si un proveedor responde bien a estas doce, ya sabes bastante más de él que lo que diría cualquier portfolio. Y si después de pasar por ellas la conclusión es que tu problema lo resuelve una herramienta que ya existe, también es un buen resultado: te has ahorrado un proyecto.

Si estás comparando proveedores

En Bolmia trabajamos el desarrollo de software a medida empezando por el proceso, no por las pantallas, y conectando lo que se construye con las herramientas que ya funcionan. Cómo planteamos las decisiones está explicado en nuestro enfoque.

Si ya tienes claro qué proceso quieres resolver, podemos revisarlo contigo y decirte si conviene integrar lo que ya usas, adaptar una herramienta existente o construir algo propio. Cuéntanos qué está pasando hoy y lo vemos.