Aplicaciones web y móviles
Cómo construimos y publicamos una aplicación en las dos tiendas.
Casi todas las conversaciones sobre una aplicación móvil empiezan por el precio y deberían empezar por otra pregunta: si el problema necesita una app o se resuelve mejor con una web que se abra en el teléfono. Esta guía responde las dos: qué mueve el precio de una app en Guatemala, qué cuesta publicarla y mantenerla, y en qué casos conviene no hacerla.
Una aplicación en las tiendas cuesta más que una web equivalente, y no un poco: son dos publicaciones que revisar, dos ciclos de actualización y una barrera de instalación que el usuario tiene que decidir cruzar. Vale la pena cuando se necesita algo que el navegador no da bien.
Cuando el uso es diario y de alta frecuencia, y la instalación se justifica sola. Cuando hace falta funcionar sin conexión de forma seria. Cuando se necesitan notificaciones push confiables, cámara con procesamiento, GPS en segundo plano, lectura de códigos a diario o integración con el hardware del teléfono. Y cuando la app es el producto que se vende.
Cuando el uso es esporádico: consultar un estado, llenar un formulario, ver un catálogo, agendar una cita. Ahí una web bien hecha se abre desde un enlace, no exige instalar nada, se actualiza sin esperar la revisión de nadie y cuesta bastante menos. Muchos proyectos que empiezan pidiendo una app terminan siendo una web, y funcionan mejor.
Publicar primero la versión web, medir el uso real y construir la app cuando los números digan que hace falta. Es más barato, se ve funcionando antes y evita gastar meses en una aplicación que nadie instala.
Los rangos son orientativos y suponen una app para las dos plataformas construida con una base de código compartida, que es como se desarrolla hoy la mayoría. Están en dólares porque así se contrata el desarrollo móvil en Guatemala.
| Tamaño | Qué incluye | Tiempo típico | Rango orientativo |
|---|---|---|---|
| App de consulta | Iniciar sesión, ver información propia, recibir notificaciones. Sin lógica compleja y con un servidor que ya existe. | 6 a 10 semanas | USD 8,000 – 20,000 |
| App de operación | Varios roles, formularios, cámara o escaneo, trabajo con conexión intermitente y sincronización. Es la app de campo o de reparto típica. | 3 a 5 meses | USD 25,000 – 60,000 |
| App de producto | La aplicación es el negocio: cuentas, suscripciones, pagos dentro de la app, panel de administración y soporte continuo. Se construye por versiones. | Desde 5 meses, continuo | Desde USD 60,000 |
Si además hay que construir el servidor y las APIs desde cero, súmelo aparte: en muchos proyectos el trabajo del lado del servidor pesa tanto como el de la aplicación. Y si la app tiene que integrarse con un sistema de terceros, esa integración es la principal fuente de retrasos.
Apple cobra USD 99 al año por su Apple Developer Program y sigue corriendo mientras la app esté publicada. Google Play cobra USD 25 una sola vez. Las dos cuentas deben quedar a nombre de la empresa, no del proveedor: es el equivalente móvil de registrar el dominio a nombre de la agencia.
Cada versión que se publica pasa por una revisión. Suele resolverse en horas o pocos días, pero puede rechazarse, y ese rechazo tiene que estar previsto en el plan del proyecto. Una app que cobra suscripciones dentro de la aplicación entra en reglas adicionales, con su comisión correspondiente.
Las tiendas suben requisitos de privacidad, permisos y versiones mínimas del sistema operativo cada año. Una app publicada y abandonada deja de aceptarse en algún momento. Es un costo previsible, y hay que presupuestarlo.
Si la app es para uso interno de una empresa y no va a estar en las tiendas públicas, hay caminos de distribución interna que evitan la revisión. Conviene decidirlo antes de construir, porque cambia el enfoque técnico.
El error de presupuesto más común en un proyecto móvil es tratar el desarrollo como un pago único. Una aplicación viva tiene un costo anual que conviene estimar desde el principio.
La app habla con algo: un servidor, una base de datos, un servicio de notificaciones, almacenamiento de archivos. Ese costo escala con el uso y va desde unas decenas hasta varios cientos de dólares al mes.
Nuevas versiones de Android e iOS, cambios de política de las tiendas, bibliotecas que quedan obsoletas. Como referencia razonable, entre un 15 % y un 20 % anual del costo de desarrollo solo para que la app siga funcionando igual.
Los primeros meses siempre aparecen errores que no salieron en pruebas, porque los teléfonos reales son muchos y variados. Conviene contratar ese período con el proveedor que la construyó.
Toda app que se usa genera peticiones de cambio. Ese presupuesto es lo que decide si la aplicación mejora o se queda congelada el día del lanzamiento.
En Haricode preferimos construir primero la versión que permite aprender del uso real: la función central, bien hecha, en manos de usuarios de verdad. Es la forma más barata de descubrir que la mitad de lo planeado no hacía falta, y esa mitad es dinero.
Trabajamos con una base de código compartida para las dos plataformas, con el servidor y las APIs del mismo lado, para que la aplicación y la web hablen el mismo idioma. Y decimos con claridad cuándo un proyecto no necesita una app: la conversación honesta al principio evita una publicación cara que nadie instala.
Nuestras propias plataformas están construidas así: Vitalink tiene aplicación móvil porque el médico consulta su agenda desde el teléfono todos los días; otras funciones se quedaron en la web porque nadie las iba a usar de otra forma.
Una aplicación de consulta —iniciar sesión, ver información propia, recibir notificaciones— ronda entre USD 8,000 y USD 20,000. Una app de operación con varios roles, formularios y trabajo sin conexión, entre USD 25,000 y USD 60,000. Una app que es el producto en sí, con suscripciones y pagos, arranca sobre los USD 60,000 y se construye por versiones.
Menos de lo que parece. Con las herramientas actuales una sola base de código sirve para Android e iOS, así que el ahorro de dejar fuera iOS está en el diseño, las pruebas y la publicación, no en construir la mitad. Suele rondar el 20 % o el 25 %, no el 50 %. Vale la pena cuando el público real está casi todo en Android.
Apple cobra USD 99 al año mientras la app siga publicada; Google Play, USD 25 una sola vez. Las dos cuentas deben quedar a nombre de la empresa. Cada versión pasa por una revisión que suele resolverse en horas o pocos días, pero que puede rechazarse.
Si el uso es esporádico —consultar un estado, agendar, llenar un formulario, ver un catálogo—, una web que se abre en el teléfono cuesta menos, no exige instalar nada y se actualiza sin esperar la revisión de una tienda. La app se justifica con uso diario, trabajo sin conexión, notificaciones push o acceso al hardware del teléfono.
El servidor y los servicios que consume, la cuenta de Apple, y el mantenimiento evolutivo para seguir el ritmo de Android, iOS y las políticas de las tiendas. Como referencia razonable, entre un 15 % y un 20 % anual del costo de desarrollo solo para que la app siga funcionando igual que el primer día.
Una app de consulta, de seis a diez semanas. Una de operación, de tres a cinco meses. Los plazos suponen que el contenido y los accesos a los sistemas a integrar están disponibles: la espera por una credencial de un tercero es la causa más común de retraso en un proyecto móvil.
Cómo construimos y publicamos una aplicación en las dos tiendas.
Cuándo conviene una web antes que una app, y cuánto cuesta.
Si la app es una pieza de un sistema más grande.
Con el problema y quién la va a usar podemos decirte si necesita ser una app, en qué rango cae y qué construiríamos primero. Sin compromiso.
¿Prefieres hablarlo antes de escribir nada?
Agendar consultorio gratisMedia hora para desarmar el proceso que te cuesta horas. Cinco espacios al mes.