El desarrollo de apps de e-commerce es la ingeniería de escaparates móviles: catálogos de producto, carritos, checkouts, seguimiento de pedidos y las mecánicas de fidelización que hacen volver al cliente. Se diferencia del desarrollo de apps corriente en tres cosas concretas: el catálogo es más grande que el dispositivo (así que la búsqueda, la caché y la entrega de imágenes deciden cómo se siente la app), el checkout es donde cada defecto se convierte en ingresos abandonados, y el mismo escaparate a menudo tiene que existir varias veces: por marca, por mercado, por divisa.

Flutter encaja en el retail inusualmente bien porque renderiza su propia interfaz: una cuadrícula de productos, una promoción en formato historias o un flujo de checkout a medida se comportan de forma idéntica en iOS y Android desde una sola base de código, por en torno a un 30-40 % menos que construir el mismo escaparate de forma nativa dos veces. Las partes que tocan la plataforma directamente —las hojas de pago de Apple Pay y Google Pay, algunos SDK de proveedores de pago— pasan por , que es trabajo rutinario pero trabajo real de ingeniería.

Los productos que construimos

  • Apps de tienda: catálogo, búsqueda, carrito, checkout, seguimiento de pedidos y reseñas para una sola marca
  • Apps de fidelización y cashback: puntos, recompensas y ofertas, como en la plataforma de cashback y fidelización que construimos y operamos como flota
  • Flotas de retail de marca blanca: una base de código que produce una app de marca por comercio o mercado; el trabajo de plataforma tiene su propia página de servicio
  • Apps del lado del comerciante: la app complementaria que usa un vendedor o el gerente de una tienda, que construimos para la misma plataforma
  • Escaparates de marketplace: donde el catálogo pertenece a muchos vendedores; la dinámica de dos lados se cubre en nuestra página de marketplace

Quién construye tu app de e-commerce

Seremos francos sobre lo que contiene nuestro portafolio: ningún escaparate de una sola marca que podamos nombrar. Lo que contiene, en cambio, son las partes difíciles del comercio, entregadas repetidamente y todavía en producción.

Una flota de quince apps de consumo de marca

Para una plataforma de cashback y fidelización bajo NDA, una sola base de código Flutter produce más de quince apps totalmente personalizadas —cada una con su propio nombre, tema y ficha de tienda—, además de la app del comerciante al otro lado de cada transacción y un panel de administración que lanza una nueva marca sin trabajo de ingeniería. Ocho meses de construcción, y la arquitectura está documentada. Si tu estrategia de retail implica más de un escaparate, esta es exactamente la forma del problema.

Pagos, operados desde dentro

Nerdy Production está liderada por Ilya Nixan, antes CTO de QIWI, una de las mayores plataformas de pago de su mercado, donde sus equipos dirigieron el procesamiento de tarjetas y cargaron con alcance PCI-DSS. La relevancia para una tienda es directa: el checkout es una integración de pagos vestida de escaparate, y la persona que lidera tu proyecto ha operado el otro lado de esa integración. Las disciplinas que vienen con ello —el dinero como enteros en unidades menores, el estado de los derechos en manos del servidor, los datos de tarjeta fuera del alcance de tu app— son las mismas que nuestra página de fintech describe al completo.

Mecánica de catálogo, a escala de marketplace

OneTwoDo no es una tienda, pero sí es un catálogo navegable de anuncios con fotos, búsqueda, precios multidivisa y un feed filtrado por idioma y ubicación — diseñado y entregado en siete semanas. La mecánica de «mostrar de forma atractiva una gran colección de cosas en un teléfono de gama media» se transfiere entera.

Qué exige realmente una app de e-commerce

Cinco preocupaciones aparecen en todo proyecto de retail. Así abordamos cada una.

Un catálogo más grande que el dispositivo

El catálogo vive en el servidor; la app sostiene una ventana deslizante sobre él. Esa frase esconde la mayor parte de la ingeniería: consultas paginadas que mantienen estable la posición de scroll, una búsqueda que tolera erratas y responde en milisegundos, imágenes dimensionadas y cacheadas para que una cuadrícula de productos no se coma la tarifa de datos, y una página de producto que se renderiza al instante desde los datos cacheados de la lista mientras los detalles cargan por detrás. Si esto se hace mal, la app se siente lenta en todas partes aunque cada petición individual parezca correcta.

Un checkout que trata el fallo como el camino principal

Los pagos fallan: las tarjetas se rechazan, los desafíos de 3-D Secure caducan, la app pasa a segundo plano a mitad de pago, la red se cae entre que el proveedor confirma y tu backend se entera. Un checkout se diseña alrededor de esos casos, no alrededor del camino feliz: creación de pedidos idempotente para que un reintento no pueda cobrar dos veces, estado del pago en manos del servidor y meramente mostrado por el cliente, y una respuesta definitiva en pantalla para cada desenlace. «Pagos que tienen éxito en el proveedor pero no llegan a confirmarse en tu backend» es la clase de bug que cuesta dinero real, y se elimina en la fase de arquitectura.

Hojas de pago nativas, hechas de forma nativa

Apple Pay y Google Pay convierten notablemente mejor que los formularios de tarjeta tecleados en móvil, y ambos se alcanzan desde Flutter mediante platform channels respaldados por el SDK propio de cada plataforma. Los integramos junto al flujo de tarjeta del proveedor, no en su lugar, y mantenemos los datos de tarjeta en bruto dentro del SDK del proveedor para que tu alcance PCI sea tan pequeño como tu producto permita.

Los precios son dinero, y el dinero no es un float

Cada precio, descuento, línea de impuestos y total es un entero en unidades menores o un tipo decimal — nunca coma flotante, donde 0.1 + 0.2 no es igual a 0.3 y el total de un carrito puede discrepar de la suma de sus líneas. Las reglas de redondeo son explícitas y están probadas en cada frontera donde el dinero se muestra, se transmite o se almacena. La versión larga está en Por qué 0,1 + 0,2 ≠ 0,3.

Las reglas de tienda que los equipos de retail descubren tarde

Ambas tiendas se llevan una comisión de los bienes digitales pero no de los físicos: vender productos físicos a través de tu propio proveedor de pagos está permitido, y mezclar ventajas digitales en una app de retail es donde empiezan los problemas de revisión. La directriz 4.2.6 de Apple es la otra trampa: una flota de apps de marca ligeras y casi idénticas es exactamente lo que esa directriz existe para rechazar, y diseñar una plataforma de marca blanca para superarla es una especialidad nuestra y no una sorpresa en la semana veinte. La eliminación de cuentas, las declaraciones de seguridad de datos y los plazos de revisión se presupuestan como una fase, igual que en todas las páginas de este sitio.

Por qué Flutter para e-commerce

RequisitoCómo lo resuelve Flutter
Ambas tiendas, un presupuestoUna base de código, en torno a un 30-40 % menos que dos escaparates nativos
Una interfaz perfecta para la marcaFlutter dibuja cada píxel, así que el sistema de diseño es tuyo y no de la plataforma
Cuadrículas de producto rápidas en teléfonos baratosEl renderizado compilado a nativo sostiene los 60 fps donde de verdad están los compradores: el Android de gama media
Velocidad de iteración estacionalHot reload en menos de un segundo; una pantalla de promoción sale en días, no en ciclos de release
Más de un escaparateLa misma base de código escala de una marca a una flota — mira la plataforma de marca blanca

Dónde sigue ganando lo nativo: si tu escaparate es en esencia un envoltorio alrededor de la capacidad de una plataforma —una experiencia guiada por App Clips, una integración profunda con Wallet como producto en sí—, el ahorro multiplataforma no es lo importante, y te lo diremos. La página general del servicio es desarrollo de apps con Flutter.

Cómo trabajamos

Proyecto de alcance cerrado. Somos dueños de la entrega de principio a fin: descubrimiento, arquitectura, construcción y envío a tiendas. Nuestro proceso de desarrollo describe cómo es semana a semana.

Ampliación de equipo. Nuestros ingenieros se suman a tu equipo existente, en tu repositorio y tus sprints: mira ampliación de equipo.

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 de e-commerce

Un escaparate —catálogo y búsqueda, carrito y checkout, integración de pasarela de pago, seguimiento de pedidos, reseñas— es su propio nivel en la página de desarrollo de apps con Flutter: 40-72 mil €, en un plazo de cuatro a seis meses. Una plataforma multivendedor, una flota de marca o una integración profunda con ERP e inventario es trabajo de nivel enterprise, a partir de desde 72 mil €.

Son los mismos niveles publicados que en la tabla de precios del pilar: las mismas claves renderizan ambas páginas, así que no pueden divergir. Lo que mueve una cifra de retail dentro de ellos: el número de métodos de pago y mercados, cuánta maquinaria de catálogo aporta ya tu backend y si «una app» es en realidad una flota.

Preguntas frecuentes

Dudas habituales de los equipos que construyen productos de retail y e-commerce sobre Flutter.

Sí. Flutter renderiza su propia interfaz, así que una cuadrícula de productos, una pantalla de promoción o un checkout a medida se ven y se comportan de forma idéntica en iOS y Android desde una sola base de código, normalmente por un 30 a 40 por ciento menos que construir dos escaparates nativos. Compila a código nativo, lo que mantiene el scroll fluido en los dispositivos Android de gama media donde de verdad ocurre buena parte del tráfico de retail. Las partes específicas de plataforma —las hojas de pago de Apple Pay y Google Pay, algunos SDK de proveedores de pago— se alcanzan mediante platform channels, que es trabajo de ingeniería rutinario pero real.
Nuestro nivel publicado de e-commerce cubre catálogo y búsqueda, carrito y checkout, integración de pasarela de pago, seguimiento de pedidos, reseñas y gestión de inventario en un plazo de cuatro a seis meses; el rango exacto está en esta página y en la página de desarrollo de apps con Flutter, no detrás de una llamada comercial. Las plataformas multivendedor y las flotas de apps de marca se presupuestan como trabajo enterprise. Lo que mueve la cifra es, primero, el número de métodos de pago y mercados, y segundo, cuánta maquinaria de catálogo aporta ya tu backend.
Sí, mediante platform channels respaldados por el SDK de pago propio de cada plataforma, presentados como la hoja de pago nativa que los usuarios reconocen. Las hojas nativas convierten mediblemente mejor que los formularios de tarjeta tecleados en móvil, así que las integramos junto al flujo de tarjeta del proveedor y no en su lugar. La introducción de la tarjeta en bruto se queda dentro del SDK del proveedor de pagos, lo que mantiene tu app fuera del alcance PCI allí donde el proveedor lo permite.
Sí, con la arquitectura adecuada: el catálogo vive en el servidor y la app sostiene una ventana paginada sobre él, con la búsqueda en el backend, imágenes dimensionadas y cacheadas por pantalla, y páginas de producto que se renderizan al instante desde los datos cacheados de la lista mientras los detalles cargan por detrás. El modo de fallo no es Flutter: es tratar un catálogo de cien mil artículos como una lista que descargar. Hemos entregado la mecánica de navegación a escala de marketplace, con precios multidivisa y feeds filtrados por ubicación.
No siempre, y lo diremos cuando una experiencia web móvil bien construida sea la respuesta honesta. Una app se gana su presupuesto con la superficie de retención que una web no tiene: notificaciones push de ofertas y actualizaciones de pedidos, un icono en la pantalla de inicio, hojas de pago nativas y mecánicas de fidelización que premian volver. Si la mayor parte de tus ingresos son clientes recurrentes, ese argumento suele ser sólido; si es tráfico de búsqueda de una sola vez, invierte primero en la web — eso también lo construimos.
Sí — es nuestra credencial de comercio más directa. Una base de código Flutter que construimos produce más de quince apps de consumo totalmente personalizadas más una app de comerciante, con un panel de administración que lanza una nueva marca sin trabajo de ingeniería. La trampa de política de tiendas es la directriz 4.2.6 de Apple, que existe para rechazar flotas de apps casi idénticas, y una plataforma de marca blanca tiene que diseñarse para superarla desde el principio. La arquitectura completa está documentada en nuestra página de servicio de marca blanca y en el artículo de ingeniería que la acompaña.

Lee el desglose de costes en Cuánto cuesta desarrollar una app en Flutter en 2026, mira cómo está construida la flota de la plataforma de fidelización o empieza por el pilar de desarrollo de apps con Flutter.