FastFood
FastFood es una plataforma completa para pedir comida, construida alrededor de dos experiencias conectadas. Una app web de cliente permite descubrir restaurantes cercanos, recorrer las cartas con detalles y alérgenos de cada plato, montar un pedido en un carrito vivo y cerrarlo eligiendo el método de pago, y después seguir el pedido a lo largo de todo su recorrido, en tiempo real. Una consola de gestión permite al restaurante llevar su carta, hacer avanzar los pedidos entrantes por su cadena de estados y seguir el rendimiento en un panel de analítica. LilyByte diseñó y construyó el producto entero de principio a fin (frontend Next.js, API Express/MongoDB) como proyecto propio.
Los dos roles los mueve un solo sistema: un único modelo de cuenta con un interruptor cliente/restaurante, un mismo pedido que ambas partes ven y sobre el que pueden actuar, y un motor de descubrimiento consciente de la ubicación que ata las cartas a un mapa.
El reto
Un mercado para pedir comida son en realidad dos productos que tienen que darse la razón. Construir bien los dos, a la vez, era el reto central.
Dos públicos, un solo modelo de datos. El cliente quiere velocidad: encontrar algo bueno cerca y pedirlo en pocos toques. El restaurante quiere control y visión: llevar una carta, procesar los pedidos que entran y entender el negocio. A los dos los mueven los mismos restaurantes, cartas y pedidos.
Descubrimiento consciente de la ubicación. El descubrimiento solo se siente bien si respeta dónde estás y qué te gusta: consultas geoespaciales reales para los restaurantes cercanos a una dirección, junto a las preferencias de cocina y las restricciones por alérgenos.
Un ciclo de pedido compartido y en vivo. Un pedido pasa por los estados pedido, en preparación, listo o en reparto, y completado. El mismo registro alimenta la ventana de seguimiento del cliente y el tablero operativo del restaurante, así que el estado debe mantenerse coherente en ambos lados.
Un embudo de pedido completo. Desde el plato que se hojea hasta su ficha, luego el carrito vivo, luego la confirmación con los datos del pedido y el método de pago: todo el camino tenía que sentirse como una app de pedidos de verdad, no como un formulario.
Visión operativa. El restaurante necesitaba analítica de verdad (evolución de ingresos y pedidos, los platos que más y menos venden, comparaciones entre periodos) presentada con claridad.
La solución
FastFood une un frontend Next.js moderno con un backend geoespacial Express/MongoDB, unificados por una capa de autenticación consciente de los roles.
001
Un frontend Next.js consciente de los roles
El cliente está construido sobre Next.js 15 (App Router, Turbopack) con el sistema de componentes HeroUI y Tailwind CSS. Los grupos de rutas separan la app del cliente de la consola del restaurante, y una guarda de autenticación lleva a cada usuario a la superficie correcta. Chart.js mueve la analítica, y el estado del carrito y del pedido se lleva con el context de React, así el flujo sobrevive a todo el proceso de compra.
002
Una API geoespacial de pedidos
El backend es una API REST Express 5 sobre MongoDB vía Mongoose, protegida con JWT (bcrypt), validada con Joi, documentada con Swagger y con las imágenes de las cartas gestionadas por Multer. El descubrimiento se apoya en índices 2dsphere de MongoDB y en tuberías $geoNear que ordenan los restaurantes por distancia y filtran los platos por cocina y alérgenos; Nominatim de OpenStreetMap geocodifica las direcciones y OSRM estima los tiempos de reparto.
003
Un ciclo de pedido, dos vistas
Una sola colección de pedidos es la espina dorsal de la app: alimenta la ventana de estado en vivo del cliente, el tablero de gestión del restaurante y las agregaciones del panel para ingresos, número de pedidos, evolución de ventas y popularidad de los productos.
Funciones clave
Autenticación y roles
Un único registro con un interruptor Usuario/Restaurante lleva a cada persona a la experiencia correcta; las sesiones usan JWT.
Descubrimiento y búsqueda
El inicio se personaliza por gusto y ubicación; una página de búsqueda dedicada añade un carrusel de categorías, preferencias de cocina, exclusión de alérgenos y un filtro «abierto ahora» sobre el orden geoespacial.
El recorrido del pedido
El corazón de la app de cliente es un embudo de pedido completo. Desde la página de un restaurante, un plato abre una ficha con foto, etiquetas, alérgenos e ingredientes; al añadir platos se llena un carrito vivo con cantidades y total corriente; y la confirmación recoge los datos del pedido y el método de pago antes de enviarlo.
Seguimiento del pedido
El cliente sigue cada pedido a lo largo de su recorrido en una ventana de estado en tiempo real (de «Esperando confirmación» a «Preparando tu pedido», «Listo para recoger» y «Completado») con el pedido detallado y su avance. El restaurante hace avanzar ese mismo pedido desde su consola.
Área del cliente
El cliente gestiona su perfil, las direcciones de reparto y las tarjetas guardadas desde un área propia.
Consola del restaurante: panel de analítica
El panel del gestor convierte el flujo de pedidos en visión: tarjetas de indicadores para pedidos e ingresos (hoy, semana, mes, con diferencias respecto al periodo anterior y ticket medio), un gráfico configurable de evolución de ventas, una tabla de los platos que más y menos venden, y un flujo en vivo de pedidos recientes.
Consola del restaurante: carta y pedidos
El restaurante lleva su catálogo con la gestión completa de platos (añadiendo uno nuevo o eligiendo uno existente) y trabaja los pedidos entrantes en un tablero con búsqueda y paginación, haciendo avanzar el estado de cada uno desde una ventana.
Tecnologías
001
Frontend
- Next.js 15: App Router with Turbopack; role-based route groups and an auth guard
- React 18 + TypeScript
- HeroUI component system + Tailwind CSS for a consistent, responsive design
- Chart.js analytics · Framer Motion · react-beautiful-dnd · Axios · js-cookie
- React context for cart & auth state that persists across the ordering flow
002
Backend y API
- Node.js with Express 5: REST API
- MongoDB with Mongoose ODM
- JWT authentication with bcrypt-hashed credentials; role-based access
- Joi validation · Multer image uploads · Swagger (OpenAPI) docs
003
Geoespacial y datos
- MongoDB 2dsphere indexes and $geoNear aggregation for “near me” discovery
- Preference- and allergen-aware feeds and search via aggregation pipelines
- OpenStreetMap Nominatim geocoding + OSRM routing for delivery-time estimates
- Server-side analytics aggregations for revenue, orders and product trends
Áreas de trabajo
El trabajo cubrió todo el ciclo de vida del producto, en estos frentes:
001
Diseño de producto — flujos e interfaz para dos roles bajo un solo sistema de diseño.
002
Ingeniería frontend — cliente Next.js, recorrido de pedido con estado y visualización de datos.
003
Backend y API — servicios REST en Express, validación y documentación.
004
Datos y geoespacial — esquema MongoDB, índices 2dsphere y agregaciones.
005
Auth y seguridad — sesiones JWT, hash de contraseñas y enrutado por rol.
006
DevOps y despliegue — plan de puesta en producción (abajo).
Producción y escala (previstas)
FastFood es un prototipo completo de funciones que todavía no se ha publicado. A continuación, el camino previsto hacia producción y los objetivos fijados para él.
001
Arquitectura de despliegue
El frontend se publicaría en Vercel con caché en el borde y optimización de imágenes, mientras que la API Express correría como servicio en contenedor (Render / Fly.io / AWS ECS) detrás de un balanceador. Los datos pasarían a MongoDB Atlas conservando los índices geoespaciales, con copias automáticas; las imágenes de las cartas se servirían desde almacenamiento de objetos (S3) a través de una CDN (CloudFront) en lugar de la carpeta local. Una tubería de GitHub Actions se encargaría de CI/CD, y el stack quedaría instrumentado con registro estructurado, seguimiento de errores (Sentry) y monitorización de disponibilidad.
002
Endurecimiento para tráfico real
Antes del lanzamiento la plataforma añadiría limitación de peticiones y saneamiento de entradas en el borde de la API, cookies de sesión seguras y no legibles desde JavaScript, moderación de las imágenes subidas, una confirmación de pedido idempotente apoyada en un proveedor de pagos real (Stripe), y avisos push y por correo en los cambios de estado. Una caché Redis se pondría delante de las consultas de descubrimiento más frecuentes, y la cadena de pedidos pasaría a websockets para actualizaciones realmente en vivo en ambos lados.
Objetivos previstos
Los objetivos de la puesta en producción se plantearon como metas concretas, no como resultados medidos:
~50
Restaurantes en el lanzamiento
Incorporar un primer grupo de unos 50 restaurantes asociados en una sola ciudad, en el lanzamiento.
<300ms
Respuesta de la búsqueda geoespacial
Tiempo de respuesta mediano por debajo de 300 ms en las consultas de descubrimiento geoespacial con carga nominal.
100s
Sesiones simultáneas por instancia
Aguantar cientos de sesiones de pedido simultáneas en una sola instancia de la API antes de crecer en horizontal.
99.9%
Disponibilidad, con vuelta atrás automática
99,9% de disponibilidad prevista, con copias automáticas y vuelta atrás en un clic.
<24h
Del registro al primer pedido
Embudo del restaurante: del registro a la primera carta publicada y al primer pedido procesado en menos de un día.
~50
Restaurantes en el lanzamiento
Incorporar un primer grupo de unos 50 restaurantes asociados en una sola ciudad, en el lanzamiento.
<300ms
Respuesta de la búsqueda geoespacial
Tiempo de respuesta mediano por debajo de 300 ms en las consultas de descubrimiento geoespacial con carga nominal.
100s
Sesiones simultáneas por instancia
Aguantar cientos de sesiones de pedido simultáneas en una sola instancia de la API antes de crecer en horizontal.
99.9%
Disponibilidad, con vuelta atrás automática
99,9% de disponibilidad prevista, con copias automáticas y vuelta atrás en un clic.
<24h
Del registro al primer pedido
Embudo del restaurante: del registro a la primera carta publicada y al primer pedido procesado en menos de un día.
Nota: este proyecto no se ha publicado en producción; la arquitectura de despliegue y las cifras de esta sección son la instalación prevista y los objetivos fijados, no resultados medidos.
Siguientes proyectos
FantaGraal
Una app de fantasy football que une los datos en directo con una gestión profunda
PayWise
Una plataforma multi-tenant de nóminas y gestión de personal para una asesoría laboral
FantaGraal
Una app de fantasy football que une los datos en directo con una gestión profunda
PayWise
Una plataforma multi-tenant de nóminas y gestión de personal para una asesoría laboral