La respuesta corta
Cuando la marca ya tiene una plataforma de comercio, la app no es una tienda nueva: es otra fachada de la tienda que ya existe.
Y de ahí sale la regla que evita la mayoría de los bugs caros: la lógica de negocio no se duplica. Precios, promociones, impuestos, disponibilidad y reglas de envío viven en la plataforma. La app pregunta y muestra. En cuanto la app calcula un precio por su cuenta, has creado dos fuentes de verdad y la pregunta ya no es si van a discrepar, sino cuándo.
Lo que decide el proyecto: dónde vive el carrito
Es la primera decisión de arquitectura y condiciona todo lo demás.
El carrito vive en la plataforma. La app lo consulta y lo modifica por API. El mismo carrito se ve en web y en app, y las promociones se aplican una sola vez y en un solo sitio. Es lo correcto en casi todos los casos.
El carrito vive en la app. Se puede montar sin conexión y se envía al final. Da autonomía y trae de vuelta el problema que queríamos evitar: hay que replicar las reglas para poder mostrar un total creíble antes de enviar.
La solución intermedia que funciona: carrito local como borrador, con la plataforma como única autoridad del total. La app puede mostrar una estimación —marcada como tal— y el importe bueno llega al validar.
El pago: nativo o del lado de la plataforma
Dos caminos, y los dos son legítimos:
- Checkout de la plataforma en una vista web, reutilizando su flujo, sus métodos de pago y su cumplimiento. Se lanza rápido y hereda todo el trabajo ya hecho.
- Checkout nativo contra las API de pago. Mejor experiencia, y significativamente más trabajo: cada método de pago local, cada caso de error y cada actualización de la plataforma pasa a ser tuya.
Un criterio razonable: empezar por la vista web y nativizar después, empezando por el paso que más abandono provoca. Y si se opta por la vista web, cuidar tres cosas que la delatan: que la sesión pase sin pedir volver a iniciar, que el estilo no rompa con el resto de la app, y que el retorno tras pagar sea limpio y no deje al usuario perdido en un navegador.
Y recordar la regla de la tienda: la compra de bienes físicos no pasa por la compra integrada de la plataforma móvil, sino por métodos de pago propios — está en app de marca en varios países.
Identidad: un solo cliente
El cliente es el mismo en web, en tienda y en la app, y eso hay que garantizarlo desde el principio:
- Un único identificador de cliente en la plataforma, no uno por canal.
- Sesión compartida entre la app y cualquier vista web que se abra dentro.
- Invitado que se registra: su carrito y su histórico tienen que sobrevivir a ese salto.
- Fidelización asociada al cliente, no al dispositivo.
Si esto se resuelve tarde, aparecen clientes duplicados. Y limpiar duplicados en un sistema de comercio con histórico de pedidos es de las migraciones más ingratas que existen.
Rendimiento: lo que la plataforma no te va a dar gratis
Las plataformas de comercio están pensadas para navegadores. Una app tiene otras expectativas:
- Respuestas pensadas para móvil. Una respuesta de catálogo con cuarenta campos por producto para pintar una rejilla es ancho de banda tirado y batería del usuario.
- Caché con criterio. El catálogo cambia poco; el stock y el precio, más. No se cachean igual.
- Imágenes servidas al tamaño real del dispositivo, no la original de la ficha web.
- Una capa intermedia propia cuando la plataforma no ofrece lo que necesitas. Es el patrón habitual: un servicio tuyo que agrega, adapta y protege a la app de los cambios del proveedor.
Esa capa intermedia tiene además una ventaja de gobierno: cuando la plataforma cambia —y cambia—, actualizas un servicio en vez de publicar una versión en las tiendas.
Lo que se subestima
- Los entornos. Conseguir un entorno de pruebas de la plataforma con datos representativos suele depender de un tercero.
- Las promociones. Son la parte más viva y la que más discrepancias genera entre canales.
- Los estados del pedido. El cliente pregunta por su pedido en la app y espera lo mismo que ve en la web. Cualquier estado que exista en un canal y no en el otro es un ticket.
- Las devoluciones, que casi nunca entran en el alcance inicial y siempre acaban pidiéndose.
Antes de estimar
- ¿Qué plataforma, qué versión y qué APIs expone?
- ¿El carrito y el checkout son de la plataforma o los construimos?
- ¿Hay ya una capa intermedia, o la creamos?
- ¿Cómo se unifica la identidad del cliente entre canales?
- ¿Quién gestiona las promociones y con qué herramienta?
La segunda decide la mitad del presupuesto. La quinta decide cuántas incidencias tendrás el primer trimestre.
Es el trabajo que hacemos en apps de retail para empresa: construir el canal móvil encima del comercio que ya funciona, sin duplicarlo y sin quedar atado a él.
