Caso de éxito · Eventos y venta de entradas · Móvil
Caso de éxito Move2Armenia: cómo creamos una app nativa para iOS y Android para descubrir eventos, reservar plaza y comprar entradas con QR en Ereván y otras ciudades de Armenia. El producto atiende al mercado armenio; el desarrollo se diseñó con los estándares que espera nuestra base de clientes de EE. UU. y la UE, sobre un backend en Symfony y React y con clientes móviles totalmente nativos publicados en App Store y Google Play.
El equipo de producto de Move2Armenia quería una app de eventos que ayudara a recién llegados y a vecinos de Ereván y otras ciudades de Armenia a encontrar algo que hacer esta noche y a reservarlo en un único flujo: sin pestaña de navegador, sin entrada en PDF, sin copiar y pegar la dirección de un local en una app de mapas. El listón de aceptación lo marcaban las apps de consumo de EE. UU. y la UE que el público ya tenía en el teléfono: un feed de eventos rápido con un carrusel de selección del editor, filtros de categoría y fecha que se sienten instantáneos, una página de detalle del evento que responde a «dónde, cuándo, cuánto cuesta y si está agotado», y una entrada dentro de la app que funciona en la puerta incluso con una conexión inestable. El cliente aportó una base de backend existente; nosotros nos encargamos del frontend en React y de los clientes nativos de iOS y Android, y YuSMP Group fue incorporada precisamente porque el equipo ya había lanzado esta clase de producto de consumo. El resultado es una app nativa, en servicio en App Store y Google Play, construida con los estándares de ingeniería y privacidad que esperan nuestros clientes de EE. UU. y la UE aunque el mercado del propio producto sea Armenia.
Un resumen de lo que aportó el desarrollo de Move2Armenia en iOS, Android y un backend en Symfony en su primer ciclo de producción. Las cifras son datos de entrega y rangos típicos, no métricas confidenciales del cliente.
La decisión sobre la plataforma condiciona todas las demás decisiones en una app de eventos de consumo. Creamos Move2Armenia como iOS nativo en Swift y Android nativo en Kotlin, con un backend Symfony compartido y un frontend web en React, en lugar de un único cascarón multiplataforma. Una app de eventos hace su trabajo más importante en la puerta del local, donde depende de la cámara, la cartera, las notificaciones push y una entrada QR que debe mostrarse incluso sin señal. Los clientes nativos ofrecen un acceso predecible a esas capacidades, un desplazamiento fluido en feeds largos y una vía de visualización de la entrada que no depende de que un webview sobreviva a una conexión caída. La contrapartida (dos bases de código en lugar de una) se compensa manteniendo toda la lógica de reservas, inventario y precios en el backend de Symfony para que los clientes sigan siendo ligeros.
Solo web se descartó pronto: una pestaña del navegador no puede mantener de forma fiable una entrada escaneable en un acceso, y los recordatorios push de «su evento empieza en una hora» son el bucle de interacción del que depende el producto. Un cascarón multiplataforma fue una decisión más ajustada, pero el feed de eventos largo y cargado de imágenes y el requisito de entrada sin conexión nos llevaron a lo nativo en ambas tiendas. Es el mismo equilibrio que recomendamos en nuestra práctica de desarrollo de aplicaciones móviles a clientes de EE. UU. y la UE que lanzan apps de consumo en App Store y Google Play.
| Criterio | Nativo (Move2Armenia) | Capa multiplataforma | Solo web / PWA |
|---|---|---|---|
| Entrada QR sin conexión en la puerta | Fiable: en caché, se muestra sin señal | Normalmente bien; depende del puente | Frágil: la pestaña se descarta y sin señal falla |
| Recordatorios push | APNs / FCM de primer nivel | Admitidos mediante plugins | Limitados, sobre todo en iOS |
| Rendimiento del desplazamiento en feeds largos | Reciclado nativo de listas: fluido | Bueno con ajustes | Entrecortado en dispositivos de gama baja |
| Acceso a cámara / cartera | API directas de la plataforma | Mediado por plugins | Limitado por el navegador |
| Lógica de negocio compartida | Centralizada en el backend de Symfony | Interfaz y backend compartidos | Solo backend |
| Presencia en App Store / Play | Apps de tienda de primer nivel | Apps de tienda mediante envoltorio | Sin ficha nativa en las tiendas |
| Acabado por plataforma | Total: idiomas propios de Swift / Kotlin | Reducido al mínimo común denominador | Limitado al navegador |
Referencias de la plataforma: documentación de Swift de Apple, guías de Kotlin para Android, documentación de Symfony.
El cliente de iOS está desarrollado en Swift, con la pantalla de inicio organizada en torno a un feed de eventos rápido: un campo de búsqueda, una tira horizontal de fechas, un desplegable de categorías y etiquetas, seguidos de un carrusel de selección del editor y una sección «recomendado para usted» impulsada por los intereses que el usuario elige durante el onboarding. El filtrado está diseñado para sentirse instantáneo: categoría y fecha reducen primero el feed sobre resultados almacenados en caché local y después se concilian con el backend en segundo plano, de modo que la lista nunca parpadea en blanco mientras hay una petición en curso. Las tarjetas de evento llevan una etiqueta de local y una insignia de agotado para que el usuario pueda clasificar de un vistazo antes de entrar.
La página de detalle del evento es donde el descubrimiento se convierte en intención: responde a las restricciones de edad, las condiciones especiales, la fecha y la hora aproximada, el coste y el local, y después condensa la decisión en una única acción de reservar. El flujo de reserva pasa al backend de Symfony, que reserva el inventario y procesa el pago antes de emitir la entrada. Las mismas pantallas forman parte de la ingeniería para iOS y Android que ejecutamos para clientes de EE. UU. y la UE, con las versiones de iOS y Android avanzando en paralelo para que una función llegue a ambas tiendas en la misma versión y no se desfase.
El cliente de Android está escrito en Kotlin y ofrece la misma superficie de funciones que iOS: feed, búsqueda, filtros, detalle del evento, reservas y la entrada QR universal. Tras una reserva correcta, la app emite una única entrada escaneable (un código QR vinculado a un ID de entrada opaco más el nombre del asistente) que el usuario muestra al personal en la puerta. La entrada se renderiza a partir de datos en caché, por lo que se muestra incluso cuando la conectividad del local es mala, y el backend registra el estado de canje para que una entrada no pueda reutilizarse una vez escaneada.
El calendario personal reúne los eventos reservados del usuario en una vista «mis eventos», agrupada por fecha y con recordatorios, de modo que la app se convierte en el único lugar donde gestionar a qué se asiste esta semana. Los intereses que el usuario selecciona en el onboarding alimentan tanto el carrusel de recomendaciones como un ajuste de ciudad (Ereván por defecto) que delimita el feed. Todo ello está respaldado por la capa de control de Symfony a través de nuestra práctica de desarrollo de software a medida, con las reglas de reserva, inventario y reembolso mantenidas en el servidor para que ambos clientes nativos sigan siendo ligeros y coherentes.
El backend es un servicio Symfony / PHP que gestiona el catálogo de eventos, la lógica de reservas e inventario, los flujos de pago y reembolso, y la emisión y el canje de entradas; un frontend web en React comparte esa superficie de API, y los dos clientes nativos consumen los mismos endpoints. La localización es de primer nivel: la primera pantalla que ve el usuario es un selector de idioma (armenio, inglés o ruso) y la elección se propaga al feed, al detalle del evento y a la entrada. Mantener las reglas de reserva y reembolso en el servidor permite a la app cambiar una política sin publicar un nuevo binario en ninguna de las dos tiendas.
Aunque el producto atiende al mercado armenio, diseñamos el modelo de datos con los estándares de privacidad que espera nuestra base de clientes de EE. UU. y la UE. Los datos personales se minimizan, los identificadores de las entradas son opacos y no están ligados en tránsito a un correo electrónico ni a un nombre de cuenta, y los flujos de consentimiento y eliminación están acotados para que la misma base de código pueda configurarse para satisfacer las obligaciones del RGPD en la Unión Europea y de la CCPA / CPRA en Estados Unidos cuando se reutilice la misma ingeniería para un lanzamiento en EE. UU. y la UE. Así, una futura revisión independiente de privacidad sigue siendo un ejercicio de documentación y no una reforma de la arquitectura.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo Agile en cinco fases que llevó a Move2Armenia desde la especificación del producto hasta producción en iOS, Android y un backend en Symfony, con el trabajo de descubrimiento y analítica adelantado para reducir las revisiones a mitad del desarrollo.
Aclarar de antemano las reglas de reserva, la política de reembolso, el flujo de validación de entradas y el modelo de feed y filtros. Esta pasada de analítica adelantada es la mejor palanca para mantener predecible el calendario para las partes interesadas de EE. UU. y la UE.
Definir el contrato del backend de Symfony para catálogo, reservas, inventario, pagos, reembolsos y emisión de entradas; acordar la API compartida que consumen el frontend web en React y ambos clientes nativos.
Cliente de iOS en Swift y cliente de Android en Kotlin construidos en paralelo: feed, búsqueda, filtros de categoría y fecha, detalle del evento, reservas dentro de la app, entrada QR y el calendario personal de eventos.
Localización en armenio, inglés y ruso en todas las superficies; QA de reservas, pagos, reembolsos y canje de entradas; pruebas de renderizado de entradas sin conexión para el escenario de la puerta del local.
Envío a App Store y Google Play, calibración de la ficha en las tiendas y una hoja de ruta con selección de asientos con mapas de locales, notificaciones push y un detalle más rico del organizador.
La capa de monetización de Move2Armenia se construyó para que una única fuente de verdad gobierne cada plaza. El backend de Symfony guarda el catálogo de eventos y el libro de inventario; cuando un usuario toca para reservar, el backend reserva la plaza, ejecuta el pago y solo entonces emite una entrada ligada a un ID de entrada opaco. Como el inventario reside en el servidor, las mismas reglas se aplican por igual al cliente de iOS, al cliente de Android y al frontend web en React: no hay ningún camino para que un cliente venda de más un evento. Los reembolsos pasan por el mismo libro: un reembolso devuelve el inventario al conjunto y anula la entrada, de modo que un QR reembolsado ya no puede canjearse en la puerta. Todo el subsistema se diseñó para poder ampliarse: añadir selección de asientos con mapas de locales, cupos gestionados por el organizador o un modelo de precios multiciudad es un cambio de configuración y de backend y no una reescritura de los clientes móviles, que es precisamente lo que mantuvo barato ejecutar la hoja de ruta posterior al lanzamiento y el patrón que reutilizamos para productos de eventos y comercio en toda nuestra base de clientes de EE. UU. y la UE.
El mercado propio de Move2Armenia es Armenia: los eventos, los locales y las ciudades son de Ereván y de más allá. Nuestro encargo, en cambio, se llevó con el estándar que esperan nuestros clientes de EE. UU. y la UE, y el desarrollo se estructuró para que el mismo stack pudiera impulsar un lanzamiento en Estados Unidos o en la Unión Europea sin reescribirlo. Cuando reutilizamos esta arquitectura para un producto de eventos de EE. UU. y la UE, la versión en inglés está lista para atender 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, desde una única base de código. Las prácticas de tratamiento de datos están diseñadas para alinearse 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, de modo que pasar de un mercado a muchos es un ejercicio de configuración y no de arquitectura.
Como la lógica de reservas y de venta de entradas está centralizada en el backend de Symfony y los datos personales se minimizan por diseño, el cumplimiento regional se reduce a una divulgación honesta y a un consentimiento por jurisdicción, en lugar de mantener una versión distinta por región. El equipo 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 equipo de producto estadounidense y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día. Documentamos el tratamiento de datos directamente frente a las obligaciones del RGPD y las obligaciones de la CCPA de California para que un despliegue en EE. UU. y la UE parta de un enfoque defendible.
La hoja de ruta activa de desarrollo de software a medida de Move2Armenia incluye un flujo de registro más refinado, selección de asientos mediante mapas interactivos de locales, notificaciones push de eventos próximos y recomendados, y perfiles más ricos de locales y organizadores. En el lado de la plataforma, están previstas una lógica de recomendación más profunda sobre el grafo de intereses del usuario y más ciudades armenias, con el subsistema de reservas e inventario ya estructurado para varias ciudades y cupos gestionados por el organizador. La hoja de ruta de infraestructura (observabilidad, automatización del despliegue y un camino hacia un despliegue del mismo stack en EE. UU. y la UE) está integrada en nuestra práctica de cloud y DevOps para que escalar el producto sea un cambio operativo y no un rediseño de la arquitectura.
Si está planificando una plataforma de eventos, un producto de reservas o cualquier app móvil en la que el pago dentro de la app y una entrada que tiene que funcionar en la puerta sean esenciales, 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 producto en servicio está disponible en move2.am para iOS y Android, y 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.
Un MVP de eventos y venta de entradas con clientes nativos de iOS y Android, un feed de eventos, búsqueda, filtros de categoría y fecha, detalle del evento, reservas dentro de la app y emisión de entradas con QR suele costar $90k–$220k. Añadir selección de asientos con mapas de locales, reembolsos, notificaciones push, paneles para organizadores y soporte multilingüe lleva un producto completo a $250k–$500k. Los principales factores de coste son la lógica de reservas e inventario, los flujos de pago y reembolso, y las versiones nativas de iOS y Android mantenidas en paralelo en cada lanzamiento.
Una app de eventos y venta de entradas vive en el bolsillo del usuario en la puerta del local, así que depende en gran medida de la cámara, la cartera, las notificaciones push y la visualización de entradas sin conexión. iOS nativo en Swift y Android nativo en Kotlin dan un acceso predecible a esas capacidades de la plataforma, un desplazamiento fluido en feeds de eventos largos y un renderizado fiable del QR incluso sin señal en la entrada. Un backend compartido en React y Symfony mantiene la lógica de negocio en un solo lugar mientras cada cliente sigue siendo totalmente nativo, que es el equilibrio que necesitaba Move2Armenia para una base de clientes de EE. UU. y la UE que publica en ambas tiendas.
Un usuario abre un evento, ve la clasificación por edades, el programa, el local y el precio, y toca para reservar. El backend de Symfony reserva el inventario, procesa el pago y emite una entrada ligada a un ID de entrada opaco. El cliente móvil renderiza ese ID como una entrada universal con QR que el usuario muestra en la puerta, donde el personal la escanea para validar el acceso. Las entradas se renderizan a partir de datos en caché, por lo que se muestran incluso sin conexión, y el backend registra el estado de canje para que una misma entrada no pueda reutilizarse una vez escaneada.
Un MVP acotado con feed de eventos, búsqueda, filtros, detalle del evento, reservas y venta de entradas con QR en ambas tiendas suele llevar de 12 a 20 semanas. Añadir selección de asientos con mapas de locales, reembolsos, herramientas para organizadores, notificaciones push y soporte multilingüe suma de 6 a 12 semanas. El trabajo previo de descubrimiento y analítica (aclarar las reglas de reserva, la política de reembolso y el flujo de validación de entradas antes de empezar a programar) es la mejor palanca para mantener predecible el calendario y reducir las revisiones a mitad del desarrollo.
Sí. Aunque Move2Armenia atiende al mercado armenio, nuestras prácticas de desarrollo se orientan a una base de clientes de EE. UU. y la UE, por lo que el modelo de datos está estructurado desde el primer día para el RGPD en la Unión Europea y para el mosaico de normas de la CCPA / CPRA en Estados Unidos. Los datos personales se minimizan, los ID de las entradas son opacos y los flujos de consentimiento y eliminación están acotados para que la misma base de código pueda configurarse por jurisdicción sin una versión distinta por región.
Casos relacionados
Una plataforma de reservas y alquiler con disponibilidad, programación y pago, creada para una base de clientes de EE. UU. y la UE.
Ver el caso →
Una app de consumo para reservar ocio con reserva de franjas, pagos y clientes nativos para iOS y Android.
Ver el caso →
Una app de movilidad con descubrimiento en mapa, pago dentro de la app y estado de los vehículos en tiempo real en 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 →
Automatización del despliegue, observabilidad e infraestructura escalable para productos de consumo.
Explorar cloud y DevOps →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.