Cuánto cuesta una aplicación empresarial: qué comparar

Dos aplicaciones pueden tener pantallas parecidas y requerir trabajos muy diferentes. Una lista de tareas para un equipo pequeño no tiene el mismo alcance que un sistema con permisos por empresa, documentos históricos e integraciones. El precio depende del comportamiento que debe ofrecer la solución y de las condiciones de su puesta en marcha. Contar pantallas es una aproximación insuficiente para comparar propuestas.

Esta guía no presenta tarifas de mercado ni precios de Domisys sin un alcance definido. Propone un método para entender qué se está presupuestando. Si buscas una cifra útil para decidir, el primer paso es concretar usuarios, operaciones, datos y dependencias. Una estimación inicial puede incluir hipótesis y cuestiones pendientes; debe identificarlas. Confundir esa orientación con una oferta cerrada suele producir discrepancias cuando aparecen requisitos que nadie había descrito.

Una función aparentemente sencilla puede contener varias decisiones. «Aprobar un presupuesto» exige saber quién puede aprobarlo, qué versión se aprueba y qué ocurre si cambia después. Si además intervienen varias empresas o importes con condiciones distintas, la regla necesita más definición. El esfuerzo no reside únicamente en añadir un botón, sino en construir y comprobar el comportamiento completo.

Para preparar el presupuesto, describe cada operación con un inicio, un resultado y sus excepciones. No es necesario escribir especificaciones técnicas extensas, pero sí acordar qué debe ocurrir. Pide que la propuesta distinga funciones incluidas, supuestos y exclusiones. Si una necesidad sigue abierta, puede presupuestarse una fase de análisis antes del desarrollo. Esa fase debe tener entregables propios, como un mapa del proceso, prioridades y criterios de aceptación, no una promesa indefinida de estudiar el proyecto.

El número de personas importa, pero también las diferencias entre sus responsabilidades. Un único perfil de acceso es distinto de combinar administración, supervisión, personal operativo y clientes externos. Cada perfil implica decisiones sobre qué puede consultar, modificar o aprobar. Los límites deben comprobarse tanto en la interfaz como en las operaciones del sistema; ocultar un botón no basta para definir un permiso.

Aclara desde qué dispositivos se trabajará y en qué situaciones. Una aplicación web adaptable al móvil no equivale a una aplicación nativa ni garantiza trabajo sin conexión. Si un equipo necesita operar en zonas sin cobertura, ese requisito debe figurar expresamente y estudiarse. También influyen la necesidad de adjuntar archivos, utilizar lectores o trabajar con varios idiomas. La propuesta debe explicar qué se probará, con qué combinaciones representativas y qué dispositivos quedan fuera del alcance inicial.

Conectar una aplicación con otra requiere revisar permisos, documentación, versiones y reglas de intercambio. Un acceso API no confirma que todas las funciones necesarias estén disponibles. Hay que decidir qué sistema mantiene cada dato, cómo se detecta una operación repetida y qué ocurre si el servicio externo deja de responder. Estas decisiones influyen en desarrollo, pruebas y mantenimiento.

Separa el trabajo del integrador de las cuotas o licencias de terceros. Pregunta quién contrata cada servicio, qué límites tiene y cómo se revisarán cambios posteriores. Si necesitas conectar una tienda, consulta el alcance de la integración entre Odoo y WooCommerce. Para otras herramientas, prepara una relación de las APIs disponibles con el servicio de integraciones a medida. No facilites claves en la solicitud inicial: primero debe definirse qué acceso hace falta y cómo se entregará de forma segura.

El presupuesto debe distinguir entre crear una aplicación vacía y trasladar información existente. Una exportación puede contener registros incompletos, duplicados o relaciones que no aparecen en un único archivo. También puede haber documentos adjuntos que deban conservarse separados de los datos operativos. Identificar estas situaciones antes del cambio permite estimar un trabajo que a menudo se descubre demasiado tarde.

Pide un inventario de conjuntos de datos: clientes, productos, trabajos, documentos y operaciones abiertas, por ejemplo. Para cada conjunto, indica origen, destino y comprobaciones previstas. Conservar un archivo consultable no es lo mismo que reconstruir todo su historial dentro de la aplicación. El presupuesto debe explicar la diferencia. Una muestra representativa ayuda a detectar problemas, pero no garantiza por sí sola el resultado de la carga completa. La conciliación final y el tratamiento de rechazos también necesitan responsable y tiempo asignados.

La inversión inicial puede incluir análisis, diseño, desarrollo, integración, migración, pruebas y formación. Los costes recurrentes pueden corresponder a alojamiento, licencias, copias, supervisión y mantenimiento. No todas las propuestas incluyen las mismas partidas. Por eso conviene comparar entregables y condiciones, no únicamente el total destacado en la primera página.

Solicita que se indique la periodicidad, el tratamiento de impuestos y qué condiciones pueden cambiar el coste. Aclara si las mejoras evolutivas están incluidas o se presupuestan aparte. También pregunta por almacenamiento, servicios externos y ampliación de usuarios cuando sean relevantes. Una aplicación aparentemente más económica puede necesitar trabajos adicionales para alcanzar el mismo resultado. La comparación es válida cuando ambas propuestas describen una solución equivalente, con un nivel similar de acompañamiento y una responsabilidad clara sobre su funcionamiento posterior.

Imagina dos propuestas para gestionar intervenciones. La primera incluye registrar solicitudes y asignarlas, pero excluye migración y formación. La segunda añade importación de trabajos abiertos, perfiles de acceso y sesiones de preparación con el equipo. Compararlas solo por su importe sería confundir alcances distintos. Este ejemplo es hipotético y no reproduce ofertas ni proyectos de clientes.

Construye una tabla con filas para cada necesidad y columnas para cada propuesta. Utiliza respuestas concretas: incluido con estas condiciones, excluido, pendiente o servicio adicional. Añade una columna con las pruebas que demostrarán la entrega. Si una propuesta incorpora una función que no necesitas, no la conviertas automáticamente en una ventaja. Si omite una dependencia imprescindible, aclara su impacto antes de contratar. El objetivo es saber qué solución podrás utilizar al terminar y qué trabajo seguirá pendiente, no escoger la lista más larga de prestaciones.

Dividir el proyecto puede facilitar decisiones, siempre que la primera fase cubra un recorrido útil. Por ejemplo, registrar, asignar, consultar y cerrar una solicitud. Las estadísticas avanzadas o una conexión adicional podrían quedar para otra fase si no son necesarias para operar. En cambio, dejar los permisos para después puede impedir el uso seguro de esa primera entrega.

Para cada fase, define entregables, dependencias, pruebas y condiciones de aprobación. Explica también qué ocurrirá si se decide no continuar. La primera versión debería poder utilizarse según el alcance contratado, sin depender de una ampliación que no se haya acordado. Revisa la guía sobre cuándo sustituir Excel por software a medida si todavía estás identificando el proceso prioritario. Una fase de análisis puede concluir que conviene configurar un ERP o mejorar un procedimiento antes de construir una aplicación nueva.

Como referencia de una alternativa configurable, la documentación de etapas y estados de tareas de Odoo 19 describe cómo organizar tareas. Esa documentación no acredita que una instalación concreta cubra todos los requisitos del proyecto.

Un presupuesto sólido explica cómo se comprobará el trabajo. Las pruebas deben incluir el recorrido habitual, datos incompletos, errores y límites de acceso relevantes. La revisión del cliente debe realizarse con ejemplos acordados y personas que conozcan la operativa. Una demostración comercial puede ayudar a entender la propuesta, pero no sustituye la aceptación de la solución concreta.

Define cómo se gestionarán los cambios de alcance. Una petición nueva no debe confundirse con corregir un comportamiento que ya estaba incluido. Documentar esa distinción protege la planificación y la relación con el proveedor. También conviene acordar cómo se comunican incidencias y quién decide prioridades. No hace falta anticipar cada detalle visual, pero sí saber qué proceso se seguirá cuando una decisión afecte a coste o plazo. Las fechas deben considerar las revisiones y dependencias del cliente, además del tiempo de desarrollo.

Antes de contratar, aclara qué recibirás al finalizar: acceso a la aplicación, documentación de uso, configuración necesaria, exportaciones y condiciones sobre código y otros entregables. La propiedad y los derechos deben quedar establecidos en la propuesta o el contrato. No se pueden deducir únicamente de que el desarrollo se describa como personalizado.

El mantenimiento necesita un alcance comprensible. Pregunta qué incluye una incidencia, por qué canal se atiende y qué tareas preventivas se realizan. Distingue el tiempo de respuesta del tiempo de resolución; una investigación puede depender de terceros o de reproducir un problema. Aclara también el procedimiento para cambiar de proveedor o finalizar el servicio. La continuidad no consiste solo en conservar una copia del código: necesita datos recuperables, documentación y accesos bajo control, según las responsabilidades que se hayan contratado.

Resume actividad, usuarios, operación principal, herramientas existentes y datos que quieres trasladar. Añade integraciones necesarias, restricciones de dispositivo y una fecha objetivo si responde a una necesidad real del negocio. Si dispones de un presupuesto orientativo, compartirlo puede ayudar a priorizar, pero no sustituye la definición del alcance. No presentes información confidencial ni bases reales de clientes en esta primera fase.

Domisys ofrece desarrollo de software y aplicaciones empresariales y estudia alternativas de configuración o adaptación cuando encajan mejor. Si lo que necesitas es una web informativa, utiliza la guía específica para pedir presupuesto de una web de empresa: su alcance es distinto. Para una aplicación, solicita una valoración describiendo tu proceso. La respuesta útil debe ayudarte a entender el trabajo propuesto, sus límites y el siguiente paso, sin apoyarse en cifras de ahorro no demostradas.