Si necesitas que otras personas consulten información, trabajen con sus datos o utilicen una función del móvil, el formato influye en lo que podrán hacer y en cómo recibirán la solución. Una web, una aplicación web, una PWA y una app móvil pueden servir a necesidades distintas.
La misma idea puede resolverse de varias formas. No tienes que elegir la tecnología antes de hablar con quien vaya a construirla: aporta la tarea, el resultado y las condiciones importantes. Ricardo puede comparar contigo las opciones y comprobar las limitaciones que cambien la decisión.
Empieza por la tarea
Para explicar la necesidad puede servir esta frase, sin convertirla en un formulario obligatorio:
Cuando ocurre ___, una persona debe poder ___ con ___ y obtener ___.
Por ejemplo: “Cuando toma una decisión en un proyecto, una persona debe poder registrarla con su motivo y encontrarla después de cerrar el navegador”.
Esta frase permite distinguir dos trabajos. Consultar una decisión publicada puede resolverse con una página y un enlace. Crear, corregir y recuperar decisiones necesita comportamiento de aplicación.
En este artículo usamos “web” para referirnos a una experiencia principalmente informativa y “aplicación web” para el trabajo con datos y estados. Es una distinción práctica de alcance. Una PWA sigue siendo una aplicación web, con capacidades adicionales; no es un escalón obligatorio entre navegador y móvil.
Qué conviene comprobar en cada opción
| Opción | Cuándo puede encajar | Distribución | Comprobación decisiva |
|---|---|---|---|
| Web principalmente informativa | Consultar contenido, entender un servicio o completar una acción breve | URL, buscador, enlace o QR | Que el recorrido se complete con información y la acción prevista |
| Aplicación web | Crear, modificar, buscar y recuperar datos desde un navegador | URL, con acceso adaptado al contexto | Guardado, permisos, continuidad y errores |
| PWA | Una aplicación web necesita instalación o una experiencia útil con conectividad irregular | Web e instalación compatible | Qué funciona en los navegadores/dispositivos objetivo y sin conexión |
| App móvil específica | Una necesidad comprobada depende del sistema o de una capacidad que la web no cubre | Plataformas y tiendas concretas | La función del dispositivo, su publicación y el mantenimiento de cada plataforma |
Una PWA puede utilizar mecanismos web de instalación, almacenamiento y funcionamiento sin red. Hay que diseñar qué recursos y datos estarán disponibles; tener un icono no resuelve la continuidad. La disponibilidad de cada capacidad depende del navegador y plataforma. MDN describe estas capacidades, consultado el 10/09/2026.
Una app móvil añade decisiones de plataforma, distribución y mantenimiento. Las bases de Android y las reglas de revisión de Apple, consultadas el 10/09/2026, muestran contextos que deben revisarse cuando esa sea la vía elegida.
El mismo ejemplo en cuatro situaciones
Cuaderno de decisiones es un ejemplo ficticio para registrar decisiones de un proyecto, su motivo y estado. La idea se mantiene; cambia el contexto.
Consultar una decisión por enlace
Una persona recibe un enlace a una decisión publicada, lee su contexto y vuelve al proyecto. Una web puede resolver esa tarea sin instalación ni edición.
Antes de añadir una cuenta, pregunta para qué hace falta: ¿la información es privada, hay que identificar quién la consulta o solo se quiere facilitar la lectura? La respuesta afecta acceso y operación, aunque el aspecto de la página sea parecido.
Crear editar y recuperar desde el navegador
Ahora la persona crea un proyecto, registra una decisión, la corrige, la filtra y vuelve a encontrarla otro día.
Esto describe una aplicación web. Su recorrido incluye crear, guardar, recuperar y entender los fallos. El navegador es el lugar donde se usa; no reduce el proyecto a una página informativa.
Puedes describirlo en el briefing de aplicación si te ayuda. Dónde se guarda el dato —en ese navegador, en un servidor o en ambos— es una decisión que el profesional debe concretar contigo, porque “guardar” significa cosas distintas en cada caso.
Trabajar cuando se corta la conexión
Imagina que se redactan decisiones durante desplazamientos. Conviene probar qué parte del trabajo debe continuar sin red:
- Abrir decisiones que ya se habían consultado.
- Crear una nueva entrada.
- Cerrar y volver a abrir.
- Recuperar los cambios al volver la conexión.
- Resolver qué ocurre si otra persona modificó el mismo dato.
Una aplicación web con capacidades PWA puede ser una opción. Ricardo puede preparar la prueba con los dispositivos relevantes y un recorrido realista. Si solo se necesita consultar información descargada, quizá el alcance sea mucho menor que editar y sincronizar.
La frase “funciona offline” debería transformarse en una lista concreta de tareas. Así podrás comparar alternativas y comprobar lo contratado.
Depender de una función del dispositivo
Supón que el encargo incorpora registrar audio durante una reunión con la pantalla bloqueada y conservarlo ante interrupciones. Ese requisito merece una prueba específica: duración prevista, bloqueo, llamada entrante, permisos y recuperación en los dispositivos elegidos.
Si se comprueba que la alternativa web no cubre el recorrido y una implementación nativa sí, existe una razón para elegir app móvil. El ejemplo plantea una comprobación profesional; no da por probado su resultado ni incorpora esa función al Cuaderno inicial.
El mismo criterio sirve para otras capacidades. Poder tomar una fotografía o instalar un icono no basta por sí solo para justificar desarrollo nativo. Identifica la limitación que importa y compruébala.
Separa superficie y modelo de prestación
SaaS describe cómo se ofrece y opera una aplicación como servicio. No decide por sí mismo si se abre en navegador, se instala como PWA o aparece en una tienda.
Una aplicación para una organización y un producto para varios equipos pueden compartir superficie web. El segundo exige pensar además en separación de datos, roles, administración, planes y operación.
Si quieres convertir un servicio en producto, el artículo sobre qué cambia antes de desarrollar un SaaS ayuda a separar esa decisión del formato de pantalla.
Qué conviene comentar al valorar una propuesta
| Pregunta | Qué conviene aclarar juntos |
|---|---|
| ¿Qué tarea debe llegar a resultado? | Una acción completa y su resultado, no el nombre de un panel |
| ¿Qué datos o estados continúan después? | Qué se guarda, dónde y cómo se recupera |
| ¿Cómo llega a la persona? | Enlace, instalación, tienda o dispositivo gestionado |
| ¿Qué debe funcionar sin red? | Tareas concretas y recuperación posterior |
| ¿Qué capacidad del dispositivo es imprescindible? | Requisito, dispositivos y prueba de compatibilidad |
| ¿Quién mantendrá cada plataforma? | Responsabilidad, publicación y cambios |
| ¿Existe una solución que ya cumpla lo esencial? | Recorrido probado, límites y condiciones de salida |
La herramienta para elegir solución recorre estas preguntas y devuelve razones, alternativas y dudas. La guía de idea a aplicación o SaaS conecta la elección con alcance, datos y operación. Ambas son ayudas para pensar el encargo, no requisitos para pedir una propuesta.
Conservar el motivo de la elección ayuda a revisarla si el contexto cambia. Si ya tienes requisitos o solo una necesidad por explorar, puedes comentar el proyecto con Ricardo sin decidir primero si será web, PWA o app móvil.