El problema: En aplicaciones financieras y de reservas, confiar en la lógica del cliente (Flutter) expone el sistema a manipulación de precios, inyección de datos o brechas de privacidad entre usuarios.

La solución: Arquitectura "Confianza Cero". Se bloqueó toda escritura crítica en la base de datos mediante Firestore Rules inquebrantables. Transacciones complejas (pagos, deducción de aforo o reembolsos) se delegan exclusivamente a middlewares robustos en Node.js (Cloud Functions). El backend verifica criptográficamente cada intento, garantizando seguridad fintech/bancaria y privacidad estricta (GDPR) sin exponer jamás claves API en la app.

El problema: Cobrar centralmente a los alumnos para luego transferir a los centros crea un cuello de botella fiscal, legal y contable enorme. Por otro lado, la barrera de adopción en software B2B es altísima si se exige pago desde el día uno.

La solución: Orquestación financiera descentralizada. Se implementó Stripe Connect para que el dinero B2C fluya directo a las cuentas de los centros (delegando a ellos la responsabilidad fiscal). Simultáneamente, se integró Stripe Billing para administrar las suscripciones de los estudios (SaaS), inyectando lógicas agresivas de adopción comercial como "Trials" de 60 días y precios dinámicos para los primeros clientes ("City Pioneers"). Esto permite escalar a cientos de centros sin saturar la contabilidad de Ayogis.

El problema: Firebase NoSQL carece de relaciones estrictas, por lo que reservas concurrentes o cancelaciones masivas corrompen el aforo (maxAttendees). Además, cruzar permisos en reglas de seguridad para datos anidados es propenso a fugas de datos y encarece la lectura en la nube.

La solución: Se implementó un patrón de "Escritura Sincronizada" (Dual-Write). El backend actúa como guardián único que duplica y aísla atómicamente las reservas: una vista para el cliente y otra para el centro. Esto protege el maxAttendees con transacciones contra carreras de datos, elimina complejas dependencias en las Reglas de Seguridad y reduce agresivamente los costos de lectura mensual.

El problema: Apple y Google imponen estrictamente un 30% de peaje sobre pagos in-app digitales. A nivel operativo, si un estudio cancela una clase, el soporte manual para reembolsar individualmente a docenas de alumnos colapsaría al equipo.

La solución: Arquitectura limpiamente desacoplada en dos apps (B2C fluida vs B2B analítica). Logramos argumentar frente a los revisores de Apple/Google que el código intermedia compras de servicios físicos presenciales, evadiendo el peaje del 30% legalmente. Operativamente, al cancelar una clase en el B2B, un worker distingue pagos de banco frente a pases internos, ejecutando reembolsos en Stripe de manera 100% desatendida y automática.