Es la primera pregunta de casi todo el mundo, y la respuesta honesta incomoda: depende del alcance, y el alcance no se conoce hasta entender qué tiene que hacer la aplicación.
Eso no significa que estés a ciegas. Los factores que mueven el precio son conocidos y puedes evaluarlos tú mismo antes de hablar con nadie. Este artículo te da esa lista.
Los seis factores que mueven el costo
1. Cuántas pantallas tiene
Es el factor más directo. Una herramienta con cinco pantallas cuesta una fracción de una con cuarenta. Y no es solo dibujarlas: cada pantalla trae su lógica, sus validaciones y sus casos borde.
Un ejercicio útil: haz una lista de todo lo que un usuario tiene que poder hacer. Cada verbo de esa lista suele ser al menos una pantalla.
2. Cuántos tipos de usuario
Una aplicación donde todos ven lo mismo es mucho más simple que una con administrador, supervisor y operario, cada uno con permisos distintos. Cada rol multiplica los casos a diseñar, desarrollar y probar.
3. Si tiene que conectarse con otros sistemas
Integrar con un sistema contable, con una pasarela de pago o con el ERP que ya usas puede ser sencillo o puede ser la mitad del proyecto. Depende enteramente de qué tan bien documentado y abierto esté ese otro sistema.
Es también el factor con más incertidumbre: hasta que no se revisa, nadie puede afirmar cuánto costará.
4. Si necesita versión móvil
Una aplicación web bien hecha se adapta al celular. Pero si necesitas una app instalable —con cámara, notificaciones push o uso sin conexión— eso es un desarrollo adicional, no un ajuste.
5. Cuántos datos maneja y de qué tipo
No es lo mismo una herramienta interna para diez personas que una plataforma que va a recibir miles de registros diarios. Y si maneja datos sensibles, hay requisitos de seguridad que no son opcionales.
6. Qué tan claro tienes el proceso
Este es el factor que más subestiman los clientes y el que más encarece los proyectos en la práctica. Si el proceso está definido, el desarrollo avanza. Si se va descubriendo sobre la marcha, cada hallazgo es un cambio de alcance.
Por qué no publicamos una lista de precios
Podríamos poner un rango amplio en la web. No lo hacemos por una razón práctica: un rango tan amplio que sea honesto no te sirve para decidir, y uno estrecho sería mentira para la mayoría de los casos.
Lo que sí hacemos es darte el precio junto con el alcance detallado antes de empezar, para que sepas exactamente qué incluye y qué no. Sin partidas que aparezcan a mitad de camino.
Cómo comparar cotizaciones
Si estás pidiendo varias, estas preguntas te van a distinguir una propuesta seria de una barata:
- ¿Qué incluye exactamente? Un precio sin alcance escrito no es una cotización, es un número.
- ¿Qué pasa si pido un cambio? Debe estar claro qué entra en el alcance y qué se cotiza aparte.
- ¿De quién es el código al terminar? Debería ser tuyo, y debería estar por escrito.
- ¿Qué incluye el soporte posterior? Y hasta cuándo.
- ¿Quién hace el trabajo? Si se subcontrata, pregunta a quién.
Cuidado con lo muy barato
Una cotización notablemente más baja que las demás suele explicarse por una de tres cosas, y ninguna te conviene:
Entendieron un alcance menor. Van a llegar a la mitad, descubrir lo que falta y pedir más presupuesto. El costo final termina siendo mayor.
Van a usar una plantilla. Que puede estar bien si tu caso es estándar, pero entonces no estás comprando desarrollo a la medida.
No contemplaron las pruebas. Es lo primero que se recorta y lo que más caro sale después.
La forma barata de reducir el costo
No es negociar el precio por hora. Es reducir el alcance de la primera versión.
Casi todos los proyectos pueden partirse: una versión inicial que resuelva el problema principal, y el resto después, cuando la primera esté en uso y sepas qué hacía falta de verdad.
Esto abarata el arranque, entrega valor antes y —lo más importante— evita construir funciones que nadie termina usando. En casi todos los proyectos que hemos hecho, la lista de "imprescindibles" del día uno se recorta sola cuando el equipo empieza a usar la herramienta.