Caso de éxito · Restauración · Pedidos de comida
Caso de éxito Vilka-Lozhka: cómo reconstruimos desde cero las apps móviles de una cadena de restaurantes de comida rápida informal —clientes nativos de iOS y Android sobre un backend limpio en Laravel, un catálogo de combos, un carrito en tiempo real, una vía estable de adquirencia con tarjeta y pagos recurrentes, un saldo de fidelización y programación de la hora de recogida— publicadas en App Store y Google Play y creadas para atender a públicos de Estados Unidos y la Unión Europea con las exigencias del RGPD y la CCPA.
El equipo de producto de Vilka-Lozhka llegó a YuSMP Group con un par de apps móviles que habían dejado de hacer lo único que una app de pedidos de comida tiene que hacer con fiabilidad: cobrar. El código heredado había acumulado errores críticos, y la integración de pagos —apoyada en una conexión defectuosa con Apple Pay y Google Pay— fallaba con tanta frecuencia que los clientes abandonaban los pedidos al pagar. La cadena necesitaba un rediseño completo y una reconstrucción funcional, no un parche: eliminar los defectos heredados, sustituir la vía de pago por un flujo estable de adquirencia con tarjeta que admitiera cargos únicos y recurrentes, y renovar la interfaz para que las apps pudieran superar la revisión de App Store y Google Play y verse actuales junto a competidores centrados en el reparto. El desarrollo debía atender a compradores de Estados Unidos y la Unión Europea desde una única base de código, con el enfoque de privacidad y los avisos que los públicos de EE. UU. y la UE esperan hoy de cualquier app que guarde un token de tarjeta y una identidad de fidelización. Lo tratamos como una reescritura desde cero del dominio de pedidos y pagos —un backend limpio en Laravel y React, Swift nativo en iOS y Kotlin en Android— conservando intactos el catálogo de menús y los datos de fidelización.
Un resumen de lo que aportó la reconstrucción de Vilka-Lozhka en iOS, Android y un backend de pedidos limpio durante su primer ciclo de producción.
La decisión que dominó este proyecto fue construir o parchear. Las apps heredadas tenían dos clases de fallos especialmente peligrosos de parchear de forma incremental: una conexión de pagos defectuosa y una aritmética del carrito poco fiable. Ambas están en la vía del dinero, donde una corrección descuidada cobra dos veces a un cliente o pierde un pedido, así que perseguir regresiones a través de código acumulado es más lento y arriesgado que una reescritura disciplinada del dominio de pedidos y pagos. También evaluamos SDK de pedidos de restaurante de marca blanca y los descartamos: sus flujos de pago no podían alojar las reglas de fidelización que ya tenía la cadena, sus opciones de adquirencia no incluían la vía de pagos recurrentes que necesitaba el negocio y sus paquetes inflaban el IPA y el APK por encima de los umbrales que App Store aplica a las instalaciones por red móvil.
Optar por lo nativo sobre un stack limpio de desarrollo de apps móviles —Swift en iOS, Kotlin en Android y un backend en Laravel y React— nos permitió conservar el catálogo de menús y los datos de fidelización mientras reescribíamos todo lo que toca el pago, el estado del carrito y el estado del pedido. La comparación siguiente es la justificación que expusimos al cliente antes de comprometernos con la reconstrucción.
| Criterio | Reconstrucción nativa (Vilka-Lozhka) | Parchear el código heredado | SDK de marca blanca |
|---|---|---|---|
| Estabilidad de la vía de pago | Reescrita sobre un único proveedor de adquirencia con idempotencia | Conexión defectuosa con Apple/Google Pay heredada | Fijado por el proveedor; los pagos recurrentes a menudo no están disponibles |
| Pagos recurrentes | Con token, compatibles desde el primer día | Inexistentes; difíciles de añadir después con seguridad | Depende del proveedor; rara vez flexible |
| Reglas de fidelización | Libro mayor propio, con las reglas de la cadena preservadas | Contadores frágiles propensos a corromperse | Modelo de fidelización del proveedor, no el de la cadena |
| Tamaño del paquete de la app | Binarios nativos ligeros por plataforma | Arrastra código muerto y dependencias antiguas | SDK hinchado, por encima de los límites de instalación por red móvil |
| Riesgo de aprobación en las tiendas | Avisos de privacidad claros, interfaz renovada | Es probable que persistan los rechazos heredados | Los rechazos del SDK compartido afectan a todos los clientes |
| Migración del catálogo y los datos | Menú + fidelización conservados intactos | Atrapado en el esquema antiguo | Remodelado al esquema del proveedor |
| Propiedad a largo plazo | El cliente es dueño de todo el código fuente y de la hoja de ruta | Se hereda código frágil y la deuda se acumula | Atado a los precios y a la hoja de ruta del proveedor |
Referencias de la plataforma: documentación de Apple StoreKit y de pagos dentro de la app, referencia de Google Play Billing, PCI Security Standards Council.
El cliente de iOS está construido en Swift, y lo primero que simplificamos fue el flujo de registro. Las apps heredadas pedían demasiado antes de que un cliente pudiera ver un precio; el flujo reconstruido se abre con un único campo de número de teléfono con teclado numérico y el consentimiento del acuerdo de usuario integrado, de modo que un comprador nuevo está a un código por SMS de empezar a explorar. A partir de ahí, el catálogo se abre con los combos de menú del día de la cadena —los artículos de mayor margen y más rápida rotación—, seguidos de ensaladas, platos de pescado, sopas y guarniciones, cada uno con una miniatura, un precio y un selector de cantidad que escribe directamente en el carrito sin una ventana modal a pantalla completa de por medio.
El catálogo se alimenta de datos desde el backend de Laravel, de modo que el equipo de operaciones cambia precios, sustituye el menú del día y activa o desactiva la disponibilidad por local sin publicar una versión de la app. El mensaje centrado en la recogida está integrado en la pantalla de inicio —una dirección de entrega y un control «indicar hora de recogida» se sitúan sobre el catálogo— y la incorporación fija la expectativa de que un pedido fresco de granja está listo en unos 40 minutos. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de ingeniería para iOS y Android, de modo que el modelo de catálogo, el cálculo del carrito y las reglas de fidelización se comportan igual en ambas plataformas.
El cliente de Android está escrito en Kotlin y comparte con iOS el modelo de carrito y de pedido a través del backend de Laravel. La cesta es donde una app de comida se gana la confianza: las líneas se agrupan, cada una lleva su propio cargo por envase cuando el menú lo exige y el total se recalcula al instante al cambiar los selectores, sin spinner ni viaje de ida y vuelta por cada pulsación, porque las reglas de precios se replican en el cliente y solo se concilian con el servidor al pagar. Ese patrón de replicar y luego conciliar es lo que eliminó los errores de cálculo del carrito que afectaban a la versión heredada, en la que el total mostrado y el total cobrado podían desajustarse.
El pago reúne tres decisiones en una sola pantalla: el lugar de recogida, un comentario opcional al pedido y una hora de recogida que el cliente puede desplazar, con la app mostrando la estimación realista de «listo en unos 40 minutos» en lugar de prometer un hueco imposible. El interruptor de fidelización también está aquí: el cliente puede aplicar bonificaciones para obtener un descuento de hasta el 30 % del total del pedido, y el descuento se calcula en el servidor para que la cifra que ve el cliente sea la que ven la cocina y el equipo de finanzas. Construir el carrito y el pago sobre una base limpia es el tipo de desarrollo de software a medida que se amortiza la primera semana en que una cadena deja de perder pedidos en el paso del pago.
La reconstrucción del pago fue el corazón del proyecto. Sustituimos la conexión defectuosa con las wallets por una integración directa de adquirencia con tarjeta que gestiona el backend, compatible con un cargo único y con una vía recurrente con token para que un cliente que vuelve repita el pedido sin reintroducir los datos de la tarjeta. La aplicación nunca almacena un número de tarjeta: el proveedor de adquirencia devuelve un token opaco que se asocia al registro del cliente, y cada cargo se ejecuta contra ese token con un tratamiento alineado con PCI DSS. Los webhooks de liquidación confirman que el dinero ha llegado antes de pasar el pedido a la cocina, las claves de idempotencia hacen seguros los reintentos para que una red inestable nunca produzca un doble cobro y los reembolsos se concilian contra el mismo token, de modo que el panel del operador nunca discrepa de la realidad. La confirmación «su pedido se ha pagado correctamente» solo se muestra cuando el webhook se ha resuelto, no de forma optimista.
En el plano de los datos, la reconstrucción se estructuró desde el principio para públicos de EE. UU. y la UE. Los datos personales se reducen al número de teléfono y al historial de pedidos que realmente necesita un pedido para recoger; el saldo de fidelización es un libro mayor de solo anexado y no un campo modificable; y el consentimiento se recoge de forma explícita en el registro. El enfoque se alinea con las obligaciones del RGPD para usuarios de la Unión Europea y las de la CCPA / CPRA para 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.
Una reconstrucción en cinco fases que llevó a Vilka-Lozhka desde una app heredada defectuosa hasta una versión estable y aprobada en las tiendas en iOS, Android y un backend de pedidos limpio.
Catalogación de los errores críticos heredados, mapeo de la vía de pago defectuosa, delimitación del catálogo y de los datos de fidelización que se conservarían y definición del enfoque RGPD + CCPA para públicos de EE. UU. y la UE.
Backend limpio con Laravel + React, esquema del catálogo y del libro mayor de fidelización, diseño de la integración de adquirencia con cargos únicos y recurrentes con token y webhooks de liquidación idempotentes.
Cliente iOS en Swift y cliente Android en Kotlin con un único modelo de pedido: alta por teléfono, catálogo de combos, carrito en tiempo real, programación de la recogida e interruptor de canje de fidelización.
QA de pagos de principio a fin: prevención de doble cobro, conciliación de reembolsos, paridad del cálculo del carrito entre cliente y servidor y gestión de tokens alineada con PCI DSS bajo carga.
Envío a App Store y Google Play con interfaz renovada y avisos de privacidad en las tiendas de EE. UU. y la UE, seguido de una ventana de comentarios del operador y de estabilización.
El programa de fidelización fue el subsistema con el que más cuidado tuvimos, porque una cadena de restaurantes vive o muere según que la cifra que ve un cliente al pagar coincida con la que ven la cocina y el equipo de finanzas en el back office. Construimos el saldo como un libro mayor de solo anexado y no como un contador modificable: los puntos solo se acumulan en pedidos liquidados, los canjes tienen un tope por pedido como regla de negocio —un descuento de hasta el 30 % del total del pedido— y cada acumulación o gasto es una entrada del libro mayor que el panel del operador lee directamente. Ese diseño hace auditables las disputas y permite a la cadena lanzar promociones sin corromper los saldos históricos, porque una promoción es simplemente una nueva regla de acumulación superpuesta al mismo historial inmutable. El back office del operador lee la misma fuente única de verdad que la app, de modo que un responsable que cuadra la caja nunca tiene que adivinar qué sistema manda. Todo el subsistema se construyó para ser extensible: añadir un nivel de fidelización multilocal, una bonificación por recomendación o un programa de cuentas corporativas es un cambio de configuración en el libro mayor y en el servicio de derechos de acceso y no una publicación del cliente, lo que mantiene a la cadena fuera de la rueda de revisiones de App Store y Google Play para los cambios de marketing rutinarios.
Las apps de Vilka-Lozhka se construyeron para publicarse en Apple App Store y Google Play con tiendas activas en Estados Unidos y la Unión Europea desde una única base de código. La misma versión atiende a compradores 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 app 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 cualquier analítica de producto opcional, mientras que 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. Como la app reduce los datos personales a un número de teléfono y un historial de pedidos, el cumplimiento regional se reduce a una divulgación honesta y no a una segregación de datos por jurisdicción.
Los pagos y la adquirencia fueron el área que más reforzamos para un despliegue entre mercados: la capa de adquirencia con token abstrae al proveedor tras una única interfaz, de modo que cambiar o añadir un adquirente regional para EE. UU. o la UE es un cambio de configuración del backend y no una reconstrucción del cliente. Tanto la clasificación por edad de App Store como la clasificación de contenido de Google Play se calibraron para un conjunto de funciones de pedido de comida con pagos, y en la política de privacidad dentro de la app se citan directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja en CET y mantiene 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 a incidencias: la franja horaria que permite a un equipo de producto estadounidense y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida de Vilka-Lozhka incluye un modo de reparto con despacho de repartidores junto al flujo actual de recogida, un nivel de fidelización multilocal con cuentas corporativas, avisos de repetición de pedido por push vinculados al libro mayor de fidelización y una superficie web de pedidos que comparta el mismo backend de Laravel. Los planes de infraestructura incluyen añadir un segundo adquirente regional tras la interfaz de pago con token existente para cubrir EE. UU. y la UE, y una analítica más rica para el operador integrada en la hoja de ruta de cloud y DevOps para que la cadena pueda ver casi en tiempo real el tamaño de la cesta, la tasa de canje y la precisión de la hora de recogida por local.
Si está planificando una app de pedidos para un restaurante o QSR, sustituir una integración de pagos defectuosa o reconstruir una app de comida heredada que ha dejado de convertir al pagar 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 caso completo está documentado en yusmpgroup.com/cases/vilka-losja (iOS y Android), y 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 de pedidos de una cadena de restaurantes con clientes nativos de iOS y Android, un catálogo de combos, un carrito en tiempo real, un proveedor de adquirencia y programación de la recogida suele costar entre $90k y $200k. Añadir un programa de fidelización, facturación recurrente, soporte multilocal, integraciones con cocina y operadores y analítica lleva un producto completo a $220k–$450k. Los principales factores de coste son la integración de pagos y adquirencia, la lógica de fidelización y de derechos de acceso, y mantener en paralelo dos clientes nativos en iOS y Android.
Las apps heredadas de pedidos de comida suelen fallar primero en la vía de pago y en el cálculo del carrito, y son los lugares más difíciles de parchear con seguridad porque cada corrección arriesga un doble cobro o la pérdida de un pedido. Cuando la integración de adquirencia está rota y la base de código ha acumulado errores críticos, una reconstrucción disciplinada sobre un backend limpio en Laravel con clientes nativos en Swift y Kotlin llega antes a una versión estable y aprobada en las tiendas que perseguir regresiones por código antiguo. Conservamos el catálogo y los datos de fidelización mientras reescribíamos desde cero el flujo de pedidos y pagos.
La adquirencia con tarjeta de una app de comida necesita tanto cargos únicos como una vía recurrente con token para que los clientes que vuelven puedan repetir el pedido sin reintroducir los datos de la tarjeta. La app nunca almacena el número completo de la tarjeta: el proveedor de adquirencia devuelve un token opaco que se asocia al registro del cliente, y el backend cobra contra ese token con un tratamiento alineado con PCI DSS. Los webhooks confirman la liquidación antes de pasar el pedido a la cocina, las claves de idempotencia evitan cobros dobles en los reintentos y los reembolsos se concilian contra el mismo token para que el panel del operador siga siendo coherente.
Un programa de fidelización necesita una única fuente de verdad del saldo que lean tanto la app como el back office del operador, de modo que la cifra que ve el cliente al pagar coincida siempre con la que ven la cocina y el equipo de finanzas. Los puntos se acumulan solo en pedidos liquidados, los canjes tienen un tope por pedido como regla de negocio (aquí, un descuento de hasta el 30 % del total del pedido) y cada acumulación o gasto es una entrada de un libro mayor de solo anexado y no un contador modificable. Ese libro mayor hace auditables las disputas y permite a la cadena lanzar promociones sin corromper los saldos históricos.
Un MVP centrado en clientes nativos de iOS y Android, un catálogo de combos, un carrito en tiempo real, un proveedor de adquirencia y programación de la recogida suele tardar entre 10 y 16 semanas. Añadir un programa de fidelización, facturación recurrente, soporte multilocal e integraciones con operadores suma entre 6 y 10 semanas. La fase de aprobación en las tiendas —avisos de privacidad, revisión de las políticas de pago y la coreografía de envío a App Store y Google Play— suele subestimarse y conviene presupuestarla en 3–5 semanas de trabajo dedicado.
Casos relacionados
Una plataforma de reparto de comida con pedidos en tiempo real, despacho de repartidores y flujos de pago en EE. UU. y la UE.
Ver el caso →
Una experiencia de pedidos de restaurante con catálogo de menús, carrito y recogida: desarrollo móvil nativo para comensales de EE. UU. y la UE.
Ver el caso →
Un desarrollo de comercio minorista omnicanal con catálogo, carrito, fidelización y pagos en tiendas de EE. UU. y la UE.
Ver el caso →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Explorar el desarrollo de aplicaciones móviles →
Plataformas a medida diseñadas para su modelo de negocio, que escalan sin problemas desde el MVP hasta millones de usuarios.
Explorar el desarrollo de software a medida →
Infraestructura resiliente, CI/CD y observabilidad para que los flujos de pago y de pedidos sigan funcionando bajo carga.
Explorar cloud y DevOps →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.