Cómo crear una aplicación para tu empresa: web, móvil o PWA
Para crear una aplicación para tu empresa, define primero qué problema resuelve, quién la usa y desde dónde. Con eso eliges canal: aplicación web si se usa en ordenador, PWA instalable si hace falta el móvil y avisos, y app nativa solo si necesitas funciones del dispositivo o estar en las tiendas.
Crear una aplicación para tu empresa empieza por tres respuestas, no por la tecnología: qué trabajo tiene que resolver, quién la va a usar y desde dónde. Con eso se elige el canal (una aplicación web, una PWA que se instala en el móvil o una app nativa de las tiendas) y el resto del proyecto se ordena mejor.
Cuando alguien dice «quiero una app para mi empresa», casi siempre quiere decir «quiero que mi equipo o mis clientes hagan algo desde el móvil». Eso no obliga a publicar en las tiendas de Apple y Google. A veces compensa y muchas veces no. Esta guía te ayuda a distinguirlo y a preparar el proyecto.
Antes de la tecnología: tres preguntas
Antes de hablar de iPhone o Android, escribe las respuestas a estas tres preguntas. Son las que más cambian el proyecto.
- Qué trabajo resuelve. No «tener una app», sino algo concreto: que los técnicos cierren el parte en la calle, que los clientes reserven sin llamar o que el almacén confirme pedidos desde el móvil. Si no cabe en una frase, todavía no está claro.
- Quién la usa. Tu equipo, tus clientes, tus proveedores o varios a la vez. Cada perfil ve cosas distintas y hace cosas distintas: son roles, y cada rol añade pantallas y permisos.
- Desde dónde. En la oficina con un ordenador, en la calle con el móvil, en una nave sin cobertura o en un mostrador con un equipo antiguo. El lugar decide si tiene que funcionar sin conexión, si necesita la cámara o si debe ir en dispositivos que no vas a renovar.
Ese último punto se subestima. En uno de los sistemas que hemos construido, un TPV tiene que seguir funcionando en ordenadores con Windows 7 y Chrome 109, y eso condiciona qué tecnología se puede usar en la interfaz. Conviene saberlo el primer día, no el día del lanzamiento.
Web, PWA o app nativa: qué es cada una
Hay tres formas de poner una aplicación delante de la gente, y no son excluyentes:
- Aplicación web. Se abre en el navegador, desde el ordenador o el móvil. Hay una sola versión y cada mejora llega a todos al momento.
- PWA (aplicación web progresiva). MDN la define como una aplicación construida con tecnologías web que ofrece una experiencia como la de una app específica de cada plataforma: se puede instalar en el dispositivo, funcionar sin conexión y en segundo plano, y parte de un único código para todos los dispositivos. En iPhone y iPad, las notificaciones de las aplicaciones web llegaron con iOS y iPadOS 16.4 (WebKit lo anunció en febrero de 2023), siempre que la aplicación esté añadida a la pantalla de inicio y el permiso se pida después de que la persona pulse algo.
- App nativa. Se programa para cada sistema (iOS y Android), se publica en sus tiendas y accede a las funciones del dispositivo que permite cada sistema. Exige cuentas de desarrollador, pasar la revisión de cada tienda y mantener dos versiones o un código multiplataforma.
| Criterio | Aplicación web | PWA instalable | App nativa |
|---|---|---|---|
| Instalación | No hace falta | Desde el navegador, sin tienda | Desde App Store o Google Play |
| Sin conexión | No | Sí, si se diseña para ello | Sí |
| Notificaciones | Según navegador; en iPhone, solo si se instala (como PWA) | Sí; en iPhone, instalada | Sí |
| Funciones del dispositivo | Las que da el navegador | Las que da el navegador | Las que permite el sistema |
| Actualizaciones | Inmediatas | Inmediatas | Pasan por la revisión de la tienda |
| Código que mantener | Uno | Uno | Dos, o uno multiplataforma |
Cómo decidir qué canal necesitas
Con las tres respuestas del principio, la decisión suele salir sola:
- Se usa sobre todo en ordenador (administración, oficina, gestión): aplicación web. Si alguien la abre de vez en cuando en el móvil, basta con que se adapte a la pantalla.
- Se usa en el móvil, por tu equipo o por tus clientes, y necesita avisos o funcionar con mala cobertura: PWA instalable. Es el caso típico de los partes de trabajo, las reservas, los pedidos o los portales de cliente.
- Necesitas algo que el navegador no da bien (procesos continuos en segundo plano, integración profunda con el sistema o con periféricos concretos) o que te encuentren en la tienda forma parte del negocio: app nativa.
Dos matices. Si la app es solo para tus empleados, estar en la tienda no aporta nada: basta una PWA con acceso por usuario, y si de verdad necesitas una nativa, Apple permite distribuir apps personalizadas solo a las organizaciones que indiques y Google Play gestionado admite aplicaciones privadas. Y meter tu web en un envoltorio para publicarla no suele ser un atajo: las normas de revisión de Apple piden que una app aporte funciones, contenido e interfaz que vayan más allá de una web reempaquetada (apartado 4.2, de funcionalidad mínima), y añaden que si una app no es especialmente útil, única o «parecida a una app», no tiene sitio en el App Store. El envoltorio puede acabar en un rechazo y en pagar el trabajo dos veces.
Los pasos para crear la aplicación
El orden importa más que la herramienta. Así se construye una aplicación de empresa sin sorpresas:
- Casos de uso reales. De tres a cinco historias del tipo «el técnico llega, abre el aviso, hace fotos, el cliente firma y el parte queda cerrado». Son la base del alcance.
- Prototipo navegable. Las pantallas, clicables, antes de programar. Se prueban con quien las va a usar: corregir un dibujo cuesta mucho menos que corregir código.
- Qué se conecta. Facturación, CRM, pagos, correo o tu programa actual. Cada conexión se decide aquí, no a mitad del desarrollo.
- Una primera versión acotada. El recorrido principal completo, sin extras. Lo contamos en qué incluir en un MVP.
- Entregas por fases. Algo funcionando cada poco tiempo, con pruebas automáticas en cada entrega.
- Lanzamiento acompañado. Instalación en los dispositivos, formación y soporte los primeros días.
- Evolución. Lo que pida el uso real, no lo que se imaginó al principio.
Qué recibes en cada paso lo detallamos en las fases de un proyecto de software.
Decisiones que no se ven y conviene tomar pronto
Hay decisiones que no aparecen en las pantallas y que salen caras si se toman tarde:
- Roles y permisos. Quién ve precios, quién aprueba y qué ve un cliente de otro cliente (nada). Mejor pocos roles bien definidos que muchos improvisados.
- Sin conexión. Si la app se usa en sótanos, obras o carreteras, hay que decidir qué se guarda en el móvil, cómo se sincroniza y qué pasa si dos personas cambian lo mismo.
- Notificaciones. Qué avisos, a quién y cuándo. Una app que avisa de todo acaba silenciada.
- Datos. Dónde viven, con qué copias de seguridad, cómo se restauran y cómo se exportan si un día cambias de proveedor.
- Varias empresas en la misma aplicación. Si va a dar servicio a varios clientes, sus datos tienen que estar aislados desde el diseño. Lo explicamos en SaaS multi tenant.
- Datos personales. Si guarda datos de clientes o empleados (ubicación, firmas, fotos), la protección de datos entra en el diseño, no al final.
Coste y plazo: de qué dependen
El coste y el plazo dependen de lo mismo: número de pantallas y roles, canal elegido (una PWA mantiene un solo código; dos apps nativas, dos), integraciones, funcionamiento sin conexión y el panel de gestión que hay detrás, que pesa más de lo que parece. Si publicas en las tiendas, suma las cuotas de desarrollador de Apple y Google y el tiempo de revisión de cada versión. Lo desglosamos en cuánto cuesta hacer una app y en cuánto se tarda en desarrollar un software.
Y si la aplicación tiene que proponer textos, leer documentos o responder preguntas con IA, eso es una pieza más con su propio coste por uso: lo tratamos en cómo integrar IA en una aplicación.
Lo que hemos aprendido construyendo aplicaciones
Hemos construido aplicaciones web instalables con notificaciones para equipos y para clientes finales: el portal del conductor en el ERP de una empresa de transporte, el acceso móvil del atleta en Entrenify o las reservas de XBarber. Tres lecciones que aplicamos en cualquier proyecto:
- Un solo sistema para todos los roles. Quien trabaja en la calle y quien está en la oficina ven cosas distintas, pero trabajan sobre los mismos datos. Nadie copia nada de una aplicación a otra.
- Publicar sin interrumpir. Una versión nueva no sustituye a la que está en marcha hasta comprobar que arranca de verdad; cómo lo hacemos lo contamos en software legacy.
- Empezar por el proceso que más duele. Una primera versión que resuelve de verdad una tarea vale más que diez pantallas a medias.
Puedes ver cómo trabajamos en desarrollo de software, SaaS y apps y los sistemas en uso en proyectos desarrollados. Si todavía estás comparando proveedores, te servirá cómo elegir empresa de desarrollo de software.
Si tu equipo trabaja fuera de la oficina, como los técnicos que van de aviso en aviso, mira también qué necesita el software de una empresa de servicio técnico.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- Progressive web apps. MDN Web Docs (Mozilla).
- Web Push for Web Apps on iOS and iPadOS. WebKit (motor de Safari, Apple).
- App Review Guidelines (apartado 4.2, Minimum Functionality). Apple Developer.
- Custom apps: distribución a organizaciones concretas. Apple Developer.
- Publicar aplicaciones privadas desde Play Console. Ayuda de Google Play for business.
- Reglamento (UE) 2016/679, Reglamento General de Protección de Datos (art. 25). BOE (DOUE).
Preguntas frecuentes
¿Es mejor una app nativa o una PWA para una empresa?
Depende de quién la use y para qué. Para equipos internos, portales de cliente, reservas o partes de trabajo, una PWA suele bastar: se instala, envía avisos y mantiene un solo código. La nativa compensa si necesitas funciones del dispositivo que el navegador no ofrece bien o si estar en la tienda forma parte de tu negocio.
¿Puedo crear una aplicación para mi empresa sin programar?
Para validar una idea o un proceso sencillo, las herramientas sin código pueden servir. Sus límites aparecen con los permisos por rol, las integraciones con tus programas y la propiedad y exportación de los datos. Si la aplicación va a sostener un proceso central de la empresa, conviene valorar esos límites antes de invertir en ella.
¿Una PWA funciona en iPhone?
Sí. Se abre en el navegador y se puede añadir a la pantalla de inicio. Desde iOS y iPadOS 16.4 también puede enviar notificaciones, siempre que esté añadida a la pantalla de inicio y la persona haya dado permiso después de pulsar algo en la aplicación.
¿Se puede tener una app solo para los empleados, sin publicarla en las tiendas?
Sí. Lo más sencillo es una PWA con acceso por usuario. Si hace falta una app nativa, Apple permite distribuir apps personalizadas solo a las organizaciones que indiques y Google Play gestionado admite aplicaciones privadas para una organización.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.