Escrito por
Nacho Seoane
Publicado el
Compartir
Para elegir entre aplicación web y app móvil en un MVP, empieza por la tarea que tus usuarios necesitan completar y dónde la realizan. Si pueden resolverla desde un enlace y un navegador, una aplicación web merece ser la primera opción a probar. Si el valor del producto depende de una capacidad concreta del dispositivo o de su funcionamiento fuera de la pantalla abierta, pide una prueba técnica antes de decidir.
Que tus clientes utilicen el móvil no obliga por sí solo a crear una app para las tiendas. Tampoco basta con llamar «PWA» a una web para asegurar que funcionará sin cobertura. Esta guía propone criterios y una ficha que puedes compartir con el equipo que vaya a diseñar la primera versión.
TL;DR — Elegir la primera plataforma
- Define una tarea completa. Describe qué debe conseguir el usuario y en qué situación.
- Comprueba los dispositivos. Móvil, ordenador, navegador y versión del sistema forman parte del alcance.
- Valora empezar desde un enlace. Una aplicación web puede ser suficiente cuando cubre el recorrido necesario.
- Separa instalación y funcionamiento sin conexión. Tener un icono no demuestra que se puedan guardar o enviar datos sin cobertura.
- Prueba el requisito que podría descartar una opción. Una demostración en el dispositivo previsto vale más que una lista genérica de capacidades.
- Incluye distribución y mantenimiento. Publicar en una tienda, gestionar versiones y atender incidencias también requiere trabajo.
- Elige una primera entrega verificable. Documenta qué evidencia justificaría añadir otra plataforma más adelante.
Qué comparas al hablar de web, PWA y app móvil
Una PWA es una aplicación web con capacidades adicionales; no es una tercera plataforma completamente separada. Una web adaptable puede funcionar en pantallas pequeñas y grandes desde el navegador. Una PWA puede incorporar instalación y determinadas funciones del dispositivo, con compatibilidad que hay que comprobar.
Una app móvil se instala para un sistema como iOS o Android. Puede desarrollarse específicamente para cada plataforma o mediante herramientas que comparten parte del trabajo. Esa elección técnica tampoco elimina la necesidad de probar cada dispositivo y recorrido incluidos en el proyecto.
MDN documenta que la instalación de una PWA y su experiencia varían según navegador y plataforma. También distingue instalación de funcionamiento sin conexión. Por eso conviene pedir capacidades concretas en el presupuesto, además del nombre de la tecnología. MDN: instalación de PWA.
Si aún estás decidiendo si necesitas desarrollar algo propio, empieza por la comparación entre SaaS y software a medida. La elección de web o móvil viene después de aclarar qué problema merece resolver ese producto.
Cómo decidir según el uso previsto
Compara las alternativas con el mismo recorrido y trata los requisitos imprescindibles como condiciones de aceptación. Esta matriz es una propuesta de Apogeo para preparar la conversación con un proveedor. No es una clasificación universal de tecnologías.
| Necesidad principal | Primera opción que valoraríamos | Qué pedir antes de decidir |
|---|---|---|
| Consultar, solicitar o aprobar desde un enlace | Aplicación web adaptable | Completar el recorrido en el móvil y ordenador previstos |
| Trabajar con tablas, documentos y administración | Aplicación web diseñada para esas tareas | Probar lectura, edición y permisos con contenido representativo |
| Acceder con frecuencia desde un icono | Web instalable/PWA o app móvil | Observar instalación, reapertura e inicio de sesión |
| Registrar trabajo con cobertura irregular | Comparar las opciones con una prueba sin conexión | Guardar, recuperar y sincronizar sin perder ni duplicar el registro |
| Depender de un periférico o función específica del sistema | Prueba técnica de compatibilidad antes de elegir | Demostrar la integración en el dispositivo y condiciones de uso |
| Distribuir a través de una tienda concreta | Aplicación preparada para ese canal | Revisar requisitos, cuenta responsable y proceso de publicación |
No conviertas estas filas en una suma de puntos que oculte un bloqueo. Si la tarea esencial no funciona en una opción, hay que resolver esa limitación o cambiar el alcance antes de comparar el resto.
Qué comprobar en una PWA antes de contratar
Pide una demostración de la función que condiciona el producto en los dispositivos previstos. «Se puede hacer» es el comienzo de la evaluación; el presupuesto debe concretar qué se hará y cómo se comprobará.
Instalación y avisos
La instalación y los permisos forman parte de la experiencia que el usuario tendrá que completar. WebKit documenta Web Push para aplicaciones añadidas a la pantalla de inicio desde iOS y iPadOS 16.4. La petición de permiso debe responder a una interacción del usuario. Tener una página abierta en el navegador no basta para asumir ese recorrido. WebKit: Web Push en iOS y iPadOS.
Si el aviso es esencial, prueba instalación, aceptación y rechazo del permiso, y apertura del contenido desde la notificación. Define qué verá el usuario si no activa los avisos. El permiso concedido no garantiza que lea cada mensaje.
Trabajo sin conexión
Especifica qué puede consultar o registrar el usuario sin red y qué ocurrirá al recuperarla. MDN explica cómo las aplicaciones web pueden utilizar un service worker y caché para ofrecer funciones sin conexión. Es una capacidad que se implementa; no aparece automáticamente al añadir un icono. MDN: funcionamiento sin conexión.
Nuestra prueba propuesta consiste en abrir el producto con conexión, cargar la tarea, desconectar la red, guardar un cambio y volver a conectar. Comprueba también qué sucede al cerrar y reabrir la aplicación y cuando otro usuario modifica el mismo registro. Son situaciones distintas y pueden necesitar soluciones diferentes. Una app móvil también debe definir ese comportamiento.
Publicación en tiendas
Si el encargo incluye App Store, pide un alcance de publicación específico. Apple indica en su apartado 4.2 que la aplicación debe aportar funciones, contenido e interfaz más allá de una web reempaquetada. Convertir una web en un contenedor instalable no garantiza su aceptación. Apple: funcionalidad mínima.
Deja escrito quién prepara la cuenta, los materiales, la versión que se envía y la respuesta a incidencias de revisión. Consulta los requisitos del canal elegido cuando prepares el lanzamiento. No presupongas que todas las tiendas o formas de distribución siguen el mismo proceso.
Dos ejemplos para aplicar los criterios
La misma empresa puede necesitar experiencias distintas según quién hace el trabajo. Los siguientes ejemplos son ficticios y sirven para explicar la decisión, sin atribuir resultados a clientes.
En un portal de encargos, el cliente recibe un enlace, revisa una propuesta y la aprueba; el equipo gestiona varias propuestas desde el ordenador. Probaríamos primero una aplicación web adaptable. La primera comprobación sería completar ese recorrido con los permisos adecuados. La necesidad de una app móvil tendría que apoyarse en una limitación observada o en un uso adicional concreto.
En una herramienta para visitas de campo, una persona registra datos durante la jornada y puede perder cobertura. Aquí la decisión depende de guardar y recuperar registros, y de las funciones específicas que requiera el trabajo. Pediríamos una prueba técnica acotada antes de presupuestar el producto completo. Esa prueba puede favorecer una PWA o una app móvil según los dispositivos y requisitos comprobados.
El alcance elegido debe trasladarse al presupuesto del MVP, incluyendo las pruebas, la operación y las tareas que quedan fuera de la primera entrega.
Ficha para decidir y comparar propuestas
Una ficha útil relaciona la elección con una prueba y una condición para revisarla. Copia este recurso propio de Apogeo y complétalo antes de pedir propuestas. Si un dato es desconocido, deja pendiente la decisión que depende de él.
Producto y responsable de la decisión:
Usuario de la primera versión:
Tarea completa que debe resolver:
Lugar y frecuencia de uso:
Dispositivos, sistemas y navegadores previstos:
Conexión disponible durante la tarea:
Cómo llegará el usuario por primera vez:
Requisito que podría descartar una opción:
Por qué es imprescindible:
Prueba que debe demostrarlo:
Dispositivo y condiciones de la prueba:
Resultado esperado:
Resultado observado y evidencia:
Limitaciones o preguntas pendientes:
Opción propuesta: web / web con capacidades PWA / app móvil
Motivo de elección:
Funciones y plataformas incluidas:
Funciones y plataformas aplazadas:
Responsable de distribución y mantenimiento:
Evidencia que justificaría añadir otra plataforma:
Decisión, responsable y fecha de revisión:No hace falta desarrollar dos productos completos para rellenarla. Pide primero la comprobación más pequeña que permita despejar una incertidumbre importante. Evita aprobar el alcance definitivo mientras el requisito decisivo siga basado en una suposición.
Preguntas frecuentes
Estas respuestas ayudan a concretar qué pedir en una propuesta de primera versión. La decisión final depende de las pruebas y del alcance de tu producto.
¿Si mis usuarios entran desde el móvil necesito una app?
Puedes empezar evaluando una aplicación web adaptada al móvil. Comprueba que permite terminar la tarea con comodidad en los dispositivos previstos. Si el recorrido exige una capacidad que esa solución no resuelve, investiga la alternativa móvil. El tamaño de la pantalla es un criterio; las condiciones de uso también cuentan.
¿Una PWA funciona siempre sin conexión?
Debe tener implementado el comportamiento sin conexión que necesitas. Pide que se diferencien consultar información ya cargada, guardar un borrador y enviar datos al recuperar la red. Verifica cada caso. Instalar la aplicación no demuestra que todos esos recorridos funcionen ni que todas las funciones estén disponibles en cualquier navegador.
¿Una aplicación web siempre cuesta menos?
El coste depende del alcance y de lo que haya que comprobar y mantener. Compara propuestas que incluyan la misma tarea, dispositivos, permisos, integraciones y condiciones de uso. Añade distribución y operación. No utilices un porcentaje genérico de ahorro para decidir una arquitectura sin conocer esos requisitos.
¿Tengo que lanzar para iOS y Android a la vez?
Incluye las plataformas que necesite el grupo de usuarios con el que vas a validar el producto. Si eliges una sola, explica a quién dejas fuera y cómo limita lo que puedes aprender. Una prueba con usuarios de un sistema no demuestra que el recorrido funcione igual en el otro.
¿Puedo convertir después mi web en una app móvil?
Pueden reutilizarse partes del producto, pero hay que evaluar el trabajo de adaptación. Pide que el proveedor distinga datos, servicios e interfaz, y explique qué conservaría y qué tendría que rehacer. No des por hecho que una conversión automática resuelve experiencia, permisos, pruebas o publicación en tiendas.
¿Estar en una tienda me traerá usuarios?
La distribución debe acompañarse de un plan concreto para llegar a las personas adecuadas. Define cómo conocerán el producto, por qué lo probarán y qué tarea les hará volver. Publicar una aplicación no demuestra adquisición ni retención. Mide esos comportamientos después del lanzamiento con criterios acordados.
Recomendación final
Empieza por una aplicación web cuando resuelva el recorrido necesario y no deje sin demostrar un requisito crítico. Si una capacidad del dispositivo, el uso sin conexión o el canal de distribución condicionan el producto, encarga primero una prueba acotada de ese punto. Elige con su resultado y registra qué podría hacerte reconsiderar.
En un proyecto de desarrollo de producto digital, esta decisión debería quedar conectada al alcance, las pruebas y la continuidad. La ficha permite comparar propuestas por lo que van a demostrar y entregar.
En resumen
- La tarea orienta la elección. Describe el resultado que necesita el usuario y sus condiciones de uso.
- Web y móvil no se deciden solo por pantalla. Comprueba dispositivos, conexión y recorrido.
- Una PWA sigue siendo una aplicación web. Sus capacidades concretas requieren implementación y pruebas.
- Instalación, avisos y trabajo sin conexión se verifican por separado. No los des por incluidos en una etiqueta.
- Una prueba acotada puede resolver la decisión. Empieza por el requisito que podría bloquear la alternativa.
- Distribución y mantenimiento pertenecen al alcance. Asigna responsables desde la propuesta.
- La primera plataforma puede cambiar con evidencia. Registra qué aprendizaje justificaría ampliar el producto.
Fuentes y referencias
Estas fuentes respaldan las capacidades y restricciones técnicas citadas. La matriz, los ejemplos ficticios y la ficha son propuestas de Apogeo. Consultadas el 10 de noviembre de 2026.
- MDN: instalación de aplicaciones web progresivas.
- MDN: funcionamiento sin conexión y en segundo plano.
- WebKit: Web Push para aplicaciones web en iOS y iPadOS.
- Apple: App Review Guidelines, funcionalidad mínima.
El siguiente paso
Cuéntanos qué tarea debe resolver tu primera versión y dónde se utilizará. Añade los dispositivos previstos y cualquier requisito que todavía no hayas podido comprobar. Puedes compartir esa información al plantearnos tu producto para conversar sobre su alcance.



