Hay una duda muy específica que escuchamos de compradores primerizos de software, casi siempre formulada con cuidado: "¿pedir un presupuesto cuesta algo?" Es una preocupación razonable — nadie quiere disparar una factura por accidente solo por hacer una pregunta. La respuesta honesta es "depende", y la pregunta más útil que hay debajo es: ¿qué estás tratando de comprar en esta etapa — un rango orientativo, o un plan que realmente puedas financiar?
Son dos productos distintos, con precios distintos, y confundirlos es de donde sale buena parte de la frustración de los compradores.
Cuándo el estimado no debería costar nada
Un rango orientativo, entregado después de una llamada corta, casi siempre debería ser gratis. Describes tus objetivos, tus restricciones, más o menos lo que tienes en mente. Un partner serio responde con bandas de costo y tiempo en órdenes de magnitud, más una lista corta de qué movería esos números hacia arriba o abajo.
Eso es información genuinamente suficiente para decidir si vale la pena profundizar este mes. Lo que no es suficiente — y esta es la parte que la gente pasa por alto — es para cerrar un contrato fijo de algo con complejidad real. Si un vendor te ofrece pasar directo de esa llamada de 20 minutos a un contrato firmado de precio fijo, pregúntate qué supuestos está haciendo en silencio en tu nombre.
Cuándo pagar por discovery es la jugada inteligente, no una alerta
El discovery vale la pena pagarlo cuando necesitas algo más específico que un rango:
- una rebanada de MVP priorizada que refleje de verdad tus restricciones reales,
- una revisión de riesgo técnico — integraciones, calidad de datos, evaluación de IA, compliance,
- opciones de arquitectura presentadas con trade-offs honestos, no solo un camino "recomendado",
- o un plan de sprints lo bastante detallado como para que se lo pases a alguien de finanzas y te diga que sí.
No estás pagando por un PDF, aunque el PDF pueda ser el entregable. Estás pagando por reducir el costo de equivocarte antes de equivocarte a una escala mucho mayor. Unos pocos miles gastados en discovery que revela que tu integración "simple" en realidad son tres integraciones, es dinero bien gastado.
Un estimado que se lee como un número exacto único y cero supuestos declarados es un artefacto de ventas, no un plan.
Qué incluye un estimado genuinamente bueno
Buscamos siempre el mismo puñado de cosas, sin importar quién lo escribió:
- Supuestos, por escrito — y específicamente, qué pasa con el número si alguno resulta equivocado.
- Qué entra y qué queda explícitamente fuera de esta primera entrega. No todo lo que algún día vas a querer. Solo esta rebanada.
- El modelo de entrega — sprints o fijo — y con qué frecuencia vas a ver algo funcionando de verdad.
- Términos de propiedad — repositorio, cuentas cloud, credenciales, explicados y no dados por sentado.
- Calidad por defecto — pruebas, CI, staging, documentación — declarados como incluidos, no como líneas que descubres faltantes después.
- Un rango o un número por fases, no falsa precisión al último dólar de algo que todavía nadie construyó.
Si a un estimado le falta más de uno de estos puntos, vale la pena preguntar directamente antes de seguir — no necesariamente es un motivo para cortar, pero sí una conversación pendiente.
Señales de alerta que vale la pena tomar en serio
- Un precio fijo instantáneo ofrecido tras una charla de quince minutos, para algo que claramente toca varios sistemas.
- Ninguna mención en ningún lado de quién es dueño de qué al terminar el engagement.
- "Revisiones ilimitadas" usado como gancho de venta, sin una definición de "listo" asociada — esa combinación suele significar que el scope creep es el modelo de negocio.
- Presión para firmar antes de ver algún ejemplo de cómo funciona realmente la entrega semanal con ese equipo.
Una secuencia que suele funcionarle bien a los compradores
- Llamada gratis — establecer encaje y obtener un rango orientativo. Quince a treinta minutos, sin compromiso de ningún lado.
- Discovery opcional de pago — solo si el rango confirmó que hay un proyecto real ahí, y necesitas definir una primera rebanada específica.
- Primer sprint — software funcionando de verdad que eres libre de rechazar, extender, o llevarte a otro lado por completo.
Nota que la propiedad no tiene que esperar al paso tres. Debería ser cierta desde el inicio.
Cómo pedir un estimado sin sonar difícil
A veces los compradores temen que pedir detalle — supuestos, límites de alcance, términos de propiedad — se vea como exigente antes de que la relación siquiera empiece. En la práctica suele pasar lo contrario. Los vendors que hacen bien esto normalmente se sienten aliviados cuando un comprador hace preguntas afiladas temprano, porque significa menos renegociación dolorosa después. Los vendors que se incomodan con "¿pueden escribir sus supuestos?" te están diciendo algo sobre cómo van a ir los cambios de alcance a mitad de proyecto.
Un guion simple que funciona: "Antes de seguir, ¿nos pueden mandar los supuestos detrás de este número, y qué lo cambiaría?" No es una pregunta agresiva. Es la pregunta que un vendor competente espera y uno débil teme.
En ConaiSoft ofrecemos una llamada exploratoria breve sin costo, específicamente para entender el encaje y bocetar una primera entrega realista. Si tu situación de verdad necesita un discovery más profundo, lo diremos con claridad — y definiremos exactamente qué produce ese trabajo de pago antes de que gastes nada en él.