Web app vs mobile app: la decisión antes del build

Una fundadora con la que trabajamos el año pasado llegó al kickoff segura de una cosa: necesitaba una app de iOS. Su producto era una herramienta de agenda y cobranza para fisioterapeutas independientes, el tipo de trabajo que ocurre en un escritorio entre un paciente y otro, en una laptop, con un segundo monitor mostrando la agenda del día. Quería estar en la App Store de todos modos, porque eso era lo que un producto de verdad parecía para ella. Le construimos un web app en cambio. Dieciocho meses después tiene clínicas que pagan en tres estados y ni una sola vez ha echado de menos la app nativa que pidió el primer día.

Esa es toda la pregunta web app vs mobile app en una historia. Un web app corre en el navegador y funciona en cualquier dispositivo que abra una URL. Un mobile app se instala desde una app store y corre de forma nativa en el teléfono. Elegir entre los dos no es una elección sobre qué tecnología es más moderna. Es una pregunta sobre dónde tus clientes hacen el trabajo de verdad, y qué necesita ese trabajo del dispositivo que tienen en la mano. Responde eso con honestidad y la plataforma cae sola de la respuesta.

A la mayoría de los fundadores en etapa temprana los empujan al otro lado. El instinto de app store dice “una empresa seria tiene app”, así que pagan por construir y mantener dos plataformas para alcanzar a clientes a quienes un solo buen web app habría servido igual de bien. Esta es una guía para tomar esa decisión desde la silla del fundador, no la del desarrollador, con un framework que corres en una tarde.

Tres cosas que los fundadores siguen confundiendo

Antes de que la decisión tenga sentido, tres palabras tienen que separarse, porque los fundadores las usan como sinónimos y luego compran lo equivocado.

Un sitio web es contenido que lees. Un sitio institucional, un blog, una landing page. Nadie inicia sesión para trabajar.

Un web app es software que corre en el navegador y al que la gente inicia sesión para usar. Gmail es un web app. Figma es un web app. El dashboard de tu banco es un web app. Vive en una URL, se actualiza en el instante en que despliegas, y funciona en laptop, tablet y navegador del teléfono sin que construyas tres versiones. Un progressive web app, o PWA, es un web app que puede guardarse en la pantalla de inicio del teléfono, funcionar en parte sin conexión y enviar push notifications. Se ve y se siente cerca de una app instalada sin pasar por una tienda.

Un mobile app es eso que descargas de la App Store o de Google Play. Corre de forma nativa en el teléfono, puede usar la cámara, GPS, Bluetooth y el sistema de notificaciones completo, y funciona sin conexión por defecto. Construir uno normalmente significa construirlo dos veces, una para iOS y una para Android, o usar un framework cross-platform para compartir código. Esa segunda decisión, nativo versus cross-platform, solo importa una vez que decidiste que necesitas un mobile app del todo.

Mantén esas tres cosas separadas y casi toda la confusión del debate “web app vs mobile app” desaparece. Muchos fundadores creen que necesitan un mobile app cuando lo que necesitan es un web app que da la casualidad de que funciona bien en el teléfono.

La pregunta real no es web vs mobile

Aquí está la jugada que más dinero le ahorra al fundador: deja de comparar las plataformas y empieza a describir el trabajo.

Las plataformas son solo mecanismos de entrega. Lo que importa es el trabajo que tu cliente está haciendo cuando recurre a tu producto, y dónde está cuando lo hace. Un técnico de campo fotografiando un medidor dañado en una azotea sin señal está haciendo un trabajo distinto al de un gerente de operaciones conciliando facturas un martes por la tarde. El primero necesita la cámara, el GPS y almacenamiento sin conexión, así que quiere ser nativo. El segundo necesita un teclado de verdad y una pantalla grande, así que quiere ser un web app. Ninguno de los dos fundadores debería empezar por “iOS o navegador”. Deberían empezar por la azotea y por el martes por la tarde.

Por eso la SERP llena de listas de “20 pros y contras” te resulta inútil. Los pros y contras en abstracto son ruido. La misma función que es un pro para una app de fitness de consumo, push notifications que te empujan a cerrar los anillos, es irrelevante para una herramienta B2B que la gente abre cuando un correo se lo indica. No necesitas una matriz de funciones. Necesitas conocer el día de tu cliente.

Las cuatro preguntas que de verdad lo deciden

Pasa tu producto por estas cuatro. Las respuestas apuntan a web app, PWA o nativo de forma mucho más confiable que cualquier tabla de comparación genérica.

1. ¿Dónde ocurre el trabajo físicamente? ¿En un escritorio, en una laptop, con otras pestañas abiertas? Eso es territorio de web app, punto. ¿En movimiento, en campo, en el pasillo de una tienda, en el auto, lejos de un teclado? Eso tira hacia mobile. Sé honesto sobre dónde ocurre el trabajo de verdad, no sobre dónde te imaginas a los usuarios soñando con tu marca.

2. ¿Qué necesita el trabajo del dispositivo? Lista las funciones de hardware y de sistema operativo que la tarea central exige de verdad. Cámara para capturar un documento o un código de barras. GPS para ubicación. Bluetooth para un dispositivo. Uso sin conexión confiable sin señal. Push notifications ricas que tienen que llegar incluso con la app cerrada. Si tu tarea central necesita dos o más de estas a fondo, un app nativo justifica su costo. Si no necesita ninguna, estás pagando por un app nativo para entregar una experiencia de web.

3. ¿Con qué frecuencia vuelven los clientes, y por qué puerta? Una herramienta que la gente usa a diario, que quieren a un toque en la pantalla de inicio, se beneficia de estar instalada. Una herramienta que se usa por semana o por mes, a la que se llega haciendo clic en un enlace de un correo o de un mensaje de Slack, es mejor como web app. El descubrimiento importa aquí. Si tus clientes te encuentran y vuelven por correo, búsqueda y enlaces compartidos, una URL es tu puerta de entrada. Una ficha en la app store no lo es.

4. ¿Cuánto puedes pagar para construir y mantener a lo largo de 18 meses, no solo para lanzar? Esta es la pregunta que los fundadores se saltan y luego lamentan. Un app nativo rara vez es una sola construcción. Es iOS más Android, dos procesos de revisión de tienda, actualizaciones de sistema operativo que rompen cosas dos veces al año, y un ciclo de release en el que arreglar un bug significa esperar a los revisores de Apple en vez de desplegar en una hora. Construir para dos plataformas nativas normalmente cuesta bastante más que un solo build web, y la brecha de mantenimiento se acumula cada trimestre después del lanzamiento. Si tu runway está ajustado, cada plataforma que agregas es un impuesto que pagas para siempre.

Si tres de las cuatro respuestas apuntan al navegador, construye el web app y deja de convencerte de hacer más. Si tres apuntan al teléfono, el costo nativo está justificado. Cuando se dividen, las dos secciones siguientes son para ti.

Cuándo un web app o un PWA es la decisión correcta

Para la mayoría de los productos B2B, herramientas internas, dashboards, marketplaces y cualquier cosa que la gente usa en un escritorio, un web app no es el punto medio. Es la respuesta correcta.

Despliegas en el momento en que haces deploy, sin ninguna revisión de tienda sentada entre tú y tus clientes. Un solo código sirve a laptop, tablet y navegador del teléfono. El onboarding es un enlace, que es la distribución de menor fricción que existe. Y cuando un cliente choca con un bug un viernes, lo arreglas el viernes, no el martes siguiente cuando despierte un revisor.

Si tu producto quiere un pie en el teléfono sin el costo nativo completo, un PWA es el medio subestimado. Los clientes pueden agregarlo a la pantalla de inicio, puede funcionar sin conexión para datos en caché, y puede enviar push notifications en Android y, cada vez más, en iOS. No igualará a un app nativo en gráficos pesados, acceso profundo al hardware o en el pulido de los gestos nativos de la plataforma. Para una gran parte de los productos de fundador, no hace falta. El trade-off honesto es que los PWA pierden frente al nativo en capacidad bruta y ganan en costo y velocidad de iteración. Para una herramienta a la que la gente inicia sesión para trabajar, ese intercambio suele favorecer a la web. La guía del propio Google sobre progressive web apps es un buen punto de partida sobre lo que pueden y no pueden hacer hoy.

Cuándo necesitas de verdad un app nativo

A veces el teléfono no es algo deseable. Es el producto.

Construye nativo cuando la tarea central vive en el teléfono y se apoya con fuerza en el dispositivo: una app de navegación, un producto cámara-first, una herramienta de reparto o logística usada en campo, cualquier cosa que necesite operación sin conexión confiable, ubicación en tiempo real, hardware Bluetooth o una confiabilidad de notificación que no puedes comprometer. Construye nativo cuando el uso diario y habitual es todo el modelo de retención y el ícono en la pantalla de inicio está haciendo trabajo real para traer a la gente de vuelta. Construye nativo cuando el rendimiento es la experiencia, donde medio segundo de tirón se lee como roto.

Si ese eres tú, el costo nativo no es desperdicio. Es el precio de que el producto funcione del todo. El punto del framework no es convencerte de descartar el nativo. Es asegurar que pagas por nativo porque el trabajo lo exige, no porque la App Store se sintió como un hito que tachar.

“¿Cuál construir primero?”

Esta es la pregunta que la mitad de la SERP promete responder y luego esquiva. Aquí está la versión honesta.

Para la mayoría de los fundadores, construye el web app primero, aunque estés seguro de que un app nativo está en tu futuro. El web app es más barato, despliega más rápido, corre en todo dispositivo que tus primeros clientes tienen, y te enseña lo que el producto debería ser antes de que te comprometas con la plataforma más cara. Aprendes qué funciones importan, en qué pantallas vive la gente, y qué partes de tu plan del día uno estaban equivocadas. Luego, si las cuatro preguntas siguen apuntando a nativo, lo construyes sabiendo exactamente qué construir, encima de un backend que el web app ya probó.

La excepción es el pequeño conjunto de productos en los que el teléfono es toda la experiencia desde el primer día, donde un web app no sería una versión más pequeña del producto sino una versión distinta y peor. Una app de consumo cuyo pitch entero es cámara-más-ubicación no tiene una versión web útil. Para todos los demás, web primero no es conformarse. Es secuenciar, y es la misma disciplina detrás de un producto mínimo viable de verdad: construye la cosa más pequeña que hace bien el trabajo, aprende, luego expande la superficie a propósito. La decisión web app vs mobile app es una instancia del juicio más amplio de build versus buy versus secuenciar que todo fundador hace una docena de veces.

La app store es distribución, y la distribución tiene precio

Una cosa más que el instinto “una empresa seria tiene app” no ve. La App Store y Google Play no son solo un lugar para poner tu app. Son un canal de distribución, y los canales cobran renta.

Esa renta llega en tres formas. Está la comisión, históricamente del 15 al 30 por ciento de todo lo que vendes dentro de la app, aunque el programa para pequeñas empresas de Apple la baja al 15 por ciento por debajo de un millón de dólares al año. Está la latencia de revisión: cada release, incluido el arreglo urgente, espera en una fila que no controlas. Y está el descubrimiento, que los fundadores son los que más sobreestiman. Nadie está navegando la tienda y tropezando con tu herramienta B2B de agenda. La vas a comercializar por los mismos canales por los que comercializarías un web app, y luego pedir a la gente que vaya a instalarla, sumando un paso. La tienda es un peaje que eliges cruzar cuando la experiencia nativa vale el peaje. No es alcance gratis, y no es un trofeo.

Nada de esto significa evitar la App Store. Significa contarla como un costo, igual que cuentas cualquier otro, en vez de tratar “estamos en la App Store” como un objetivo que se paga solo. Rara vez lo hace por su cuenta.

La fundadora de la herramienta de fisioterapia lo entendió en cuanto se lo expusimos. Sus clientes estaban en escritorios, el trabajo necesitaba teclado y pantalla y nada del hardware del teléfono, volvían por recordatorios de correo, y su runway no podía cargar dos builds nativos. Cada una de las cuatro preguntas apuntaba en la misma dirección. El app nativo nunca fue el producto que necesitaba. Era la imagen en su cabeza de lo que un producto se supone que es. El trabajo, una vez descrito sin rodeos, ya había elegido el navegador.

FAQ

¿Qué es mejor, un mobile app o un sitio web?
Ninguno es mejor en abstracto. Un sitio web es para contenido que la gente lee; un web app es software al que la gente inicia sesión; un mobile app se instala desde una tienda y usa el hardware del teléfono. El correcto depende de dónde ocurre el trabajo y qué necesita del dispositivo. Para la mayoría de los productos de escritorio y B2B, un web app gana en costo, velocidad y alcance. Para productos de campo, de cámara o de hábito diario, el nativo se paga.

¿Un web app puede ser un mobile app?
En la práctica, sí, y eso es lo que es un progressive web app. Un PWA corre en el navegador pero puede guardarse en la pantalla de inicio, funcionar sin conexión para datos en caché y enviar push notifications, así que se comporta muy parecido a una app instalada sin pasar por una app store. No igualará a un app nativo en uso pesado de hardware o gráficos, pero para muchos productos cierra la mayor parte de la brecha por una fracción del costo.

¿Por qué los PWA no son populares?
Los PWA se usan ampliamente, solo que en silencio. Varios productos que usas son PWA sin anunciarlo. La percepción de que no son populares viene de dos cosas: iOS los soportó más tarde y de forma más parcial que Android, y no hay ficha de tienda que los haga visibles, así que la adopción es invisible por diseño. Para los fundadores esa invisibilidad es una ventaja, ya que la distribución ocurre por tus propios enlaces en vez de una tienda saturada.

¿Facebook es un web app o un mobile app?
Ambos, y ese es el punto. Las empresas grandes corren un web app y apps nativas de iOS y Android en paralelo porque tienen el presupuesto y la base de usuarios para justificar cada plataforma. Ese es el modelo equivocado para copiar en la etapa temprana. Las apps grandes están en todas partes porque pueden permitírselo, no porque todo producto necesite empezar así. Elige la única plataforma que el trabajo de tus clientes de verdad exige, pruébala, y luego agrega superficies cuando los números, no el instinto, lo digan.