Caso de éxito · Automoción · E-commerce
Caso de éxito ZipIt: cómo lanzamos en producción un marketplace bilateral de autopiezas —apps de comprador en Flutter para iOS y Android, una superficie web para compradores y un CRM multi-tenant para vendedores—, creado con Symfony, con búsqueda por VIN respaldada por Laximo, inventario por ubicación en muchas sucursales, traspaso integrado a la entrega y un enfoque listo para auditoría que resiste las exigencias del RGPD y la CCPA para compradores y vendedores de Estados Unidos y la Unión Europea.
Un operador de alquiler de coches tenía dificultades continuas para conseguir recambios de proveedores dispersos y desconectados. Cada compra exigía rastrear entre proveedores, comparar precios por teléfono y conciliar entregas que llegaban desde distintas direcciones en días distintos. El equipo necesitaba una única capa de compras: un marketplace de cara al comprador que reuniera los catálogos de piezas de varios vendedores, con búsqueda por VIN para que un mecánico pudiera encontrar piezas compatibles sin hojear microfichas en papel, y un CRM de cara al vendedor que diera a los minoristas de recambios una razón creíble para trasladar su inventario de las hojas de cálculo. La plataforma también debía resistir las expectativas de compradores y vendedores en Estados Unidos y la Unión Europea: el RGPD para usuarios europeos, la CCPA para usuarios de California y registros listos para auditoría para operadores que atienden flotas en varias jurisdicciones. Construimos la plataforma como una app de comprador en Flutter para iOS y Android, una superficie web de comprador en React y un CRM multi-tenant para vendedores sobre un backend compartido en Symfony, con búsqueda por VIN respaldada por Laximo y traspaso integrado a la entrega. El resultado es un marketplace en producción que cierra el ciclo desde la consulta del VIN hasta la entrega de la pieza y está posicionado para operar conforme a las expectativas de privacidad en EE. UU. y la UE.
Un resumen de lo que aportó el desarrollo de ZipIt en apps de comprador en Flutter, una superficie web en React y un CRM multi-tenant de vendedores en Symfony.
La decisión de plataforma pesa más que cualquier otra en la velocidad de iteración de un marketplace bilateral. Elegimos Flutter en el lado del comprador frente a un par de apps nativas iOS + Android y frente a un envoltorio de tienda Magento porque las contrapartidas encajan limpiamente con lo que realmente necesita un marketplace de autopiezas. Magento es una plataforma de e-commerce sólida para catálogos de un solo vendedor, pero paga un coste elevado cuando se intenta hacerla multi-tenant, y un stack «Magento + envoltorio móvil» añade una capa de WebView que tanto los compradores como el revisor de App Store detectan de inmediato. Las apps nativas iOS + Android aportarían un valor marginal para un producto de formularios y catálogo, al doble del coste de ingeniería de una base de código en Flutter.
El desarrollo se apoya en los patrones de la documentación oficial de Flutter para la gestión de estado y los canales de plataforma, en el framework Symfony en el backend y en la seguridad a nivel de fila de PostgreSQL para el aislamiento de tenants en el CRM multi-tenant de vendedores: primitivas abiertas y citables que nos dan un marketplace multiplataforma mantenible sin atar al operador a un SaaS de un proveedor.
| Criterio | Flutter (ZipIt) | iOS + Android nativos | Magento + envoltorio móvil |
|---|---|---|---|
| Encaje con el CRM multi-tenant | Independiente del backend; Symfony es multi-tenant de forma nativa | Mismo backend; mismo encaje | El multi-tenant de Magento es un añadido frágil |
| Latencia de la búsqueda por VIN | HTTP de Dart + adaptador de Laximo con caché en Redis | HTTP nativo; misma latencia de backend | Plugin de Magento o viaje de ida y vuelta por WebView: visiblemente más lento |
| Ergonomía de la integración de entregas | Un único cliente Dart, compartido con la web | Dos clientes que mantener en paralelo | Extensiones de Magento, actualizaciones frágiles |
| Analítica para vendedores | Paneles propios del backend, renderizados por Symfony | Mismo backend; mismo enfoque | Complemento de Business Intelligence de Magento: costoso |
| Velocidad de iteración | Una base de código Dart, UX con hot-reload | Dos bases de código, el doble de QA | Riesgo de compatibilidad de extensiones en cada versión |
| Adecuación a la revisión de la App Store | De primer nivel: la app de comprador es un binario nativo | De primer nivel | A menudo marcada como «envoltorio web» |
| Control de la residencia de los datos | Infraestructura propiedad del operador en regiones de EE. UU. o la UE | Mismo enfoque | Solo el mapa de regiones de Magento Commerce Cloud |
Referencias: documentación de Flutter, documentación del framework Symfony, referencia de seguridad a nivel de fila de PostgreSQL.
El CRM de vendedores es una aplicación de una sola página en React respaldada por un backend multi-tenant en Symfony. Cada vendedor es un tenant de nivel superior; cada sucursal —tienda física, almacén regional— es una entidad hija dentro de ese tenant. La seguridad a nivel de fila de PostgreSQL garantiza el aislamiento entre tenants, de modo que un vendedor de un tenant no puede leer el inventario de otro, y el índice de búsqueda de cara al comprador es consciente de los tenants, por lo que el comprador ve un conjunto de resultados unificado sin llegar a ver nunca la frontera entre tenants. La recepción de mercancías, el inventario por ubicación, los precios, la verificación de contrapartes y los flujos de pedidos viven por sucursal y se consolidan en un panel de todo el tenant, de modo que un vendedor con tiendas en varias ciudades ve una vista coherente.
La verificación de contrapartes da al operador una posición defendible sobre quién puede vender en el marketplace. El CRM ingiere documentos mercantiles durante el alta del vendedor, los pasa por una cola de verificación (prueba de vida del documento, análisis de caducidad, confianza del OCR) con una fase de revisión humana y escribe una pista de auditoría inmutable por vendedor. Los registros se conservan según los requisitos de la normativa mercantil local —distinta en California, en Países Bajos o en el Reino Unido— y se cifran en reposo con rotación de claves. Toda la superficie del vendedor se entrega como parte de nuestra práctica de desarrollo de software a medida.
El cliente de comprador está construido en Flutter con una única base de código Dart que da servicio a iOS y Android. La autenticación sin contraseña reduce la fricción del registro: el comprador introduce un número de teléfono o un correo, recibe un código de un solo uso y está en el catálogo en cuestión de segundos. La búsqueda por VIN es la puerta de entrada principal: el comprador introduce un VIN o selecciona una marca y un modelo, y la app llama al servicio adaptador de VIN, que consulta el catálogo de tipo Laximo y concilia los resultados con el inventario del lado del vendedor en todos los tenants. El resultado es una lista unificada de piezas con disponibilidad entre ubicaciones, precios por vendedor y un botón de añadir al carrito con una sola pulsación que respeta el aislamiento entre tenants entre bastidores.
El flujo de pedido cierra el ciclo. El comprador revisa el carrito, elige una opción de entrega entre los proveedores de entrega integrados y confirma: el pedido se escribe en el registro de auditoría inmutable, el CRM de vendedores recoge el pedido en las sucursales afectadas y el comprador recibe una notificación push cuando cada sucursal envía. Los operadores transatlánticos pueden encaminar a un comprador de California hacia un vendedor de EE. UU. y a un comprador de Alemania hacia un vendedor de Países Bajos sin que el comprador elija nunca una región; el modelo de datos se encarga de ello. El mismo equipo de ingeniería entrega la app de comprador y el CRM de vendedores en paralelo como parte de nuestra práctica de desarrollo de apps móviles.
La integración de entregas convierte un pedido de un solo vendedor en un cumplimiento de varios tramos sin obligar al comprador a pensar en ello. Cada sucursal traspasa el pedido a su proveedor de entrega preferido mediante una capa adaptadora fina; el backend sigue cada tramo a través del motor de flujo de pedidos y escribe las actualizaciones de estado en el registro de auditoría inmutable. Los compradores ven una única línea de tiempo de seguimiento que agrega el estado de cada tramo, y los vendedores ven una vista de cumplimiento por sucursal dentro del CRM. La analítica para vendedores vive en el mismo backend de Symfony y aparece en el CRM como paneles casi en tiempo real: unidades vendidas por sucursal, tiempo medio de cumplimiento, términos de búsqueda principales por región y estado de verificación de contrapartes en las sucursales del tenant.
El enfoque de tratamiento de datos se alinea con las obligaciones del RGPD para compradores y vendedores de la Unión Europea y las de la CCPA / CPRA para usuarios de California y del resto de Estados Unidos. Los datos de compradores, los datos de vendedores y el registro de auditoría de pedidos pueden fijarse a regiones de EE. UU. o de la UE para futuros compromisos de residencia de datos, y el modelo multi-tenant mantiene el aislamiento entre tenants aplicado en la capa de base de datos y no en la capa de aplicación.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó a ZipIt desde una historia de compras fragmentada hasta un marketplace bilateral en producción en iOS, Android, web y un CRM multi-tenant para vendedores.
Mapeo del recorrido del comprador (línea base de compras por teléfono), estudio del flujo de trabajo del vendedor, modelo de datos multi-tenant, revisión de privacidad comercial de EE. UU. y la UE y evaluación de proveedores de catálogos de VIN.
Backend multi-tenant en Symfony, seguridad a nivel de fila de PostgreSQL, índice de búsqueda consciente de los tenants, servicio adaptador de VIN, especificación del adaptador de proveedores de entrega y registro de auditoría inmutable de pedidos.
App de comprador en Flutter para iOS y Android, superficie web de comprador en React, CRM de vendedores en React, búsqueda por VIN de principio a fin, flujo de carrito y pedido y paneles para vendedores.
Flujo de verificación de contrapartes, datos cifrados en reposo, pruebas de aislamiento entre tenants, QA de la integración de entregas, prueba de carga multi-tenant con el tamaño de catálogo previsto y coreografía de revisión en las tiendas.
Envío a App Store + Google Play en las tiendas de EE. UU. y la UE, despliegue por tenant, coreografía de incorporación de vendedores y runbooks de guardia para los adaptadores de VIN y de entregas.
La analítica para vendedores de ZipIt convierte el CRM en algo que el vendedor mantendrá abierto todo el día, y no solo en un lugar donde subir el inventario una vez por semana. Los paneles respaldados por Symfony agregan las unidades vendidas por sucursal, el tiempo medio de cumplimiento por proveedor de entrega, los términos de búsqueda principales por región y el estado de verificación de contrapartes en las sucursales del tenant. Los mismos datos respaldan una exportación por tenant para que un vendedor con tiendas en Países Bajos y Alemania pueda conciliar con su flujo contable existente sin pagar un complemento de Business Intelligence de Magento. La migración de tenants se incorporó desde el primer día: un vendedor nuevo puede darse de alta, importar inventario desde una carga estructurada, ser verificado y estar en el marketplace en cuestión de horas y no de semanas, y un vendedor existente puede mover sucursales entre tenants si cambia su estructura societaria sin perder la pista de auditoría por sucursal. Los operadores entre tenants pueden acotar su vista por región, que es como un único equipo de back office cubre las operaciones de EE. UU. y la UE en turnos tranquilos sin perder el límite de cumplimiento por tenant.
La plataforma ZipIt se diseñó para operadores de marketplaces de automoción que atienden a compradores y vendedores en Estados Unidos y la Unión Europea. La versión en inglés da servicio a usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento tienen en cuenta la región en la capa del cliente: los usuarios de la UE y del EEE reciben una pantalla de consentimiento granular al estilo del RGPD, con interruptores independientes para los canales de marketing y la analítica de producto opcional; los usuarios 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 leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y Oregon CPA. Los registros de verificación de contrapartes de los vendedores se conservan según los requisitos de la normativa mercantil local, y los registros de pedidos listos para auditoría convierten el cumplimiento regional en un ejercicio de divulgación honesta y no en un problema de segregación de datos por jurisdicción.
El despliegue del backend se ejecuta 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; el este y el oeste de EE. UU. para Norteamérica—, con servicios de Symfony e instancias de PostgreSQL aprovisionados de forma idéntica mediante Terraform. El almacén de tenants y el registro de auditoría de pedidos pueden fijarse a regiones de EE. UU. o de la UE para futuros compromisos de residencia de datos, y los adaptadores de VIN y de entregas no tienen estado, por lo que pueden escalarse de forma independiente en cada región. Tanto la clasificación por edad de App Store como la clasificación de contenido de Google Play se calibraron para una app de marketplace, y la política de privacidad dentro de la app se redactó para documentar exactamente la arquitectura anterior, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja con una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coreografía de revisión en las tiendas y la respuesta de guardia en los flujos transatlánticos de incorporación de vendedores.
La hoja de ruta activa de desarrollo de software a medida de ZipIt incluye un nivel B2B con dominio propio y SSO para compradores corporativos de flotas, una integración más profunda con sistemas contables y ERP de EE. UU. y la UE, un arnés interno de verificación continua de las invariantes de aislamiento entre tenants y un adaptador de catálogo de VIN de segunda fuente para dar redundancia entre regiones. Los planes de infraestructura incluyen más particionado (sharding) por tenant para el rendimiento multi-tenant previsto y una futura evaluación de preparación independiente integrada en la hoja de ruta de cloud y DevOps.
Si está planificando un marketplace de autopiezas, una plataforma de comercio B2B multi-tenant o cualquier producto bilateral en el que el CRM del lado del vendedor deba resistir la revisión de un regulador para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el calendario del desarrollo. El equipo de ingeniería responsable trabaja dentro de YuSMP Group. Trabajamos a precio cerrado para MVP bien delimitados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una ventana garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP centrado en una app de comprador en Flutter para iOS y Android, una superficie web de comprador y un CRM multi-tenant para vendedores con recepción de mercancías e inventario por ubicación suele costar entre $180k y $340k. Añadir la búsqueda de piezas por VIN mediante una integración con un catálogo de tipo Laximo, traspaso integrado a la entrega, analítica para vendedores, verificación de contrapartes y un enfoque listo para auditoría para operadores de EE. UU. y la UE lleva una plataforma completa a $360k–$700k. Los principales factores de coste son la integración del catálogo de VIN, el modelo de datos multi-tenant y la analítica para vendedores que el CRM debe mantener casi en tiempo real.
Las apps de comprador de autopiezas son productos de formularios y catálogo con una integración relativamente superficial con la plataforma, justo donde Flutter es más fuerte. Una única base de código Dart entrega las apps de comprador para iOS y Android con una sola pasada de ingeniería, tokens de diseño compartidos con la superficie web de comprador y una iteración más rápida de la interfaz del catálogo que con dos equipos nativos. Las apps nativas de iOS y Android añadirían coste sin aportar un valor proporcional para la búsqueda por VIN, el carrito y el flujo de pedido. Reservamos los desarrollos nativos para los casos en que dominan la especificación la ubicación continua, la fiabilidad del push o la integración a nivel de kernel.
Un CRM multi-tenant trata a cada vendedor como un tenant de nivel superior y a cada sucursal como una entidad hija dentro de ese tenant. El inventario, las recepciones de mercancías, los precios y los flujos de pedidos viven por sucursal pero se consolidan en un panel de todo el tenant, de modo que un vendedor con tiendas en varias ciudades ve una vista coherente. Symfony respalda el almacén de tenants; el filtrado a nivel de fila de PostgreSQL garantiza el aislamiento entre tenants, y la app de comprador lee la disponibilidad entre ubicaciones mediante un índice de búsqueda consciente de los tenants, de modo que un comprador nunca ve una pieza de un vendedor con el que no puede operar.
La búsqueda por VIN se implementa como un servicio adaptador dedicado que consulta un catálogo de automoción de tipo Laximo y concilia los resultados con el inventario del lado del vendedor. El adaptador traduce un VIN en una lista estructurada de referencias de piezas, las distribuye al índice de inventario de vendedores y devuelve un conjunto de resultados unificado con disponibilidad entre ubicaciones y precios por vendedor. El adaptador guarda en caché en Redis las consultas de VIN frecuentes con TTL ajustados a la cadencia de actualización del catálogo, y escribe cada consulta en un registro de auditoría para que el operador pueda atribuir el tráfico de búsqueda por comprador en la analítica de EE. UU. y la UE.
Una app de comprador en Flutter para iOS y Android, una superficie web de comprador y un CRM multi-tenant para vendedores en Symfony con recepción de mercancías e inventario por ubicación suelen tardar entre 14 y 22 semanas para el MVP. Añadir la búsqueda de piezas por VIN mediante un catálogo de tipo Laximo, el traspaso integrado a la entrega, la analítica para vendedores, la verificación de contrapartes y un enfoque listo para auditoría para operadores de EE. UU. y la UE suma entre 8 y 14 semanas. La integración del catálogo de VIN suele ser el tramo más largo porque las API de catálogos reales devuelven referencias de piezas incoherentes que requieren conciliación en el servidor.
Casos relacionados
Plataforma de taxis con tres apps —conductor, pasajero y despachador—, con transmisión de GPS en tiempo real y verificación de documentos.
Ver el caso →
App para asesores de retail con inventario de boutiques entre tiendas: búsqueda con ElasticSearch, integración con 1C y alcance multitienda.
Ver el caso →
App móvil de marketplace local para una cadena física de artículos infantiles: catálogo flexible y sincronización de stock online.
Ver el caso →
MVP listo para inversores entregado en 12 semanas por 60-120k EUR. PM sénior, diseñador, ingenieros y QA.
Más información →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Más información →
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 →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.