Una propuesta de software se lee como un documento comercial y se comporta como un contrato. Todo lo que no diga hoy, se discute dentro de cuatro meses y con el sistema a medias.

Esta es la lista con la que puedes evaluar a cualquier proveedor. Está escrita para que la uses contra nosotros también.

Qué debe traer por escrito

Una propuesta seria no tiene que ser larga. Tiene que ser específica en siete puntos.

Alcance cerrado, no "y lo que salga"

El documento debe listar módulos, pantallas y flujos concretos. "Sistema de administración de clientes" no es un alcance; es un título.

Lo que sirve se lee así: alta de cliente con estos campos, tres roles de usuario, reporte mensual exportable, notificación por correo al autorizar.

Si no puedes contar los entregables con los dedos, el alcance está abierto y el precio también.

Qué NO incluye

Esta es la sección que casi nadie escribe y la que más discusiones evita.

Debe decir explícitamente qué queda fuera: migración de datos históricos, integración con tu facturación, app móvil nativa, capacitación presencial, soporte fuera de horario. Cualquiera de esas puede estar dentro o fuera, y las dos opciones son válidas.

Lo que no es válido es descubrirlo en la junta de entrega.

Propiedad del código y de los datos

El documento debe decir a nombre de quién queda el repositorio y a nombre de quién quedan las cuentas de servicios.

La respuesta correcta es: de tu empresa, desde el primer día, no al terminar de pagar. Si el proveedor te da acceso de invitado a su propia cuenta, no eres dueño de nada.

Lo mismo con la base de datos. Tuya, completa, con relaciones y archivos, no un archivo de exportación.

Plan de mantenimiento con precio

Un sistema no se entrega, se opera. Si la propuesta termina en la fecha de entrega, está incompleta.

Debe traer el costo mensual posterior y qué cubre: actualizaciones de seguridad, cambios del negocio, crecimiento de datos, integraciones que se rompen solas. Nosotros lo publicamos: el mantenimiento arranca en $15,000 MXN al mes y el desarrollo entre $60,000 y $100,000 MXN.

Una propuesta sin mantenimiento se ve más barata hoy y sale más cara al año.

Quién responde cuando falla

Debe haber un nombre, un canal y un tiempo de respuesta comprometido. "Nos escribes por WhatsApp" no es un compromiso, es una costumbre.

Pregunta qué pasa un martes a las nueve de la mañana con el sistema caído y quién contesta si esa persona está de vacaciones.

Plazos con la razón detrás

Los plazos honestos vienen con condiciones. Un primer sistema que ya usa gente real toma entre cuatro y ocho semanas desde que se cierra el alcance; uno con varios módulos, integraciones y migración se va entre tres y seis meses.

Lo que mueve esas fechas casi nunca es programar. Es qué tan disponible está quien conoce el proceso de tu lado y qué tan sucios están los datos que hay que migrar.

Una propuesta que promete fechas sin mencionar de qué dependen está adivinando.

Precio cerrado y forma de pago

Monto total, qué pasa si pides algo fuera del alcance, y contra qué se pagan los parciales. Lo sano es pagar contra entregables verificables, no contra el calendario.

Una propuesta de siete puntos claros vale más que una de treinta páginas bonitas.

Las señales de alarma

Ninguna de estas es prueba de mala fe. Todas son motivo para preguntar más antes de firmar.

Cotizar por hora

Cobrar por hora premia tardarse. Y te deja sin techo: no sabes cuánto vas a pagar hasta que ya pagaste.

Hay casos donde tiene sentido, como una bolsa de horas de mantenimiento. Para construir un sistema nuevo, pide alcance cerrado con precio cerrado.

Prometer todo en dos semanas

Hoy cualquiera hace una demo funcionando en dos semanas. Escribir código es rápido y barato para todo el mundo.

Lo que no cabe en dos semanas es lo que sostiene el sistema: pruebas, permisos por usuario, migración de datos y puesta en producción. Cuando alguien recorta el calendario, sale de ahí.

Vas a recibir una demo bonita sin la parte de producción.

No publicar ningún precio

La razón que dan es que cada proyecto es distinto, y es cierta. Pero un proveedor que no suelta ni un rango después de entender tu caso está esperando a ver cuánto aguantas.

Pide un rango en la primera llamada. Si no lo dan ahí, no lo van a dar mejor después.

Negarse a entregar el repositorio

Es la señal más seria de la lista. Un proveedor que no entrega el código está vendiendo dependencia, no software.

La variante suave es igual de grave: "te lo entregamos al final del contrato". El código se te entrega mientras se escribe, commit por commit, en tu propia cuenta.

"Te lo dejamos en nuestro servidor"

Suena a comodidad y es amarre. Si la base de datos, los dominios y los servicios están a nombre del proveedor, cambiar de equipo significa reconstruir.

Las cuentas de nube, base de datos y dominio van a nombre de tu empresa, y tú pagas esa factura directo. El proveedor entra como colaborador.

Un solo desarrollador sin respaldo

Puede ser excelente y costar la mitad. También es un punto único de falla con tu operación adentro.

Si vas por ese camino, exige documentación escrita y accesos a tu nombre desde el día uno. Eso convierte un riesgo en un riesgo administrable.

Detalle desigual en el documento

Cuando la propuesta dedica cuatro páginas a la metodología y tres líneas al alcance, está vendiendo confianza en vez de trabajo.

El detalle se pone donde está el dinero, no donde está la presentación.

Preguntas para copiar y mandar

Manda estas preguntas por correo, no por llamada. Lo que quieres es la respuesta por escrito.

¿A nombre de qué empresa queda el repositorio del código, y desde qué momento tenemos acceso de administrador?
¿A nombre de quién quedan las cuentas de nube, base de datos y dominio, y quién recibe esa factura?
¿Qué entregables concretos incluye el precio y qué cosas quedan explícitamente fuera del alcance?
Si a mitad del proyecto pedimos algo que no estaba, ¿cómo se cotiza y quién lo autoriza?
¿Cuánto cuesta el mantenimiento mensual después de la entrega y qué incluye exactamente?
Si el sistema se cae un martes a las nueve de la mañana, ¿a quién escribimos y en cuánto tiempo se compromete una respuesta?
¿Los cambios a la base de datos quedan versionados en el repositorio o se aplican directo en producción?
¿Cómo se controla que un usuario solo vea los datos que le tocan, y dónde se valida ese permiso?
¿Dónde se guardan las llaves y contraseñas del sistema, y qué pasa si se filtra el repositorio?
¿Hay respaldos automáticos, cada cuánto, y alguna vez han restaurado uno para probar que sirve?
¿Qué pasa con nuestros datos si dejamos de trabajar juntos, y en qué formato se entregan?
¿Quién específicamente va a escribir este sistema, y qué pasa si esa persona deja el proyecto?
¿De qué depende el plazo que nos están dando y qué lo retrasaría?
¿Qué proyecto suyo lleva más tiempo en producción y quién lo mantiene hoy?

La pregunta 7 y la 10 son las que más separan a los proveedores. Casi nadie las espera.

Cómo leer las respuestas

No busques respuestas perfectas. Busca respuestas específicas.

Una respuesta buena trae sustantivos. Nombres de servicios, frecuencias, nombres de personas, números.
Una respuesta mala trae adjetivos. "Robusto", "seguro", "escalable" sin decir cómo.
Un "no" claro vale más que un "sí" vago. Un proveedor que dice "eso no lo hacemos" es un proveedor que sabe qué sí hace.
Un "eso lo vemos después" es un costo futuro. Anótalo y pregúntalo otra vez antes de firmar.

Si alguien se molesta por la lista, ya obtuviste la información más útil de todo el proceso.

Cómo comparar dos propuestas distintas

El problema real no es evaluar una propuesta. Es comparar dos que no se parecen en nada.

La forma que funciona es normalizarlas a tres años, igual que se compara un desarrollo propio contra un producto de renta.

Suma desarrollo más treinta y seis meses de mantenimiento en cada una.
Agrega a cada una lo que la otra sí incluye y esta no: migración, capacitación, integraciones.
Agrega la infraestructura mensual si no viene incluida.

Es normal que la propuesta más barata suba al primer lugar de precio cuando la completas. Ahí es donde estaba el descuento.

La propuesta más barata casi nunca es el proyecto más barato.

Antes de la propuesta va un diagnóstico

Una cotización que llega sin que nadie haya entendido tu proceso no es una cotización. Es un promedio.

Antes de escribir un precio, alguien tiene que averiguar quién captura, quién autoriza, dónde se atora el flujo y qué se resuelve por WhatsApp porque el sistema no lo permite. Esa conversación es la que define si el proyecto sirve.

Fíjate en quién hace las preguntas y de qué tipo son.

Buena señal: preguntan por el proceso actual, por los datos que hay que migrar y por quién va a usar el sistema todos los días.
Mala señal: preguntan solo por pantallas y colores, y salen con un número el mismo día.
Señal de que ya entendieron: te dicen qué parte del proyecto no vale la pena construir.

Un diagnóstico que se cobra puede ser legítimo. Uno que no existe siempre se paga después, en cambios de alcance.

Lo que te toca a ti

La lista de arriba es exigente con el proveedor. Es justo decir qué se necesita del otro lado, porque la mitad de los proyectos que se retrasan se retrasan aquí.

Una persona que decida. Alguien con autoridad para cerrar dudas en el día, no en la junta del jueves siguiente.
Alguien que haga el proceso todos los días. No solo quien lo dirige. La diferencia entre cómo se supone que funciona y cómo funciona es donde vive el proyecto.
Tus datos como estén. Sucios, duplicados, en tres archivos distintos. Limpiarlos es parte del trabajo, esconderlos lo retrasa.
Tiempo para probar. Un sistema que nadie de tu equipo probó antes de salir a producción sale a producción con tus errores adentro.

Un proveedor que no te pide nada de esto no está planeando entregar nada serio.

Úsala con nosotros

Esta lista no está escrita para que nos elijas. Está escrita para que compares con criterio, y eso nos incluye.

Nuestras respuestas a las catorce preguntas son públicas y siempre las mismas: el repositorio y la base de datos quedan a nombre de tu empresa desde el primer commit; las cuentas de nube van a tu nombre y tú pagas esa factura; el alcance se cierra por escrito con su lista de exclusiones; no cotizamos por hora; el mantenimiento arranca en $15,000 MXN al mes; los cambios de base de datos van versionados en el repositorio, nunca aplicados a mano en producción; los permisos se validan en la base, no en la pantalla; las llaves viven en un almacén de secretos, fuera del código.

Si dejamos de trabajar juntos, te quedas con todo: repositorio, base, documentación y accesos. Ese es el punto de que sea a la medida.

Nuestro proceso es el mismo desde el primer proyecto: Escuchamos, Definimos, Desarrollamos, Expandimos. El diagnóstico inicial no se cobra, y si en esa llamada concluimos que no necesitas un desarrollo, te lo decimos ahí.

Manda las catorce preguntas a tres proveedores y compara las respuestas. De idea a producción, la primera decisión es a quién le crees.

Qué pedirle a una propuesta de software antes de firmar