El núcleo, resuelto
Pedidos con máquina de estados en base de datos, idempotencia, pagos con captura al entregar y aislamiento entre marcas a nivel de PostgreSQL.
Código fuente y documentación · multi-tenant
Plataforma white-label de delivery,sin empezar de cero.
Código fuente y documentación de una plataforma de delivery lista para adaptar a tu marca: backend, panel de administración y app de cliente para Android. Para operadores, franquicias y emprendedores que quieren lanzar su propio servicio.
- Código fuente
- Plataforma white-label
- Documentación
- Alcance sin letra pequeña
«Aurea» es el nombre de trabajo de la demostración. La marca no forma parte de la venta: tú pones la tuya.
- 163tests de la API, unitarios e integración
- 207tests unitarios de la app Android
- 68tests de la lógica de iOS
- 43operaciones en el contrato OpenAPI
La oportunidad
Lanzar tu app de delivery sin empezar de cero
Construir desde cero el backend, el aislamiento entre marcas, los pagos, una carta con alérgenos, un panel y una app móvil es un proyecto largo. Esta plataforma te entrega ese núcleo ya hecho y probado, para que dediques tu esfuerzo a lo que sí es tuyo: tu marca, tus restaurantes y tu operación.
Tu marca, no la nuestra
Cada tenant configura su marca, idiomas, moneda, impuestos y modelo de flota sin tocar código. El tenant de demostración es solo un ejemplo.
Sabes lo que compras
Cada pieza viene con su estado verificado y sus huecos documentados. Lo que no existe está dicho, y más abajo.
Qué incluye
Un producto completo en su núcleo
Un monorepo con todo lo necesario para arrancar en local en unos 30 minutos y seguir desarrollando.
Backend y API
NestJS, PostgreSQL con PostGIS y un worker con outbox. Login OIDC por tenant, con doble factor obligatorio para el personal.
43 operaciones OpenAPIPanel de administración
Resumen, pedidos, locales y cartas con alérgenos, editor de marca con contraste WCAG en vivo, ajustes y módulos.
Next.jsApp Android del cliente
Login, restaurantes, carta con alérgenos, carrito, dirección, checkout y seguimiento de pedidos, en español e inglés.
Kotlin · ComposePagos con Stripe
PaymentIntent con captura manual al entregar y sincronización del pago por si el webhook se retrasa. Probado con un doble del SDK; no con Stripe real. Stripe Connect está en el diseño, no implementado.
Modo de pruebaMulti-tenant y marca blanca
Marca, dominios, moneda, impuestos, zonas, módulos y modelo de flota (plantilla o flota independiente) como datos. Dos tenants de demostración incluidos.
RLS en PostgreSQLTests y CI
Tests de la API validados contra el contrato, oasdiff contra cambios incompatibles, gitleaks, OSV y política de licencias en cada cambio.
GitHub ActionsLógica de iOS
Sesión, catálogo, carrito, checkout, pago y pedidos portados de Android, probados en Linux contra respuestas reales de la API. Sin pantallas.
68 testsGuías de despliegue y publicación
Guía del comprador, de despliegue, de publicación en Google Play y en App Store (escritas, no ejecutadas) y de Stripe en modo de prueba.
En españolQué es cada cosa y hasta dónde llega está en la sección «Alcance». Lo que figura aquí funciona con datos de demostración.
La app en acción
Así se ve la app de cliente
Capturas de un recorrido real grabado en un emulador de Android, con el tenant de demostración y un proveedor de pago simulado. Desplázate y la pantalla cambia.
Acceso
Login y registro contra el proveedor de identidad de cada marca (OIDC). En la demo, contra el IdP de desarrollo.
Restaurantes
Lista con el estado «abierto» o «cerrado» escrito en texto, nunca solo con color.
Carta y aviso de alérgenos
Categorías y platos, con el alérgeno en palabras y un aviso fijo de que la declaración es del restaurante.
Plato, opciones y alérgenos
Tamaños y extras con mínimos y máximos. «Contiene» y «Puede contener» a la vista antes de añadir.
Carrito
Un solo restaurante a la vez, notas por plato y subtotal. Cambiar de restaurante pide confirmar el vaciado.
Checkout
Totales calculados por la API. Antes de pagar se reconcilian precio, alérgenos y platos retirados.
Pago
En la demo, un proveedor de pago simulado. Stripe PaymentSheet está integrado, sin probar con tarjeta real.
La plataforma en 38 segundos
Un recorrido por la app de cliente: acceso, restaurantes, carta con alérgenos, personalización del plato, carrito, total y pago simulado.
Vídeo promocional con la app grabada en un emulador de Android, con datos ficticios y pago simulado. No es un teléfono real. Se carga solo al reproducirlo. (1,6 MB)
Diferenciador
Alérgenos y cumplimiento, de serie en el diseño
Los alérgenos no son un campo opcional: son parte del modelo de datos y de la interfaz.
- Sin declaración, no se publicaLa API rechaza publicar un plato u opción sin su declaración completa de alérgenos (error 422).
- Siempre en palabras«Contiene» y «Puede contener» en texto, nunca solo con color. Si no cargan los nombres, se muestran los códigos y se avisa; la declaración nunca se oculta.
- Reconciliación al pagarEl checkout compara precio, alérgenos y platos retirados con la carta actual, y el cliente acepta los cambios antes de pagar.
- Régimen por tenantEl régimen de alérgenos de cada país es configuración del tenant, no código.
La plataforma no afirma cumplir ninguna normativa. Permite configurar estas decisiones; validarlas con tus asesores en cada país donde operes es responsabilidad del operador.
Margherita
11,00 €Tomate San Marzano, fior di latte y albahaca
Contiene: cereales con gluten, leche
Puede contener: mostaza
La información de alérgenos la declara el restaurante. Si tienes una alergia grave, consúltalo antes de pedir.
Arquitectura y calidad
Pensado para que un comprador lo audite
Un monolito modular con aislamiento entre marcas en la propia base de datos y una cadena de comprobaciones en cada cambio.
- 14 migracionesReversibles, comprobadas de subida, bajada y subida.
- 90 políticas RLSEl aislamiento entre tenants vive en PostgreSQL y se probó con PostGIS real.
- Contrato como fuente de verdadCada respuesta de los tests se valida contra el OpenAPI; oasdiff frena los cambios incompatibles.
- Clientes generadosTypeScript, Kotlin y Swift, generados del contrato.
- Sin secretos ni vulnerabilidades conocidasgitleaks sobre todo el historial y OSV-Scanner en CI.
- Licencias controladasPolítica de licencias aplicada en CI, con inventario de terceros.
Transparencia
Qué no incluye
Lo decimos antes de que lo preguntes. Esto es lo que no hay y lo que no se ha probado.
- iOS sin interfazSolo existe la lógica (con 68 tests en Linux). Sin pantallas SwiftUI y sin compilar con Xcode.
- Sin apps de restaurante ni de repartidorLas apps de restaurante (Partner) y de repartidor (Rider) no existen.
- Sin usuarios ni ingresosTodo se ha probado con datos de demostración. No hay clientes, pedidos reales ni facturación.
- Sin despliegue en producciónNo hay infraestructura desplegada ni como código, ni apps publicadas, ni cuentas de tienda, de Stripe o de identidad.
- Pagos sin probar en realNi con Stripe real, ni con su webhook, ni con tarjeta en la hoja de pago. Stripe Connect no está implementado.
- Android sin probar en un teléfonoCompila y pasa sus tests y seis flujos en un emulador; nadie la ha usado en un móvil real ni con lector de pantalla.
- Sin seguimiento en vivo ni notificacionesLas apps consultan el estado cada 20 segundos. No hay push, correo ni SMS.
- Sin textos legalesLos documentos de la semilla están vacíos y las decisiones legales y laborales son del operador.
La lista completa y detallada está en la documentación que recibes (resumen para el operador y huecos conocidos).
Hoja de ruta y desarrollo adicional
Lo que viene después
Estas fases están pendientes. No forman parte de la venta; pueden completarse como desarrollo adicional bajo acuerdo, con presupuesto aparte.
App iOS con interfaz SwiftUI
La lógica ya está hecha y probada (68 tests). Falta la interfaz y compilar y probar en Xcode.
Lógica hecha · interfaz pendienteApp de restaurante
App de restaurante (Partner), con recepción de pedidos en tiempo real.
PendienteApp de repartidor
App de repartidor (Rider), con asignación de pedidos y seguimiento, para los dos modelos de flota.
PendienteSeguimiento en vivo y notificaciones
Ubicación en tiempo real, push, correo y SMS.
PendientePanel de finanzas
Panel de administración completo y finanzas.
PendienteEndurecimiento
Seguridad, pruebas de carga, accesibilidad, observabilidad y una demo completa.
Pendiente
Sin fechas ni precios aquí: se acuerdan caso por caso. Nada de esta sección está incluido en la venta.
Consultar desarrollo adicionalLa transferencia
Qué recibe el comprador
Recibes
- El monorepo completo: API, worker, panel, app Android, lógica iOS, contrato OpenAPI, clientes generados, migraciones y semilla de demostración.
- La documentación: arquitectura, decisiones de diseño, guía del comprador, guía de despliegue, publicación en tiendas, Stripe en modo de prueba, huecos conocidos y decisiones legales pendientes.
- La CI de GitHub Actions ya escrita, con las comprobaciones de calidad y seguridad.
No recibes
- La marca de la demostración: es solo un nombre de trabajo y no forma parte de la venta.
- Infraestructura desplegada ni cuentas de ningún proveedor.
- Apps publicadas ni cuentas de Apple o Google.
- Textos legales ni asesoramiento jurídico.
- Usuarios, ingresos ni contratos con restaurantes.
Cómo es la transferencia
Los términos concretos se cierran en el contrato de venta: titularidad y cesión del código (incluido el generado con herramientas de IA) y las licencias de terceros. Después, el camino documentado es este:
- Arrancar el entorno de demostración en local, unos 30 minutos con Docker.
- Elegir infraestructura y montar el despliegue siguiendo la guía.
- Crear tus cuentas: Stripe, Apple Developer, Google Play y tu proveedor de identidad.
- Escribir los textos legales con tus asesores y validar las decisiones pendientes.
- Dar de alta tu tenant, ajustar tu marca y cargar tu carta.
- Compilar, firmar y probar las apps, y hacer un pago real de importe mínimo.
Preguntas frecuentes
Lo que suelen preguntar
¿Funciona ya con clientes reales?
No. No hay usuarios, pedidos reales ni ingresos. Todo se ha probado con datos de demostración. Es la base para que tú lances el servicio.
¿Puedo ponerlo en producción mañana?
No. Necesitas infraestructura, cuentas de Stripe, Apple, Google y de identidad, textos legales y probar las apps con tus cuentas. La guía del comprador lista los pasos.
¿Qué pasa con iOS?
La lógica de iOS está hecha y probada en Linux (68 tests), pero no hay pantallas SwiftUI ni se ha compilado con Xcode. Completarlo es desarrollo adicional.
¿Se vende la marca «Aurea»?
No. «Aurea» es el nombre de trabajo de la demostración y no forma parte de la venta. Recibes el código fuente y la documentación; tú eliges, compruebas y registras tu propia marca.
¿Puedo cambiar la marca?
La marca de cada tenant (colores, nombre, tipografías) se edita en el panel, con contraste WCAG comprobado. La app de Android todavía no lee esa marca: sus colores, nombre e icono se cambian a mano en el código.
¿Cumple el RGPD o la normativa laboral?
La plataforma no afirma cumplir ninguna normativa. Permite configurar las decisiones, y el operador debe validarlas con sus asesores. En España y la UE, el modelo de flota independiente tiene un riesgo alto de recalificación laboral y exige un dictamen previo.
¿Qué tecnologías usa?
NestJS, PostgreSQL con PostGIS, Next.js, Kotlin con Jetpack Compose, Swift para la lógica de iOS y OpenAPI 3.1. Todo con licencias permisivas controladas en CI.
¿Puedo encargar lo que falta?
Sí, como desarrollo adicional bajo acuerdo y con presupuesto aparte: iOS, apps de restaurante y repartidor, seguimiento en vivo, finanzas y endurecimiento.
Contacto
Hablemos
Cuéntanos quién eres y qué buscas. Te respondemos con el alcance exacto y los siguientes pasos. Sin compromiso.
También por teléfono o WhatsApp: +34 614 622 559