"Tengo tres cotizaciones y no sé cómo compararlas." Es una de las frases que más escuchamos cuando una empresa nos busca para hacer una app. El cuadro suele ser parecido: una propuesta cuesta varias veces lo que otra, una segunda promete entregar muy rápido y la tercera pide una reunión antes de dar cualquier número. Las tres dicen "app móvil" en el asunto del correo. Cada una describe una app distinta.
Pasa cuando una empresa ya decidió que necesita una aplicación y todavía no sabe con quién hacerla. En Monterrey la oferta es amplia —freelancers, agencias, consultoras, empresas de software— y la diferencia entre una buena elección y una mala rara vez está en el precio del primer documento.
Este artículo es para esa etapa previa: cómo evaluar a un proveedor, qué preguntarle, qué señales revisar y qué debe quedar por escrito antes de firmar. Si ya pasaste por ahí y quieres ver cómo trabajamos nosotros, lo explicamos en nuestra página de desarrollo de apps en Monterrey para empresas.
La metáfora del contratista de obra
Imagina que comparas tres presupuestos de obra que llegaron antes de los planos. Si le pides a tres contratistas "una casa de dos pisos", uno te cotiza con acabados básicos, otro con cimentación para un tercer piso y otro con cocina integral y cisterna. Los tres números son honestos. Solo que cada uno imaginó una casa distinta.
En construcción el orden está claro: primero el terreno, después los planos, al final el presupuesto. El contratista serio pide ver el terreno antes de hablar de dinero.
Una app funciona igual. El "terreno" es tu operación: quién va a usar la aplicación, dónde y con qué sistemas tiene que hablar. Los "planos" son el alcance definido: pantallas, flujos, roles, integraciones y lo que entra en la primera versión. Y el presupuesto solo tiene sentido cuando existen los planos.
Punto clave
Por qué las cotizaciones de una app son tan distintas
Detrás de cada número hay una lista de supuestos, escrita o no. Los que más mueven el alcance de una app empresarial son estos:
- Funcionamiento sin conexión. Una app que trabaja en bodegas, rutas o plantas sin señal necesita guardar datos en el teléfono y sincronizarlos después, resolviendo qué pasa si dos personas cambiaron lo mismo. Es de lo que más se subestima al cotizar.
- Integraciones. Cada sistema con el que la app tiene que leer o escribir —el ERP, la facturación, un CRM— suma desarrollo y, sobre todo, pruebas.
- Roles y permisos. Una app con un solo tipo de usuario es un proyecto distinto a una donde vendedor, supervisor y almacenista ven cosas diferentes.
- El lado de la oficina. Casi toda app de operación necesita un panel web donde alguien administra catálogos, usuarios y reportes. Lo explicamos en cómo trabajan juntas una aplicación web y una app móvil; si una cotización no lo menciona, pregunta si está incluido o si se da por hecho que no hace falta.
- Publicación y mantenimiento. Subir la app a App Store y Google Play, y mantenerla viva después, también es trabajo.
Una cotización baja puede ser válida para un alcance menor; lo que hay que averiguar es qué alcance cotizó. Los supuestos que no quedan por escrito suelen reaparecer después como cambios de alcance.
El descubrimiento: los planos antes del presupuesto
La forma más confiable de que las cotizaciones sean comparables es hacer primero un descubrimiento: un trabajo enfocado en entender la operación antes de diseñar la solución. Es como trabajamos en IS del Norte, y es lo que recomendamos aunque el proyecto termine con otro equipo.
Un descubrimiento bien hecho responde preguntas como:
- ¿Qué problema operativo resuelve la app y cómo se sabrá que lo resolvió?
- ¿Quiénes la van a usar y en qué condiciones? Un gerente en su escritorio usa la app de otra forma que un almacenista con guantes, sol directo en la pantalla y una mano ocupada.
- ¿Con qué sistemas tiene que conectarse y quién administra cada uno?
- ¿Qué entra en la primera versión y qué puede esperar?
El resultado es un documento de alcance con los flujos, las prioridades y los supuestos explícitos. Con él en la mano, cualquier proveedor puede cotizar lo mismo, y tú puedes comparar las propuestas por lo que ofrecen.
Cuando una cotización llega sin que nadie haya preguntado cómo opera tu empresa, está basada en supuestos. Pide que te los escriban: es la forma más rápida de saber qué estás comprando.
Qué evaluar en una empresa de desarrollo de apps
Que pregunte antes de proponer
El primer filtro es la conversación inicial. Un buen proveedor dedica más tiempo a entender tu operación que a presentar su portafolio. Si en la primera reunión ya hay una propuesta de pantallas, la solución se diseñó antes de conocer el problema.
Apps parecidas a la tuya, funcionando
Pide ver aplicaciones que el equipo haya construido y que estén en uso: publicadas en las tiendas o, si son internas, en una demostración. La experiencia que más pesa es la del tipo de problema: una app que opera en campo y conectada a un ERP exige cosas distintas a una app de consumo.
Criterio técnico explicado en lenguaje de negocio
Todo equipo tiene tecnologías preferidas. Lo que importa es que sepa explicarte por qué la que propone conviene a tu caso: nativa o multiplataforma, qué base de datos, dónde vivirá la información. Una buena señal es que el proveedor también te diga en qué casos su tecnología preferida sería la opción equivocada.
Avance visible y frecuente
Pregunta cómo vas a ver el progreso. Lo sano es recibir versiones de prueba que puedas instalar en tu teléfono con regularidad, revisar funcionalidad real y corregir el rumbo a tiempo. Un proyecto donde ves la app completa por primera vez al final concentra todo el riesgo en el último día.
Quién hace el trabajo
Averigua quién va a construir la app, quién será tu contacto y si alguna parte se subcontrata. Subcontratar es válido; lo importante es saber quién responde por el resultado.
Qué debe quedar por escrito antes de firmar
Alcance y supuestos
Qué incluye la primera versión, qué queda fuera y qué se asumió en cada punto: plataformas, número de roles, integraciones, funcionamiento sin conexión, panel web. Lo que no está escrito se interpreta, y cada parte lo interpreta a su favor.
Cuentas y servidores
Conviene acordar desde el inicio dónde se publica la app y dónde vive la información:
- Las cuentas de las tiendas: la app puede publicarse en las cuentas de desarrollador de tu empresa o en las del proveedor. Hay equipos que publican en sus propias cuentas para salir más rápido. Si se usan las de tu empresa, Apple y Google piden un número D-U-N-S para cuentas de organización, y conviene tramitarlo al inicio del proyecto.
- Servidores, dominios y base de datos: a nombre de quién quedan y quién tiene acceso de administrador.
Cómo se manejan los cambios
A mitad del proyecto vas a querer cambiar algo; es normal, porque ver la app funcionando aclara ideas. Lo que debe quedar escrito es el procedimiento: quién aprueba un cambio, cómo se estima su impacto y cómo se registra.
Soporte después del lanzamiento
Apple y Google publican versiones nuevas de sus sistemas operativos cada año, y las tiendas van actualizando sus requisitos para las apps publicadas. Una app necesita mantenimiento para seguir funcionando bien, aunque nadie toque su código. Define qué cubre el soporte, cómo se reportan los errores, en qué tiempo se atienden y cómo se cobra.
Pruebas y aceptación
Acuerda cómo se da por aceptada una entrega: en qué dispositivos se prueba, quién de tu equipo prueba y con qué casos reales. Una entrega está terminada cuando funciona en los teléfonos de tu equipo.
Señales de alerta al comparar proveedores
Cada una de estas señales merece una pregunta antes de firmar:
- La cotización llegó cerrada antes de que alguien preguntara cómo opera tu empresa.
- La cotización omite los supuestos y la lista de lo que queda fuera.
- El plan termina el día del lanzamiento.
- La primera versión incluye todo lo que pediste y la propuesta trae una sola etapa.
Preguntas para hacerle a cada proveedor de apps
Llévalas a cada reunión y compara las respuestas lado a lado. Te dirán más que el precio.
- ¿Qué necesitas saber de mi operación antes de cotizar? La calidad de la respuesta anticipa la calidad del proyecto.
- ¿Qué supuestos hay detrás de esta cotización y qué queda fuera?
- ¿Qué tecnología propones y por qué para este caso? Pide también en qué casos no la recomendarías.
- ¿Qué app parecida tienen funcionando?
- ¿Cómo voy a ver el avance y cuándo podré instalar una versión de prueba?
- ¿Quién va a trabajar en mi proyecto y quién es mi contacto?
- ¿En qué cuentas se publica la app y dónde quedan los servidores?
- ¿Cómo se maneja un cambio a mitad del proyecto?
- ¿Qué cubre el soporte después del lanzamiento y cómo se cobra?
Tres preguntas que te toca responder a ti
El proveedor también te va a evaluar, y las respuestas a estas preguntas mejoran cualquier cotización:
- ¿Qué problema resuelve la app, en una oración? Si cuesta trabajo escribirla, el descubrimiento es el primer paso.
- ¿Quién será el responsable interno del proyecto? Alguien con tiempo asignado para decidir, probar y aprobar.
- ¿Cómo vas a medir si funcionó? Pedidos capturados en campo, errores que dejaron de ocurrir, horas de captura que desaparecieron.
La pregunta que ordena la decisión
Cuando tengas las tres propuestas enfrente, pregúntate cuál de los tres proveedores entendió mejor tu operación. Suele ser el que hizo más preguntas, el que escribió sus supuestos y el que te dijo que no a algo. El precio importa, y se puede comparar con justicia cuando los tres cotizan la misma app.
En IS del Norte construimos software para empresas desde 1999; hoy desarrollamos apps con Flutter conectadas a la operación de cada cliente, incluido Intelisis ERP. Empezamos con un descubrimiento, para que el cliente sepa qué va a recibir. Si quieres revisar tu proyecto con esa lógica, puedes escribirle a nuestro equipo.
Fuentes: Apple Developer, "D-U-N-S Number" (Account Help); Google, "Boosting trust and transparency in Google Play", Android Developers Blog (julio de 2023), sobre el número D-U-N-S para cuentas de organización en Play Console.
