Cotización sin alcance escrito
Un precio en un mensaje, sin documento que diga qué incluye y qué no. Todo lo que no esté escrito se va a discutir después, con el proyecto a medias y sin margen de negociación.
Es la primera pregunta de toda reunión y la que peor se responde. «Depende» es cierto pero inútil; un número suelto sin supuestos es peor, porque se convierte en una expectativa que nadie va a cumplir. Esta guía explica qué determina realmente el precio de un desarrollo en Guatemala, cómo se estructura una cotización seria y qué señales indican que un proyecto barato va a terminar caro.
Un desarrollo a medida se cotiza por esfuerzo: cuántas personas, de qué perfil, durante cuántas semanas. Todo lo que cambia el precio termina cambiando una de esas tres variables. Por eso una cotización sin alcance escrito no es una cotización, es una intención.
Primera, cuántas pantallas distintas hay que diseñar y construir. Segunda, cuántos roles de usuario con permisos diferentes. Tercera, cuántas integraciones con sistemas de terceros, que son el mayor generador de retrasos. Cuarta, si hay aplicación móvil además de web, porque son dos entregas y dos publicaciones en tiendas. Quinta, qué tan crítico es el sistema: uno que maneja dinero, salud o documentos legales exige controles, auditoría y pruebas que uno interno no necesita.
El diseño visual, si se parte de una identidad existente. La cantidad de registros que va a guardar. Y el lenguaje o la tecnología: quien cotiza distinto por «hacerlo en tal tecnología» normalmente está cotizando su comodidad, no su valor.
Los rangos siguientes son orientativos y sirven para saber en qué conversación se está entrando, no para reemplazar una cotización. Están expresados en dólares porque así se contrata la mayoría del desarrollo en Guatemala.
| Tamaño | Qué incluye | Tiempo típico | Rango orientativo |
|---|---|---|---|
| Herramienta puntual | Una función concreta: un cotizador, un panel de reportes, una integración entre dos sistemas, un formulario que alimenta la operación. Un rol, pocas pantallas. | 3 a 6 semanas | USD 3,000 – 9,000 |
| Sistema de operación | El software que sostiene un área completa: varios roles, catálogos, permisos, reportes y una o dos integraciones. Web, y móvil si hace falta. | 3 a 6 meses | USD 15,000 – 60,000 |
| Plataforma de producto | Un sistema que se vende a varios clientes: multiempresa, suscripciones, panel de administración, alta disponibilidad y soporte. Se construye por versiones, no de una vez. | Desde 6 meses, continuo | Desde USD 60,000 |
Estos rangos suponen alcance cerrado y contenido provisto por el cliente. Un proyecto que arranca sin definir el alcance suele terminar entre un 30 % y un 60 % por encima de su primera estimación, sin importar el proveedor.
La cotización más honesta a veces es «no lo desarrolle». Si su necesidad es una agenda de clínica, un sistema de laboratorio o un chatbot de WhatsApp, existen productos que ya resuelven el 90 % y cuestan una fracción. Nosotros mismos preferimos empezar por ahí: Vitalink para clínicas, NexaLab para laboratorios, Dilo para atención por WhatsApp.
Cuando el proceso que da la ventaja competitiva es el que no cabe en ningún producto. Cuando el costo de licencias por usuario supera al del desarrollo en dos o tres años. Cuando hay que integrarse con sistemas que ningún producto contempla. O cuando el software es el producto que se va a vender.
Producto estándar para lo común y desarrollo a medida solo para lo particular, sobre la misma base. Es más barato, se ve funcionando antes y reduce el riesgo de invertir seis meses en algo que nadie usa.
Ninguna de estas señales significa mala fe. Casi todas significan que el riesgo se está trasladando al cliente sin decirlo.
Un precio en un mensaje, sin documento que diga qué incluye y qué no. Todo lo que no esté escrito se va a discutir después, con el proyecto a medias y sin margen de negociación.
Un monto fijo por «el sistema completo» cuando nadie ha definido cuántas pantallas hay. O el proveedor pierde dinero y recorta calidad, o cotizó con un colchón que usted está pagando.
Si al terminar el proyecto el repositorio, el dominio y las credenciales no quedan a nombre de la empresa, no compró un sistema: alquiló una dependencia.
Un plan que entrega todo el último día concentra el riesgo en el peor momento. Debe haber algo usable en producción en las primeras semanas, aunque sea pequeño.
Si el único lugar donde se prueba es producción, cada corrección es una apuesta. Un ambiente separado no es un lujo, es lo que permite arreglar sin romper.
El software vive después de entregarse: se actualiza, se corrige y se adapta. Si nadie habló del costo de mantenerlo, ese costo va a aparecer igual, pero como sorpresa.
Empezamos por un diagnóstico corto y sin costo: qué proceso duele, cuánto cuesta hoy hacerlo a mano y qué pasaría si se resolviera. De ahí sale si conviene un producto existente, un desarrollo a medida o simplemente ordenar lo que ya hay.
Si hay proyecto, se cotiza por fases con alcance cerrado por fase, entregando algo usable al final de cada una. Los supuestos se escriben (quién entrega los contenidos, qué accesos hacen falta, qué se considera fuera de alcance) porque los supuestos no escritos son la causa número uno de proyectos que terminan mal.
El código, los repositorios, los dominios y las credenciales quedan a nombre del cliente desde el primer día. No porque sea generoso, sino porque un cliente atrapado es un cliente que se va en cuanto puede.
Una aplicación móvil sencilla, con registro de usuarios y unas pocas pantallas conectadas a un servicio propio, suele ubicarse en el rango de una herramienta puntual o un sistema de operación pequeño. Lo que la encarece no es la aplicación en sí sino lo que hay detrás: el servicio que la alimenta, y la publicación y mantenimiento en dos tiendas con sus revisiones.
Sí, y es lo normal en proyectos por fases: cada fase se cotiza, se aprueba y se factura contra entrega. Es también la mejor protección del cliente, porque puede detenerse al final de cualquier fase con algo funcionando en la mano.
Casi siempre porque están cotizando cosas distintas: uno incluye pruebas, ambiente de prueba, documentación y garantía; otro incluye solo escribir el código. Comparar precios sin comparar alcances lleva a elegir mal. Pida a los dos que escriban qué entregan.
Como referencia de la industria, entre el 15 % y el 20 % anual del costo de construcción cubre correcciones, actualizaciones de seguridad y pequeñas mejoras. Puede ser menos si el sistema es estable y no cambia, o más si crece de forma continua.
Para una herramienta puntual, puede ser una buena decisión y más económica. El riesgo aparece en sistemas de los que depende la operación: una sola persona significa que no hay quien continúe si se enferma, se va o cambia de trabajo. La pregunta correcta es qué pasa con ese sistema dentro de dos años.
A qué clase de proveedor le corresponde cada rango de precio.
Ya con el presupuesto, cómo escoger a quién se lo encargás.
Cómo trabajamos un proyecto a la medida de principio a fin.
Qué cambia en el precio cuando además hay app móvil.
Si lo que hace falta es un sitio y no un sistema entero.
Cuéntanos qué proceso quieres resolver y cómo se hace hoy. Te decimos si hay producto que ya lo resuelve, si conviene desarrollarlo y en qué orden de magnitud está.
¿Prefieres hablarlo antes de escribir nada?
Agendar consultorio gratisMedia hora para desarmar el proceso que te cuesta horas. Cinco espacios al mes.