Descubrimiento y modelo de datos
Auditoría de la operación offline, modelo de inventario por tienda, recorrido del cliente para padres de EE. UU. y la UE, alcance del RGPD y la CCPA y planificación del envío a App Store y Google Play.
Caso de éxito · Retail · E-commerce
Caso de éxito Malish: marketplace local nativo para iOS + Android
Caso de éxito Malish: cómo lanzamos un marketplace nativo en Swift + Kotlin para una cadena offline de artículos infantiles, registro sin fricción, un catálogo inteligente con búsqueda flexible, pago en dos toques, un panel de administración para el equipo de negocio y una sincronización de inventario bidireccional que mantiene alineado el stock online y offline sin trabajo manual, todo ello según las expectativas del público de EE. UU. y la UE y bajo el marco del RGPD + la CCPA.
El reto: llevar online una cadena de varias tiendas sin romper el suelo de venta
El equipo de Malish acudió a nosotros con una próspera cadena offline de tiendas de artículos infantiles y una ambición digital clara: llevar el surtido a internet sin obligar a los padres a desplazarse a una tienda con los niños a cuestas, y llegar a una demanda situada más allá del radio a pie de cada local. La restricción no era aspiracional, sino operativa. La operación de inventario offline funciona, el personal de las tiendas conoce el catálogo y la ventaja competitiva de la cadena es la cuidada selección del surtido que le dio su reputación. La superficie digital tenía que prolongar esa operación, no sustituirla, y no podía provocar un desajuste de stock que rompiera la confianza del cliente en ningún sentido. El perfil del comprador abarca los patrones de consumo minorista de EE. UU. y la UE en cadenas similares que se expanden online: padres que investigan en el móvil por la noche, esperan una exactitud de inventario predecible y repiten la compra en un flujo de menos de 30 segundos cuando ya conocen el producto. Las plataformas SaaS de marketplace se descartaron porque las reglas de inventario y las restricciones de integración definidas por el proveedor chocan con la lógica de surtido de la propia cadena. Se consideró un MVP en Flutter y se relegó porque el acabado de retail (hápticos nativos del sistema, accesibilidad predecible, comportamiento idiomático de la plataforma) es exactamente donde un comprador de artículos infantiles nota la diferencia, y la prima de confianza de esta categoría no sobrevive a una interfaz en el valle inquietante (uncanny valley). El resultado es un cliente nativo de iOS en Swift, un cliente nativo de Android en Kotlin, un backend en Symfony con un panel de administración en React, un catálogo con tecnología ElasticSearch, sincronización de inventario bidireccional con las tiendas offline y reparto integrado, todo orientado a públicos de EE. UU. y la UE según las expectativas del RGPD y la CCPA desde el lanzamiento.
Aspectos destacados del proyecto
Cliente iOS nativo en Swift
Cliente Android nativo en Kotlin
Panel de administración en Symfony + React
Catálogo inteligente con búsqueda flexible
Flujo de pago en dos toques
Sincronización de inventario bidireccional con tiendas offline
Integración con el servicio de reparto
Enfoque RGPD + CCPA para EE. UU. y la UE
En cifras
Un resumen de lo que aportó el desarrollo de Malish en iOS nativo, Android nativo, el panel de administración en Symfony y la sincronización de inventario de varias tiendas en su primer ciclo de producción.
2plataformas móviles nativas: iOS y Android, con bases de código totalmente separadas y optimizadas para cada plataforma
2toques desde la pantalla de inicio de un comprador recurrente hasta un pedido realizado en el flujo típico de recompra
0cifras inventadas de usuarios, GMV o ingresos en este caso de éxito: solo datos de ingeniería
1backend Symfony tipado detrás de ambos clientes móviles, el panel de administración y la sincronización con las tiendas offline
2tiendas de apps en producción: Apple App Store y Google Play con un funcionamiento nativo e idiomático de cada plataforma
14–22 sem.plazo de entrega típico de un MVP comparable de marketplace local nativo para iOS + Android
Por qué iOS + Android nativos en lugar de Flutter y plataformas SaaS de marketplace
La decisión sobre la plataforma domina todas las demás decisiones de arquitectura en un marketplace de retail donde la confianza del comprador es el producto. Elegimos Swift nativo en iOS y Kotlin en Android frente a Flutter y las plataformas SaaS de marketplace porque las contrapartidas encajan limpiamente con la ventaja competitiva de la cadena. Swift y Kotlin nativos ofrecen la sensación idiomática de la plataforma que un comprador de retail percibe en los tres primeros toques (respuesta háptica precisa, navegación nativa del sistema, accesibilidad predecible y un flujo de toque para comprar indistinguible del de las demás apps de comercio del comprador). Flutter es una alternativa legítima cuando la marca acepta expresamente una interfaz ligeramente en el valle inquietante y prioriza la velocidad de una única base de código sobre el acabado de retail; para una cadena de artículos infantiles cuya prima de confianza no sobrevive a esa contrapartida, gana lo nativo.
Las plataformas SaaS de marketplace se descartaron porque las reglas de inventario y las restricciones de integración definidas por el proveedor chocan con la lógica de surtido de la propia cadena y con la alineación de stock entre tiendas que la operación ya mantiene. Se consideró una opción de Shopify más un envoltorio móvil a medida y se relegó porque la superficie de dependencia se acumula (proveedor de pagos, tema, modelo de inventario, límites de las extensiones de la app) y el foso competitivo de la cadena es precisamente la selección cuidada que un marketplace con plantillas aplana. Todo el stack (Swift, Kotlin, Symfony, panel de administración en React, ElasticSearch, PostgreSQL, Redis) es abierto y citable de extremo a extremo, sin ninguna plataforma propietaria que ate al equipo de operaciones a un único proveedor.
| Criterio | Nativo (Malish) | Flutter | Plataforma SaaS de marketplace |
|---|---|---|---|
| Acabado nativo | Idiomático de la plataforma: hápticos, navegación, accesibilidad | Cercano, pero con riesgo de valle inquietante en retail | Definido por el proveedor; varía según la plantilla |
| Flexibilidad de la sincronización de inventario | Conector Symfony propio por tienda | Propio: el mismo backend Symfony | Conector del proveedor; extensión limitada |
| Encaje con varias tiendas | Disponibilidad por tienda en el catálogo | Posible; mismo backend | Modelo multitienda del proveedor: con opiniones propias |
| Dependencia del SaaS de marketplace | Ninguna: stack totalmente propio | Ninguna: stack totalmente propio | Alta: pagos, tema, inventario |
| Tiempo hasta el lanzamiento | 14–22 semanas para el MVP | 10–18 semanas: una única base de código | 4–10 semanas: definido por la plantilla |
| Adecuación a App Store / Play Store | Binarios nativos de primer nivel | Aceptable; patrones de revisión conocidos | App del proveedor: cascarón con la marca |
| Encaje normativo (EE. UU. y la UE) | Propio: RGPD + CCPA integrados desde el diseño | Propio: mismo enfoque | Controlado por el proveedor: varía según la región |
Referencias de la plataforma: documentación de Swift de Apple, documentación de Kotlin, documentación de Symfony.
Desarrollo para iOS: Swift, catálogo inteligente y pago en dos toques
El cliente de iOS está desarrollado en Swift con un híbrido de UIKit y SwiftUI: SwiftUI en las pantallas donde su rapidez ayuda y UIKit donde importa su previsibilidad. Toda la superficie visible para el usuario se estructura en torno a un catálogo inteligente con búsqueda flexible respaldada por ElasticSearch (por marca, categoría, rango de edad, talla, tienda y los términos libres que realmente usan los padres) y a un pago en dos toques que reduce el flujo del comprador recurrente a su superficie mínima creíble. Un toque confirma el carrito con la dirección de entrega predeterminada y el método de pago guardado; el segundo toque realiza el pedido con un paso final de revisión. Apple Pay y las tarjetas guardadas rellenan previamente la superficie de pago; el autocompletado de direcciones rellena previamente la entrega.
El registro es sin fricción por diseño: un padre con un niño pequeño en brazos no tiene paciencia para un onboarding de varias pantallas. La selección de tienda en el primer inicio tiene en cuenta la ubicación y admite un cambio manual; los inicios posteriores usan por defecto la última tienda seleccionada. Las notificaciones push de promociones, estado del pedido y avisos de recogida listos funcionan sobre Apple Push Notification service, con consentimiento explícito en la primera autorización. La superficie de iOS se entrega como parte de nuestra práctica de desarrollo de aplicaciones móviles y comparte su sistema de diseño con el cliente de Android mediante una especificación común de design tokens, no mediante una base de código compartida.
Desarrollo para Android: Kotlin, catálogo multitienda y panel de pedidos
El cliente de Android está escrito en Kotlin con Jetpack Compose para la capa de interfaz y el mismo catálogo respaldado por ElasticSearch que consume el cliente de iOS. El catálogo calcula la disponibilidad por tienda en lugar de una única cifra para toda la cadena, de modo que un comprador que recoge en tienda ve el stock de esa tienda y un comprador con entrega a domicilio ve el stock de la tienda más cercana que puede servir el pedido. El encaje multitienda fue la restricción de diseño dominante: una cadena de artículos infantiles cuyas tiendas tienen surtidos solapados pero no idénticos no puede sobrevivir a una única cifra de stock para toda la cadena que engaña al comprador en un sentido u otro.
Tras el catálogo, el motor de flujo de pedidos del backend en Symfony gestiona las transiciones de estado (realizado, preparado, listo, enviado, entregado) con eventos webhook hacia los terminales del personal de las tiendas offline y notificaciones push al comprador. Google Play Billing gestiona las compras dentro de la app; la integración con la API del proveedor de reparto se ocupa del traspaso al mensajero para que la cadena no coordine a los mensajeros a mano. El mismo equipo de ingeniería se ocupa de iOS y Android en paralelo dentro de nuestra práctica de ingeniería para iOS y Android, y el panel de administración en React, una superficie distinta pero diseñada conjuntamente, reside en el mismo despliegue de Symfony para el equipo de operaciones.
Enfoque de privacidad, sincronización de inventario bidireccional y registros preparados para auditoría
El enfoque de privacidad de Malish fue una decisión de arquitectura antes que un banner. Los datos personales en los clientes móviles se limitan a lo necesario para el pago, la entrega y la recompra; el modelo de datos codifica ventanas de retención por entidad, de modo que el registro de un pedido entregado se purga según un calendario y no se acumula indefinidamente. Intencionadamente no se recogen datos de menores: el comprador es el padre o la madre, el catálogo es de artículos infantiles, pero la app no solicita información que identifique a niños más allá de un filtro genérico de rango de edad en el catálogo.
La sincronización de inventario bidireccional es la columna vertebral operativa. Cada tienda offline tiene un conector tipado que emite actualizaciones por webhook ante cambios de stock (ventas, reposiciones, correcciones manuales), y el backend en Symfony las ingiere, las concilia y las propaga al catálogo móvil. El registro de conciliación se expone en el panel de administración en React para que un operador pueda depurar una discrepancia en minutos en lugar de conciliar dos sistemas a mano. Los registros de acceso están estructurados y rotados; cada cambio de catálogo, cada transición de estado de un pedido y cada decisión de consentimiento quedan registrados en una pista de auditoría inmutable. El enfoque está diseñado para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las obligaciones de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Metodología de entrega
Un desarrollo en cinco fases que llevó a Malish de una cadena de retail solo offline a un marketplace nativo para iOS + Android con sincronización de inventario de varias tiendas y reparto integrado.
Backend en Symfony y catálogo
Esqueleto de Symfony, API REST tipada, catálogo en ElasticSearch, modelo de disponibilidad por tienda, motor de flujo de pedidos, caché en Redis y esqueleto de la sincronización de inventario bidireccional.
Desarrollo nativo para iOS + Android
Cliente de iOS en Swift y cliente de Android en Kotlin construidos en paralelo, UX del catálogo inteligente, pago en dos toques, notificaciones push e integración con Apple Pay y Google Play Billing.
Panel de administración y reparto
Panel de administración en React con acceso basado en roles, panel de pedidos, integración con la API del proveedor de reparto, registro de conciliación, refuerzo preparado para auditoría y estructura base de la evaluación de preparación por terceros.
Lanzamiento y crecimiento
Envío a App Store y Google Play en las tiendas de EE. UU. y la UE, despliegue de los conectores de inventario en las tiendas offline, incorporación del equipo de operaciones y paneles de analítica.
Flujo de pedidos, integración de reparto y panel de administración
El flujo de pedidos de Malish es la parte del desarrollo que se acumula operativamente. El backend en Symfony aloja un motor de flujo de trabajo que lleva los pedidos por los estados realizado, preparado, listo, enviado y entregado, con barreras de transición explícitas y difusión por webhook hacia los terminales del personal de las tiendas offline y el canal push del comprador. La integración con la API del proveedor de reparto se ocupa del traspaso al mensajero: cuando un pedido entra en el estado «listo», el backend solicita un mensajero al proveedor integrado, le entrega la dirección y escucha las actualizaciones de estado que se propagan al comprador casi en tiempo real. Se admiten los flujos de contra reembolso en efectivo y con tarjeta junto con el pago dentro de la app, para los perfiles de comprador en los que esa opción aún importa. El panel de administración en React envuelve el flujo con un modelo de acceso basado en roles (empleado de tienda, responsable de tienda, operaciones centrales, finanzas) y una pista de auditoría que sobrevive a la rotación del equipo. La gestión flexible de productos y categorías permite al equipo de negocio añadir una marca, una categoría, un rango de edad o una colección de temporada sin un desarrollador de por medio; la misma superficie de administración incluye campañas promocionales, programación de banners y la vista de compradores al estilo CRM que el equipo de operaciones usa para las acciones de recompra. Añadir una nueva tienda a la cadena es un cambio de configuración de una sola página en el mismo panel de administración: una fila, un conector de inventario, un polígono de zona de reparto, y la tienda aparece en el catálogo multitienda sin desplegar nada.
Lanzamiento en Estados Unidos y la Unión Europea
Malish se lanzó en Apple App Store y Google Play con fichas activas en Estados Unidos y en la Unión Europea para cadenas de retail que se expanden online. La misma arquitectura da servicio a una cadena de artículos infantiles con varias tiendas en California, Nueva York, Texas, Florida o Washington en EE. UU., y en Países Bajos, Alemania, Francia, Irlanda o Suecia en la UE, sin bifurcaciones de la base de código por región. Los flujos de consentimiento dependen de la región en la capa del cliente: los compradores de la UE y del EEE reciben una pantalla de consentimiento granular al estilo del RGPD, con interruptores separados para cualquier analítica de producto opcional; los compradores de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios europeos y con el mosaico de normas estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Como el modelo de datos minimiza los datos personales por diseño y no solicita expresamente información que identifique a niños, el cumplimiento regional se reduce a una divulgación honesta y a un flujo de consentimiento limpio, y no a una segregación de datos por jurisdicción.
La infraestructura se desplegó en paralelo en regiones de la UE y de EE. UU. (Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; costa este y costa oeste de EE. UU. para Norteamérica), de modo que las apps atienden a ambos mercados con baja latencia desde el lanzamiento. Tanto la clasificación por edades de App Store como la clasificación de contenido de Google Play se calibraron para el conjunto de funciones del retail de artículos infantiles, y la política de privacidad dentro de la app se redactó para documentar la arquitectura descrita, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería que está detrás del desarrollo está repartido en la zona CET y trabaja con una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación de las revisiones de las tiendas y la respuesta a incidencias: la franja horaria que permite a un operador de retail con sede en EE. UU. y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día. El marketplace atiende a públicos de EE. UU. y la UE como una única superficie unificada.
Stack tecnológico y hoja de ruta
Swift
Kotlin
PHP
Symfony
React
PostgreSQL
Redis
REST API
Ingesta de webhooks
Sincronización de inventario
Motor de flujos de pedidos
Notificaciones push
Apple StoreKit
Google Play Billing
Pipeline de imágenes
Búsqueda de productos con ElasticSearch
Acceso de administración basado en roles
API del proveedor de reparto
La hoja de ruta activa de desarrollo de software a medida de Malish incluye un subsistema de fidelización con niveles por tienda y un monedero de recompensas para los padres, una superficie de localizador de tiendas con horarios en tiempo real y reserva de franja de recogida, un modelo ampliado de zonas de reparto para el cumplimiento entre tiendas y un nivel mayorista para clientes B2B del segmento de puericultura de EE. UU. y la UE. Se ha previsto como extensión de segunda fase una superficie web complementaria, que compartirá el backend en Symfony y la especificación de design tokens con los clientes nativos, para captar el tráfico de consulta desde el escritorio sin sacar a los padres del móvil. Los planes de infraestructura incluyen más automatización del registro de conciliación, un banco de pruebas interno de alertas por desajuste de stock y una futura evaluación independiente de preparación integrada en la hoja de ruta de cloud y DevOps.
Cree un marketplace como este: hable con nosotros
Si está planificando un marketplace nativo para iOS + Android, una cadena de retail con varias tiendas que se pasa a lo online o cualquier producto de retail de consumo en el que la sincronización de inventario y el acabado de la plataforma deban cumplirse a la vez para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma significativa el plazo de desarrollo. El equipo de ingeniería que lo desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado para MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con una jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Preguntas frecuentes
¿Cuánto cuesta crear un marketplace local nativo para iOS y Android?
Un marketplace local nativo para iOS y Android con backend en Symfony, catálogo en ElasticSearch, pago en dos toques y un panel de administración básico suele costar $140k–$310k para un MVP. Añadir sincronización de inventario bidireccional con las tiendas offline, integración con el servicio de reparto, acceso de administración basado en roles, búsqueda flexible con ElasticSearch y una consola de administración reforzada de nivel CRM lleva un producto completo a $360k–$680k. Los principales factores de coste son la capa de sincronización de inventario, la lógica del catálogo multitienda y la coordinación del envío y la revisión en App Store y Google Play.
¿Por qué usar iOS y Android nativos en lugar de Flutter o una plataforma SaaS de marketplace?
Swift nativo en iOS y Kotlin en Android ofrecen la sensación idiomática de la plataforma que un comprador de retail percibe en los tres primeros toques: respuesta háptica precisa, navegación nativa del sistema y accesibilidad predecible. Flutter es una alternativa legítima cuando la marca acepta expresamente una interfaz ligeramente en el valle inquietante (uncanny valley) y prioriza la velocidad de una única base de código. Las plataformas SaaS de marketplace atan la marca a reglas de inventario y restricciones de integración definidas por el proveedor, algo fatal para una cadena cuya ventaja competitiva es la red de tiendas offline y su propio surtido. En Malish ganó lo nativo por el acabado de retail y la flexibilidad de integración.
¿Cómo se mantiene alineado el inventario online y offline en una cadena de varias tiendas?
Una sincronización de inventario bidireccional defendible es una decisión de arquitectura. Cada tienda offline tiene un conector tipado que emite actualizaciones por webhook ante cambios de stock; el backend en Symfony las ingiere, las concilia y las propaga al catálogo móvil. El catálogo calcula la disponibilidad por tienda en lugar de una única cifra para toda la cadena, de modo que un comprador que recoge en tienda ve el stock de esa tienda. El panel de administración expone el registro de conciliación para que un operador pueda depurar una discrepancia en minutos en lugar de conciliar dos sistemas a mano.
¿Cómo es un flujo de pago en dos toques en una app de marketplace?
Un flujo de pago en dos toques reduce las decisiones del comprador a la superficie mínima creíble: un toque confirma el carrito con la dirección de entrega predeterminada y el método de pago guardado; un segundo toque realiza el pedido con un paso final de revisión. Las tarjetas guardadas, Apple Pay y Google Play Billing rellenan previamente la superficie de pago; el autocompletado de direcciones rellena previamente la de entrega; y un interruptor de sustitución permite al comprador autorizar de antemano un cambio por un artículo agotado. El flujo es el estándar de referencia de las apps de retail de recompra.
¿Cuánto se tarda en lanzar un marketplace local nativo para iOS y Android?
Un MVP acotado con clientes nativos en Swift y Kotlin, un backend en Symfony, búsqueda con ElasticSearch, pago en dos toques y herramientas básicas de administración suele llevar de 14 a 22 semanas. Añadir sincronización de inventario bidireccional con las tiendas offline, integración con el servicio de reparto, acceso de administración basado en roles, un panel de analítica y un subsistema de fidelización suma de 8 a 14 semanas. La fase de refuerzo preparada para auditoría (envío a App Store y Google Play, traspaso de KYC para los pagos, revisión de preparación por terceros) conviene presupuestarla en 3–5 semanas de trabajo dedicado.
Casos relacionados
Más desarrollos de retail y marketplaces
Ecosistema de reparto de alimentación
App de cliente, app de preparador y panel de administración para una cadena regional de supermercados: logística diseñada desde cero.
Ver el caso →
FlowDelivery
Descubrimiento para un par de apps de reparto de flores: catálogo con control de stock, pago en tres pasos e inventario de floristerías.
Ver el caso →
ZipIt
Marketplace de autopiezas con CRM para vendedores: búsqueda por VIN e inventario multiubicación.
Ver el caso →Servicios relacionados
Desarrollo de MVP
MVP listo para inversores entregado en 12 semanas por 60-120k EUR. PM sénior, diseñador, ingenieros y QA.
Más información →
Desarrollo de aplicaciones móviles
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Más información →
Ampliación de equipos de TI (staff augmentation)
Ingenieros sénior integrados en su Jira y en sus standups en dos semanas. Jornada CET con solapamiento con la costa este de EE. UU.
Más información →Planifique un desarrollo similar
Reservar una llamada inicialPedir propuesta
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.