Contratar el desarrollo de un software a medida es una decisión grande: vas a confiar procesos, datos y una parte importante de tu presupuesto a un equipo externo durante meses. Y, a diferencia de comprar una licencia, no puedes probar el producto antes de pagarlo, porque todavía no existe.
Por eso la mejor protección no está en el precio más bajo ni en el portafolio más vistoso, sino en las preguntas que haces antes de firmar. Estas son las 10 que recomendamos (y que nos parece justo que nos hagan a nosotros también), con lo que deberías escuchar y las respuestas que deberían encender una alerta.
1. ¿Qué entendieron de mi problema?
Antes de hablar de tecnología o de precios, un buen proveedor debería poder explicarte con sus palabras qué problema de negocio quieres resolver, quiénes usarán el sistema y cómo se medirá el éxito.
- Deberías escuchar: preguntas sobre tu operación, tus usuarios, tus datos y los sistemas que ya usas. Un diagnóstico antes de la propuesta.
- Señal de alerta: una cotización cerrada después de una sola llamada de 15 minutos, o la demo de un "sistema listo" que supuestamente sirve para cualquier empresa.
2. ¿Cómo se define el alcance y qué pasa si cambia?
En todo proyecto aparecen cambios, y es normal. Lo que no es normal es que nadie sepa qué estaba incluido desde el principio.
- Deberías escuchar: un documento de alcance con funcionalidades priorizadas, entregables y criterios de aceptación, y un procedimiento claro para evaluar cambios: su impacto en plazo y costo se revisa antes de aprobarlos.
- Señal de alerta: "eso lo vemos en el camino" para todo, o un alcance de una sola línea, como "sistema de ventas completo".
3. ¿De quién serán el código y los datos?
Es la pregunta que más empresas olvidan y la que más problemas trae después.
- Deberías escuchar: que la propuesta o el contrato establece quién es dueño del código desarrollado, dónde vive el repositorio, quién tiene acceso a servidores y bases de datos, y cómo se hace la transferencia si algún día decides cambiar de proveedor.
- Señal de alerta: respuestas vagas, un código que nunca podrás ver o una plataforma del proveedor de la que no podrás salir sin empezar de cero.
4. ¿Cómo voy a ver el avance?
Un proyecto de varios meses no debería ser una caja negra hasta el día de la entrega.
- Deberías escuchar: entregas por etapas que puedas probar, reuniones de seguimiento con una frecuencia definida y un responsable del lado del proveedor al que puedas acudir.
- Señal de alerta: "te lo mostramos cuando esté terminado".
5. ¿Quién va a trabajar en mi proyecto?
La persona que te vende no siempre es la que construye.
- Deberías escuchar: quién lidera técnicamente el proyecto, qué roles participan (análisis, diseño, desarrollo, pruebas) y, si hay especialistas externos, cómo se supervisa su trabajo.
- Señal de alerta: no poder hablar nunca con alguien técnico antes de firmar.
6. ¿Pueden mostrarme proyectos parecidos?
No hace falta que hayan construido exactamente tu sistema, pero sí algo con una complejidad comparable.
- Deberías escuchar: ejemplos concretos, con el problema, la solución y el resultado; demostraciones o referencias de clientes que puedas contactar, respetando la confidencialidad de cada uno.
- Señal de alerta: solo capturas bonitas, sin explicar qué problema resolvía cada proyecto, o testimonios imposibles de verificar.
7. ¿Cómo prueban el sistema antes de entregarlo?
Un error en un sistema que factura, cobra o controla inventario cuesta dinero real.
- Deberías escuchar: pruebas durante el desarrollo, un ambiente donde tu equipo valide antes de pasar a producción y criterios claros para dar un entregable por aceptado.
- Señal de alerta: que las pruebas las termines haciendo tú, en producción y con tus clientes.
8. ¿Qué pasa después de la puesta en producción?
El día que el sistema sale a producción no termina el proyecto: empieza su uso real.
- Deberías escuchar: un periodo de estabilización, qué cubre la garantía por errores, cómo se reportan incidencias y qué modalidades de soporte y mejora continua existen.
- Señal de alerta: no saber a quién llamar cuando algo falle, o que cada consulta posterior se cobre sin reglas acordadas de antemano.
9. ¿Cómo se integra con lo que ya uso?
Pocos sistemas viven aislados: facturación electrónica, pasarelas de pago, ERP, hojas de cálculo, CRM.
- Deberías escuchar: que revisarán las opciones técnicas de cada integración (APIs, formatos, permisos y limitaciones de cada proveedor) durante la definición, antes de prometer nada.
- Señal de alerta: "se conecta con todo", sin haber revisado nada.
10. ¿Cómo se paga y qué incluye el precio?
El precio más bajo puede salir caro si deja fuera cosas que después vas a necesitar.
- Deberías escuchar: pagos asociados a hitos o entregables, qué incluye el monto (análisis, diseño, desarrollo, pruebas, despliegue, capacitación) y qué costos recurrentes vendrán después, como servidores, licencias de terceros o soporte.
- Señal de alerta: que te pidan el 100 % por adelantado, o una cotización sin desglose.
Checklist para comparar proveedores
| Criterio | Proveedor A | Proveedor B |
|---|---|---|
| Hizo un diagnóstico antes de cotizar | ||
| Alcance escrito con criterios de aceptación | ||
| Propiedad del código y accesos por escrito | ||
| Entregas por etapas que puedo probar | ||
| Responsable técnico identificado | ||
| Proyectos comparables que puedo verificar | ||
| Ambiente de pruebas antes de producción | ||
| Garantía y soporte definidos | ||
| Integraciones revisadas antes de prometer | ||
| Pagos por hitos y precio desglosado |
Lo que no deberías usar como único criterio
- Solo el precio. Dos cotizaciones pueden no incluir lo mismo.
- Solo el portafolio. Un sistema empresarial se juzga por cómo resuelve procesos, no solo por cómo se ve.
- Solo la tecnología. Laravel, React u otras son buenas herramientas; lo importante es que el equipo sepa usarlas para resolver tu problema.
Cómo respondemos estas preguntas en Wari
Nos parece justo medirnos con la misma vara:
- Empezamos con un diagnóstico de objetivos, usuarios, procesos, datos e integraciones, y validamos si realmente necesitas un desarrollo a medida o si una herramienta estándar te alcanza.
- El alcance se acuerda por escrito, con entregables, criterios de aceptación y responsabilidades, antes de construir.
- La propuesta establece propiedad, accesos y transferencia. Nuestro principio es que tu organización conserve el control de sus datos y del sistema.
- Construimos por etapas, con entregas que tu equipo prueba durante el proyecto.
- Después de la puesta en producción acompañamos la estabilización, el soporte y la evolución, según la criticidad de tu operación.
Si quieres ver cómo sería con tu caso, revisa nuestro servicio de software a medida o cuéntanos tu proyecto: te respondemos en menos de 24 horas hábiles. Y si todavía no tienes claro si necesitas un sistema propio, empieza por estas 5 señales.