Una app web complementaria es la superficie de navegador de un producto que vive principalmente en una app móvil: el lugar donde un cliente se registra antes de instalar, donde un enlace compartido se abre para alguien que no tiene la app, donde el trabajo empezado en un teléfono continúa en un escritorio. Es el mismo producto, sobre la misma API, moldeado para aquello en lo que un navegador es bueno de verdad, en lugar de un port de la app o un folleto sobre ella.

La mayoría de las agencias construye un lado o el otro. Nosotros entregamos apps Flutter, frontends web y los servicios de backend que ambos consumen, y eso cambia la ingeniería, porque la pregunta «¿en qué superficie debería vivir esta funcionalidad?» la responde un solo equipo mirando un solo sistema, en vez de negociarse entre dos contratistas.

Los productos que construimos

  • Apps web de cliente junto a apps móviles: el producto completo en el navegador donde tiene sentido, o el subconjunto deliberado donde no
  • Superficies públicas y compartibles: las páginas a las que resuelve un enlace compartido, renderizadas e indexables, que derivan a la app cuando está instalada
  • Clientes web en tiempo real: datos en vivo en el navegador desde el mismo feed que consumen las apps
  • Back offices para el mismo producto: el lado orientado al operador es su propia disciplina, cubierta en paneles de administración y cuadros de mando
  • El lado web construido sobre Nuxt: cuando la superficie complementaria debe posicionar, la maquinaria es nuestra práctica de desarrollo con Nuxt

Quién construye tu app web complementaria

Dos productos en producción muestran el patrón, cada uno con una app y una superficie web que comparten un solo backend.

Formtastic: una plataforma, tres clientes

Formtastic funciona como una aplicación web en Nuxt más apps Flutter para iOS, iPad y Android, todas contra el mismo backend de Django y Go. La parte instructiva es cómo las funcionalidades aterrizan de forma distinta según la superficie: la entrada por voz en la web graba el audio en el navegador y lo envía a un endpoint de transcripción, porque ya había un backend que extender, mientras que las apps móviles llevan Whisper embebido en el dispositivo, porque en las obras no hay cobertura. La misma funcionalidad, dos implementaciones, cada una honesta con su superficie. Ese criterio, más que la destreza con un framework, es lo que un producto de dos superficies exige de verdad.

ExtraETF: un feed en tiempo real, todos los clientes

Para ExtraETF construimos el servicio en Go que difunde datos de mercado en vivo a los clientes web y móviles: miles de conexiones simultáneas, con las actualizaciones agrupadas a la cadencia que una persona mirando un precio necesita de verdad. Construimos las apps móviles y la capa de tiempo real; el cliente web que la consume pertenece al equipo del propio cliente, y ese es precisamente el argumento: un servicio bien diseñado alimenta superficies que tú nunca llegarás a construir.

Qué exige realmente un producto de dos superficies

Cuatro disciplinas evitan que una app y una superficie web deriven en dos productos.

Una API que sirve a ambos con honestidad

En el momento en que la web necesita «solo un endpoint especial», tienes dos backends con un mismo nombre. Diseñamos la API como el contrato único del producto —la misma autenticación, los mismos modelos, el mismo versionado para todos los clientes—, y donde las superficies necesitan genuinamente formas distintas de datos, esa diferencia queda escrita en el contrato en lugar de parcheada en un cliente.

Decidir qué es la versión web

El error caro es «la app, pero en un navegador». Una superficie complementaria se gana su presupuesto haciendo lo que la app no puede: ser alcanzable desde un resultado de búsqueda, abrirse al instante desde un enlace compartido, ofrecer teclado y pantalla grande para la edición pesada. Acotamos la superficie web funcionalidad a funcionalidad contra esa prueba, y recortar una funcionalidad de la versión web es una decisión que defenderemos en voz alta, no un hueco descubierto más tarde.

El traspaso entre web y app

Un enlace compartido debería abrir la app cuando está instalada, la página web cuando no, y nunca un interstitial roto. Los universal links de iOS y los app links de Android, las páginas de respaldo detrás de ellos y el flujo de registro que empieza en un navegador y continúa en la app: esta costura es donde los productos de dos superficies pierden usuarios de forma más visible, así que la resolvemos con ingeniería deliberada en vez de dar por hecho que funciona.

Un renderizado a la altura del trabajo de cada página

Las páginas públicas y compartibles se renderizan en el servidor para que los rastreadores y las vistas previas de enlaces vean contenido real; el espacio de trabajo con login que hay detrás se renderiza como la aplicación que es. Los compromisos están expuestos en el pilar de desarrollo web, y la elección es por ruta, no por proyecto.

Cómo trabajamos

Proyecto de alcance cerrado. Llevamos la superficie web desde la acotación de funcionalidades hasta el despliegue, contra tu API existente o una que construyamos junto a ella.

Ampliación de equipo. Nuestros ingenieros se suman al equipo dueño del producto: mira ampliación de equipo. Si el lado móvil también necesita construirse, esa es nuestra práctica de Flutter.

En cualquiera de los dos casos, enviamos un presupuesto detallado en un plazo de dos días laborables desde que entendemos los requisitos.

Cuánto cuesta una app web complementaria

Una superficie complementaria se presupuesta desde los mismos niveles publicados que la página de desarrollo web: una app web autenticada sobre tu API existente entra en el nivel de aplicación web, en 12.000-32.000 €, mientras que una segunda superficie completa con funciones en tiempo real, pagos o estructura multiinquilino se presupuesta como trabajo de nivel SaaS a partir de desde 40.000 €.

Son las mismas claves que renderizan la tabla de precios del pilar, así que las dos no pueden divergir. Lo que mueve la cifra: cuánta API existe ya y con qué limpieza se diseñó para más de un cliente, cuánto del producto cubre la versión web y si las funciones en tiempo real viajan sobre un feed existente o hay que construir uno.

Preguntas frecuentes

Dudas habituales de los equipos cuyo producto vive en una app y a los que no paran de pedirles una versión web.

No siempre, y la respuesta honesta depende de por dónde se fuga tu crecimiento. Una superficie web se gana su presupuesto cuando los registros empiezan en búsquedas o en enlaces compartidos, cuando los usuarios piden trabajar en una pantalla grande o cuando cada contenido compartido acaba hoy en un callejón sin salida para quien no tiene la app. Si no se da nada de eso, lo diremos; una ficha de tienda bien hecha y unos deep links pueden ser toda la presencia web que necesitas.
Normalmente no, y decidir qué dejar fuera es la mayor parte del trabajo de acotación. El navegador gana en alcance —búsqueda, enlaces compartidos, acceso instantáneo sin instalación— y en el trabajo de teclado y pantalla grande; la app gana en cámara, offline, notificaciones y estar a un toque de distancia. La entrada por voz de Formtastic es el patrón: la web graba en el navegador y transcribe en el servidor, las apps transcriben en el dispositivo porque en las obras no hay cobertura. La misma funcionalidad, implementaciones honestas distintas, y algunas funciones se quedan, con razón, solo en la app.
Construimos contra APIs existentes de forma rutinaria: el frontend web de Formtastic funciona sobre el backend Django que el producto ya tenía, extendido donde la web lo necesitaba. Lo primero que haremos es evaluar si la API es genuinamente multicliente: autenticación que un navegador pueda usar con seguridad, modelos que no asuman flujos exclusivos de app y un versionado que permita evolucionar a dos clientes. Donde se quede corta, te diremos con precisión qué cambiar, y podemos hacer ambos lados nosotros mismos cuando eso sea más rápido.
Sí: es una cuestión de diseño del feed, no de framework. Para ExtraETF construimos el servicio WebSocket en Go que difunde datos de mercado en vivo por igual a clientes web y móviles, sosteniendo miles de conexiones simultáneas y agrupando las actualizaciones a aproximadamente una por instrumento y segundo, el ritmo que una persona necesita de verdad. Diseña la capa de tiempo real una vez, y bien, y todos los clientes presentes y futuros consumen el mismo flujo.
Mediante universal links en iOS y app links en Android: la misma URL abre la app cuando está instalada y la página web cuando no, con la página web llevando el contenido completo en vez de limitarse a insistir en la instalación. Bien hecho, el enlace además sobrevive a la instalación: alguien que aterriza en la web, instala la app y la abre llega al contenido que se le prometió. Este traspaso es donde los productos de dos superficies pierden más usuarios, así que lo tratamos como una funcionalidad con su propio presupuesto de ingeniería.
Una app web autenticada sobre una API existente suele costar entre 15.000 y 40.000 dólares en un plazo de uno a tres meses, el nivel publicado de aplicación web de nuestra página de desarrollo web. Una segunda superficie completa con datos en tiempo real, pagos o estructura multiinquilino se presupuesta como trabajo de nivel SaaS a partir de 50.000. La palanca más grande es tu API: una diseñada para varios clientes mantiene esbelta la construcción web, mientras que una que asume flujos exclusivos de app añade trabajo de backend que acotaremos explícitamente.

Mira las dos superficies en el caso de estudio de Formtastic, lee cómo el feed en tiempo real de ExtraETF se reparte a todos los clientes o empieza por el pilar de desarrollo web.