Cómo crear un sistema de pedidos para restaurante con Next.js

Al final de esta guía sabrás cómo crear un sistema de pedidos online para un restaurante con Next.js: un sitio público para pedir, un panel de administración para la cocina y el dueño, y una API que guarda las reglas. Usamos la plantilla Food Studio como punto de partida y seguimos a un restaurante de ejemplo desde la primera instalación hasta el lanzamiento.

El objetivo es un plan que puedas seguir, no un recorrido por funciones. Verás qué hacer el primer día, qué ajustes importan antes de cobrar un pago real y qué errores cuestan más tiempo. Los mismos pasos sirven para un solo restaurante, para una marca de comida para llevar con varias cocinas o para un sitio que construyes para un cliente.

El encargo

Olive Street Kitchen es un pequeño restaurante mediterráneo de comida para llevar con dos cocinas, una en el casco antiguo y otra cerca de la estación. El dueño quiere que los clientes pidan desde el móvil, paguen online y sigan el pedido hasta que llegue. Esto es lo que tiene que hacer el proyecto:

• Mostrar una carta en la que el cliente pueda buscar y filtrar por categoría y dieta, con los alérgenos en cada plato.
• Vender un combo (un principal, un acompañamiento y una bebida) a un solo precio.
• Ofrecer entrega a domicilio y recogida, y aceptar una entrega solo si la dirección está en la zona de una cocina y esa cocina está abierta.
• Cobrar con tarjeta o PayPal sin que el restaurante maneje nunca números de tarjeta.
• Dar a las cocinas una cola de pedidos pagados, y ocultar los precios al personal de cocina.
• Funcionar en inglés y en árabe, con las páginas en árabe reflejadas de derecha a izquierda.
• Dejar que el dueño cambie la carta y la página de inicio sin pedir ayuda a un desarrollador.

Cómo cubre la plantilla el encargo

Necesidad	Dónde está	Qué usas
Carta con búsqueda y alérgenos	Sitio de pedidos	La página de la carta en /en/shop, y el editor de platos en el panel
Combo a un solo precio	Sitio y panel	La página del combo, y las secciones de oferta de combo y de armar menú de la página de inicio
Reglas de entrega por cocina	API y panel	Ajustes, Restaurante: cocinas, horarios, códigos postales de entrega, tarifas y pedido mínimo
Pago online	API	Claves y webhooks de Stripe o PayPal en el archivo .env de la API
Cola de cocina sin precios	Panel	Página de equipo, el rol de cocina asociado a una sola cocina
Inglés y árabe con RTL	Las tres apps	Rutas /en y /ar, las carpetas de mensajes, un editor de platos bilingüe
El dueño edita la página de inicio	Panel	Página de inicio, nueve secciones que activas, reordenas y editas

Antes de empezar: decisiones que tomar

La mayoría de los retrasos en un proyecto así vienen de decisiones que nadie tomó a tiempo. Resuelve estas antes de abrir una terminal.

• Qué paquete. Un paquete de una sola app necesita una API funcionando en algún sitio, así que elígelo solo si ya la tienes.
• Dónde se ejecuta. Necesitas un host de Node para tres apps, una base de datos (SQLite en un disco persistente, o MySQL) y un lugar para las subidas (una carpeta persistente o un bucket como Cloudflare R2).
• Qué idiomas. Cada plato se guarda en inglés y en árabe, así que alguien tiene que escribir o revisar cada nombre y descripción en árabe antes del lanzamiento.
• Qué proveedores de pago. Stripe, PayPal o ambos, con cuentas que pertenezcan al restaurante. Las propinas, las líneas de impuestos y el pago contra entrega no están incluidos.
• Cocinas y zonas de entrega. Cada cocina necesita una dirección, un horario, una zona horaria, un tiempo de preparación y sus códigos postales de entrega. Reúnelo todo en una sola hoja.
• Quién usa el panel. Decide quién es el dueño, quiénes son los gerentes y una cuenta de cocina por cada cocina.
• Cómo se entera el cliente de su pedido. No hay correos de confirmación de pedido, así que los clientes dependen de la página de seguimiento. Decide si eso basta durante el primer mes.

Paso a paso

Paso 1: Elige el paquete

Food Studio se vende como una plantilla full stack y también por piezas: el sitio de pedidos, el panel del personal y la API del backend. El sitio y el panel no tienen datos propios. Lo leen todo de la API, así que un paquete de sitio o de panel por sí solo necesita una API funcionando en algún lugar.

Para un restaurante nuevo, elige el paquete Full Stack. Incluye las tres apps, la configuración de la base de datos y el restaurante de demostración en una sola carpeta. Si un cliente ya tiene una API de confianza, o solo vas a reemplazar un front end, basta con un paquete suelto. Las piezas aparecen en las páginas del sitio de pedidos y del panel del personal.

Comprueba antes de seguir

Sabes nombrar el ZIP que descargaste y las apps que contiene. Si es solo un front end, sabes dónde se ejecutará su API.

Qué suele salir mal

Un front end suelto no muestra nada sin una API, porque ninguna de las dos apps guarda datos propios.

Paso 2: Ejecútalo en local con Docker

Instala Docker Desktop (o Docker Engine con Compose), descarga el ZIP desde Mis plantillas, descomprímelo y abre una terminal en la carpeta food-studio-full-stack. Luego arranca todo con un solo comando:

docker compose up --build

No hace falta configurar nada antes. La primera vez se construyen tres imágenes y se carga un restaurante de demostración, así que calcula unos minutos. Cuando termine, tendrás tres apps:

• El sitio de pedidos en http://localhost:3030 (el árabe en /ar).
• El panel del personal en http://localhost:3031.
• La API en http://localhost:8000, con todas las rutas bajo /api.

En esta captura del vídeo de instalación, fíjate en el único comando que arranca las tres apps juntas.

Si otro programa ya ocupa uno de esos puertos, pon un archivo .env junto a docker-compose.yml con SITE_PORT, ADMIN_PORT o API_PORT apuntando a un número libre y vuelve a ejecutar el comando. Las demás direcciones se ajustan solas.

Entra en el panel como dueño con owner@foodstudio.example y la contraseña FoodDemo2026!. La misma contraseña sirve para manager@foodstudio.example y kitchen@foodstudio.example. En el sitio, el cliente de demostración es sam@foodstudio.example. Son cuentas de demostración locales, así que cámbialas antes de publicar el sitio.

Dedica veinte minutos a probarlo como tres personas distintas: haz un pedido como invitado, avanza el pedido como dueño y luego abre la cuenta de cocina para ver lo poco que muestra.

Fíjate en cómo se abre un plato con su cantidad y sus instrucciones antes de entrar en el carrito.

Para detener las apps, pulsa Ctrl+C o ejecuta docker compose down. Tus datos se conservan en el volumen food-studio-data. Ten cuidado con docker compose down -v: también borra ese volumen, y el siguiente arranque carga un restaurante de demostración nuevo encima de todo lo que habías introducido.

Comprueba antes de seguir

Las tres direcciones responden, un pedido de invitado llega al panel y la cuenta de cocina no muestra precios.

Qué suele salir mal

Docker no está en marcha: abre Docker Desktop y vuelve a intentarlo. Un puerto ocupado corta el arranque con "address already in use": mueve la app con las variables de puerto de arriba. Un arranque que parece atascado suele estar todavía cargando los datos. Sin Docker, lo habitual es tener un Node.js antiguo (las apps esperan la versión 24 o superior) o Yarn 1.22 (ejecuta corepack enable).

Paso 3: Define los datos del negocio

Haz el nombre y el aspecto antes que la carta, para que todas las capturas posteriores muestren la marca real. Hay tres sitios importantes:

• storefront/src/config/brand.config.ts guarda los nombres (un valor en inglés y otro en árabe de cada uno), el dominio, los datos de contacto y los enlaces a redes sociales.
• storefront/src/styles/theme-variables.css guarda los colores, con un valor claro y uno oscuro para cada uno. Cambia --primaryColor y --heading-red y todas las páginas lo siguen. Comprueba que el texto sobre el nuevo color siga siendo legible en los dos temas.
• storefront/public/brand/ guarda los archivos del logotipo, uno por idioma y tema.

El nombre del restaurante, su eslogan y su contacto de soporte se guardan como ajustes, así que el dueño puede cambiarlos después desde la lista All settings by key del panel (Ajustes, y luego Restaurante). Abre también messages/legal: la política de privacidad y los términos de la descarga están escritos para un restaurante ficticio. Sustitúyelos antes del lanzamiento por textos que encajen con Olive Street Kitchen y con su país.

Comprueba antes de seguir

El nuevo nombre aparece en los títulos de las pestañas, en el pie de página y en los encabezados en los dos idiomas, y el texto sobre el color de tu marca sigue siendo legible en ambos temas (la documentación pide una relación de contraste de 4,5 a 1).

Qué suele salir mal

Un color cambiado solo en un tema, o texto en inglés reescrito sin la línea correspondiente en ar.json.

Paso 4: Añade las cocinas, los horarios y las tarifas

Las reglas de entrega son datos, no código. En el panel, abre Ajustes y la pestaña Restaurante. Para cada cocina defines la dirección, el horario de apertura y la zona horaria, el tiempo de preparación, los códigos postales a los que reparte y un punto en el mapa. La demostración tiene cuatro cocinas. Olive Street Kitchen se queda con dos, las edita para convertirlas en las cocinas del casco antiguo y de la estación, y desactiva las demás.

La misma pestaña contiene las tarifas de entrega y de recogida, además del pedido mínimo. La demostración parte de una tarifa de entrega de $2.99, recogida gratis y un mínimo de $10.00 para entregas, así que trátalos como valores de relleno para tus propias cifras. Mira también el reloj de servicio. La carga inicial usa el reloj Demo, que mantiene todas las cocinas abiertas a las 20:55 para que puedas probar a cualquier hora. Cámbialo a Real antes del lanzamiento, o a los clientes les dirán que estás abierto a las 3 de la madrugada.

Comprueba antes de seguir

Usa dos veces la búsqueda por código postal de la página de ubicaciones, una con un código postal que esté en la lista de una cocina y otra con uno que no esté en ninguna lista, y lee las dos respuestas.

Qué suele salir mal

El pago rechaza a un cliente porque dice que la cocina está cerrada o que la dirección de entrega queda fuera de la zona. La causa casi siempre son los datos: un código postal que falta, un horario en la zona horaria equivocada o una cesta por debajo del mínimo. Corrígelo en los ajustes de la cocina.

Paso 5: Crea la carta en dos idiomas

Abre Carta en el panel. Cada plato lleva su nombre, su texto y su lista de ingredientes en los dos idiomas, escritos uno junto al otro. Añade una categoría, un tiempo de preparación, alérgenos, etiquetas de dieta y fotos. Los extras y los tamaños son grupos de opciones: cada grupo tiene sus propias opciones, cada opción puede modificar el precio y tú defines cuántas debe y puede elegir el cliente. El stock opcional hace que el servidor rechace un pedido que no puede servir.

En nuestro ejemplo creamos primero unos cuantos platos claramente ficticios: un plato de cordero, un wrap de falafel, un entrante de hummus, una ensalada de acompañamiento y una limonada. Después montamos un combo con una opción de principal, de acompañamiento y de bebida. Un cliente que cambia por una opción más cara paga solo la diferencia. Termina abriendo la página de Inicio y eligiendo cuáles de las nueve secciones mostrar, en qué orden y con qué platos populares.

Fíjate en la opción que se ofrece para cada plato y en el precio que se muestra para el combo completo.

Comprueba antes de seguir

Abre un plato en inglés y en árabe, marca un plato como no disponible (sigue visible y lo indica) y pide el combo con un acompañamiento más caro para confirmar que solo se suma la diferencia.

Qué suele salir mal

Un plato que nunca aparece está sin publicar o archivado. Las fotos que no cargan apuntan a PUBLIC_MEDIA_URL, que la carga inicial escribe en la dirección de cada imagen, así que en un servidor defínelo antes de cargar los datos por primera vez.

Paso 6: Configura los pagos en modo de prueba

Si no hay ningún proveedor de pago configurado, el pago ofrece un pago de demostración integrado que se salta el dinero real y marca el pedido como pagado. Sirve para aprender el flujo y desaparece en cuanto se configura un proveedor real. Los clientes pagan en la página propia de Stripe o de PayPal, así que tu sitio nunca ve un número de tarjeta.

Para Stripe, pon una clave secreta de prueba (empieza por sk_test_) en el archivo back-end/.env de la API y añade en Stripe un endpoint de webhook que apunte a tu API seguida de:

/api/payments/webhooks/stripe

Suscríbelo a checkout.session.completed, checkout.session.expired, charge.refunded y charge.dispute.created, copia su secreto de firma en STRIPE_WEBHOOK_SECRET y reinicia la API. Para PayPal, define PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET y PAYPAL_WEBHOOK_ID; PAYPAL_ENV vale sandbox por defecto, que no mueve dinero.

Después haz un pedido de prueba y obsérvalo. Un pedido se guarda como no pagado, y cuenta como pagado solo cuando la API ha preguntado al proveedor qué ocurrió. Si un cliente abandona la página de pago, la API cancela el pedido más tarde y devuelve el stock y los puntos de recompensa. El servidor calcula el precio de cada pedido con su propia carta, así que un navegador no puede cambiar un total.

Fíjate en la elección de pago en el checkout: el cliente es enviado a la página del proveedor, así que aquí no aparece ningún campo de tarjeta.

Comprueba antes de seguir

Un pedido se guarda como no pagado, pasa a pagado cuando el proveedor lo confirma y luego aparece en la cola de cocina como confirmado.

Qué suele salir mal

Un pedido pagado se queda como no pagado. Revisa la dirección del webhook, el secreto de firma en el .env de la API, que hayas reiniciado la API y que API_PUBLIC_URL y STOREFRONT_URL sean accesibles desde el navegador del cliente. Que el cliente vuelva a tu sitio nunca paga un pedido por sí solo.

Paso 7: Añade personal y roles

Abre Equipo. La plantilla tiene tres tipos de cuenta. El dueño lo ve todo, incluidos el equipo y los roles. Un gerente ve todo salvo esas dos cosas. Una cuenta de cocina se limita a los pedidos de una sola cocina, oculta los precios y el correo del cliente, y pasa los pedidos de confirmado a en preparación y a listo.

Para Olive Street Kitchen, crea una cuenta de cocina para cada una de las dos cocinas, más un gerente. Los roles se editan permiso por permiso, así que también puedes crear un rol propio. Después borra o cambia las cuentas de demostración. Nadie debería poder entrar con una contraseña impresa en un documento.

Comprueba antes de seguir

La cuenta de cocina ve solo su propia cocina, sin precios, y puede pasar pedidos a listo. El gerente no ve la página de Equipo.

Qué suele salir mal

Solo el dueño tiene los permisos de equipo y de roles, así que un gerente no puede corregir un rol. Edita los roles permiso por permiso cuando los valores por defecto no encajen.

Paso 8: Decide si quieres las herramientas de IA

Las funciones de IA son opcionales, y el restaurante funciona sin ellas. Con una clave de Google Gemini en el .env de la API se activan tres cosas: un asistente al que puedes preguntar por pedidos, ventas y carta, y que responde con tus propios datos, un redactor que prepara la ficha de un plato a partir de una indicación o de fotos, y una herramienta para dar otro estilo a las fotos. Google cobra el uso de Gemini según sus propias tarifas, así que consulta la página de precios de Gemini antes de entregarle una clave a un dueño de restaurante.

Una herramienta no cuesta nada por foto: quitar el fondo de la foto de un plato se ejecuta en tu propio servidor con un modelo local y no necesita clave. Solo tienes que añadir el archivo del modelo. Eso permite que cada plato aparezca recortado en su propia tarjeta. Si te saltas las claves de IA, esos botones dicen que no están conectados, y nada más se rompe.

Fíjate en la foto del plato antes y después del cambio de estilo, con el original conservado para comparar.

Comprueba antes de seguir

Pregunta al asistente algo que puedas comprobar en el resumen, como cuántos pedidos entraron hoy, y lee el antes y el después de cualquier cambio que proponga.

Qué suele salir mal

Las funciones de IA dicen que no están conectadas. Pon la clave en el .env de la API, nunca en un archivo del front end, y reinicia la API.

Paso 9: Prueba el pedido completo, en el móvil y en árabe

Antes de tocar un dominio, ejecuta el pedido de principio a fin. En el móvil, abre el sitio, busca un plato, añade un combo, elige entrega, introduce un código postal dentro de la zona de una cocina y paga con la clave de prueba. Mira cómo el pedido aparece en el panel, pásalo por cada estado y confirma que la página de seguimiento del cliente se actualiza. Los pedidos para recoger se saltan el paso de entrega.

Fíjate en el selector de entrega o recogida en la parte superior del carrito, que decide si se aplica la comprobación del código postal.

Después repite la prueba en árabe en /ar. Revisa la carta, el carrito, el pago y el panel con la disposición de derecha a izquierda. Comprueba también una dirección fuera de la zona de todas las cocinas y un pedido hecho mientras una cocina está cerrada, porque son los casos con los que se encontrará un cliente real el primer día.

Fíjate en la línea de estado que le dice al cliente dónde está su pedido: es la página que debes refrescar mientras avanzas el pedido en el panel.

Fíjate en la disposición reflejada: los filtros, las tarjetas y la navegación cambian de lado mientras los precios mantienen los dígitos latinos.

Fíjate en cómo la página del plato se adapta a una pantalla estrecha, con la cantidad y el botón de añadir al alcance del pulgar.

Comprueba antes de seguir

Ejecuta tu lista de pruebas en un móvil y en un portátil: busca un plato, cambia de entrega a recogida, aplica un código promocional, paga y mira cómo se actualiza la cronología.

Qué suele salir mal

Los pedidos nuevos aparecen solo tras recargar. El panel se conecta a NEXT_PUBLIC_WEBSOCKET_BASE_URL, y la API solo acepta esa conexión desde la dirección de FRONTEND_URL.

Paso 10: Sal en producción

Salir en producción significa tres apps en un host de Node, una base de datos, un lugar para las subidas y tus dominios reales. La plantilla guarda sus decisiones en archivos .env, así que la mayor parte del trabajo consiste en configurarlos bien:

• Define NODE_ENV=production y tu propio JWT_SECRET. Genera un secreto nuevo en lugar de reutilizar el del ejemplo. En producción la API no arranca sin CORS_ORIGIN, que lista las direcciones del sitio y del panel separadas por comas.
• Define FRONTEND_URL (el panel, para las notificaciones de pedidos en vivo), STOREFRONT_URL (adonde los pagos y los restablecimientos de contraseña envían al cliente) y API_PUBLIC_URL (adonde Stripe y PayPal devuelven primero).
• Elige la base de datos: SQLite en un disco persistente, o una base de datos MySQL vacía con su conexión definida en .env y la carga inicial o la creación de tablas ejecutada antes del primer arranque.
• Apunta las subidas a un almacenamiento persistente: una carpeta local en un disco que persista, o un bucket (define las cinco variables del bucket).
• En los dos front ends, define NEXT_PUBLIC_API_BASE_URL con la dirección de la API en producción, incluido /api, y vuelve a compilar. Estos valores se compilan dentro del código que carga el navegador, así que un cambio no hace nada hasta la siguiente compilación.
• Cambia Stripe y PayPal de las claves de prueba a las claves reales, y añade los webhooks reales.

No uses yarn railway:setup como comando de compilación de un restaurante en producción. Borra todas las tablas y vuelve a cargar los datos cada vez que se ejecuta, algo que va bien para un entorno nuevo y arruina uno que ya funciona. Después haz un pequeño pedido real y devuélvelo desde el panel del propio proveedor, para saber que todo el circuito funciona con dinero real.

Comprueba antes de seguir

En una ventana privada, haz un pedido como invitado y confirma que funcionan la página de pago, la vuelta a tu sitio y la notificación en el panel.

Qué suele salir mal

Páginas vacías con un mensaje de CORS en la consola significan que las direcciones reales no están en CORS_ORIGIN. Un "Too many attempts" para todo el mundo significa que TRUST_PROXY no está definido detrás de un proxy. Las fotos fallan cuando NEXT_PUBLIC_MEDIA_HOSTNAME no nombra su host.

El día a día

El lanzamiento es el comienzo del trabajo. Así son un día y una semana normales del equipo de Olive Street Kitchen, con pantallas que el panel ya tiene.

Una mañana en el panel

El gerente abre el resumen. Empieza por el dinero y el ritmo del día (ingresos, número de pedidos, pedido medio, pedidos en preparación) junto a los de ayer, y sigue con gráficos de ingresos por hora y de reparto por categoría, y con la lista de los más vendidos y la cola de cocina. Se actualiza cuando entra un pedido.

Fíjate en la cola de cocina junto a las cifras de ventas: es la parte de la pantalla a la que el equipo vuelve todo el día.

Después viene la página de pedidos. Filtra por estado, por entrega o recogida, o por fecha, y abre un pedido para ver sus artículos, sus totales y su cronología. Solo se ofrece el siguiente estado razonable, y una cancelación exige un motivo. Mira también la campana: guarda los mensajes del formulario de contacto.

Durante el servicio

El personal de cocina trabaja desde su propia cuenta, ve los pedidos confirmados de su cocina sin precios y los va avanzando. Cuando algo se agota, el gerente pone ese plato como no disponible en su fila de la carta, lo que detiene los pedidos nuevos sin borrar el plato.

Tareas semanales

• Renueva la página de inicio. Reordena las nueve secciones, edita la portada en los dos idiomas y elige los platos populares. No hace falta cambiar código.

Fíjate en la lista de secciones con sus interruptores y flechas: así se define el orden de la página de inicio pública.

• Revisa la carta. Archiva lo que ya no cocinas y añade el plato de temporada con los dos idiomas rellenados.
• Pregunta al asistente. ¿Qué platos se venden mejor esta semana? Responde con tus propios datos y dibuja un gráfico para las tendencias.
• Haz copias de seguridad. La base de datos y las subidas son el negocio. Activa las instantáneas de tu host y guarda una copia en otro lugar.

Un plan de lanzamiento de ejemplo, semana a semana

Este es un calendario de ejemplo para Olive Street Kitchen, no una promesa sobre lo que tardará tu proyecto.

• Semana 1, cimientos. Ejecuta el stack con Docker, haz el recorrido como dueño, gerente, cocina y cliente, toma las decisiones de arriba y empieza con la marca y las páginas legales.
• Semana 2, contenido. Introduce las dos cocinas, las categorías y los primeros platos en los dos idiomas con fotos. Crea un combo y organiza la página de inicio.
• Semana 3, dinero y personas. Conecta Stripe y PayPal en modo de prueba, crea las cuentas del equipo y ejecuta el recorrido completo del pedido en dos móviles y en árabe.
• Semana 4, salida a producción. Despliega en tus dominios, cambia a las claves reales, haz un pequeño pedido real e invita primero a unos cuantos clientes habituales.

Lista de comprobación para el lanzamiento

• El nombre del restaurante, los datos de contacto y los textos legales son tuyos, en inglés y en árabe.
• Cada plato de la carta tiene los dos idiomas, alérgenos y una foto.
• Cada cocina tiene el horario, la zona horaria, los códigos postales, las tarifas y el pedido mínimo correctos.
• El reloj de servicio está en Real, no en el reloj de demostración.
• Las cuentas de demostración están borradas o tienen contraseñas nuevas.
• JWT_SECRET es tuyo, y NODE_ENV es production.
• CORS_ORIGIN, FRONTEND_URL, STOREFRONT_URL y API_PUBLIC_URL usan las direcciones reales.
• Los dos front ends se volvieron a compilar con la dirección real de la API.
• Stripe y PayPal usan claves reales, y sus webhooks reales entregan.
• La base de datos y las subidas están en un almacenamiento que sobrevive a un reinicio, y existe una copia de seguridad.
• domain.url en la configuración de la marca es la dirección real.
• Se hizo un pedido real, se siguió y se devolvió desde el panel del proveedor.

Plantilla, desde cero o una plataforma alojada

Hay tres formas honestas de poner un restaurante online, y ninguna es la mejor para todos.

Una plantilla como esta

Obtienes el código fuente del sitio, del panel y de la API, así que el resultado es tuyo y puedes cambiar lo que quieras. El cálculo de precios en el servidor, las comprobaciones de entrega, los estados de los pedidos y los webhooks de pago ya están resueltos. A cambio, tú alojas y mantienes el sistema, y todo lo que la plantilla no tiene, como las confirmaciones por correo, es trabajo de desarrollo.

Construirlo desde cero

Obtienes exactamente el producto que diseñes. Pero también construyes y pruebas tú mismo cada regla: cómo se calcula el precio de un combo, cómo un webhook confirma un pago una sola vez, cómo se reserva y se libera el stock. Para la mayoría de los restaurantes es un camino largo hasta llegar a donde empieza una plantilla.

Una plataforma de pedidos alojada

Es la forma más rápida de empezar, y otra empresa se encarga de los servidores. A cambio hay cuotas recurrentes, menos control sobre la experiencia del cliente y tus datos de pedidos viviendo en su sistema. Compara las condiciones de cada plataforma, las comisiones de pago y su compatibilidad con el árabe antes de elegir.

Cuánto cuesta mantenerlo

La plantilla es una compra única, desde $79 solo por el sitio de pedidos. El paquete Full Stack que usamos en este ejemplo cuesta $179. Incluye soporte de por vida y una licencia comercial.

Mantener el restaurante cuesta más que la plantilla. Pagas por:

• El alojamiento de la API, del sitio y del panel, y un disco persistente o una base de datos MySQL.
• El almacenamiento de las fotos subidas, si eliges un bucket como Cloudflare R2.
• Las comisiones del procesador de pagos. Stripe y PayPal cobran según sus propias páginas de precios, y la plantilla no añade nada. Consulta los precios de Stripe.
• Una clave de Google Gemini, solo si activas el asistente de IA o las herramientas de fotos.
• Tu propio dominio.

Lo que no cuesta nada: el desarrollo local con SQLite, el pago de demostración, los mosaicos del mapa (la plantilla usa por defecto los estilos públicos de OpenFreeMap, que no necesitan clave) y la eliminación de fondos en tu propio servidor.

Qué personalizar después

• Recompensas. La demostración da un punto por dólar y descuenta $5 por 100 puntos. Cambia esas cifras en Ajustes para que encajen con tus márgenes.
• Códigos promocionales. Crea un código con un porcentaje, decide si cubre la carta o todo el pedido, y si se combina con las recompensas.
• La página de inicio. Reordena las nueve secciones para ajustarlas a una campaña y reescribe la portada en los dos idiomas sin cambiar código.

Errores comunes

Cambiar el .env de un front end y esperar que se aplique

Cada valor NEXT_PUBLIC_* se compila dentro de la página en el momento de la compilación. Si el sitio sigue llamando a la API antigua después de editar el archivo, vuelve a compilarlo. Con Docker Compose, pon el valor en el .env junto a docker-compose.yml y ejecuta docker compose up --build.

Dejar puesto el reloj de demostración

La carga inicial mantiene todas las cocinas abiertas a la misma hora fija para que puedas probar a medianoche. Si olvidas cambiar al reloj real, los clientes podrán pedir a una cocina cerrada.

Olvidar CORS en los dominios reales

Si las páginas reales siguen vacías y la consola del navegador menciona CORS, la API todavía no conoce tu dominio. Añade las direcciones de los dos front ends a CORS_ORIGIN y reinicia la API.

Dar por hechas funciones que no están incluidas

La plantilla no envía correos de confirmación de pedido, no acepta pedidos para más tarde, no añade propinas ni líneas de impuestos y no gestiona el pago contra entrega. El correo de restablecimiento de contraseña pasa por Resend si lo configuras. Si Olive Street Kitchen necesita alguna de las otras, reserva tiempo de desarrollo.

Preguntas frecuentes

¿Cómo creo un sistema de pedidos online para un restaurante con Next.js?

Empieza con una plantilla que ya incluya las partes difíciles y luego configúrala. Necesitas un sitio para los clientes, un panel para el personal y una API que calcule el precio de los pedidos y hable con un proveedor de pago. Esta guía recorre los pasos con Food Studio: ejecutarlo, ponerle tu marca, introducir las cocinas y la carta, probar los pagos, añadir personal y desplegar.

¿Necesito un backend?

Sí. Los precios, el stock, los estados de los pedidos y la confirmación del pago deben decidirse en un servidor, no en el navegador. La plantilla incluye una API de NestJS con TypeORM para eso, y el sitio y el panel leen todo de ella.

¿Puedo usarla en proyectos de clientes?

Sí. Viene con una licencia comercial para proyectos ilimitados, que cubre a las agencias que construyen sitios para restaurantes. Lee la licencia en la documentación para conocer las condiciones exactas.

¿Admite árabe y RTL?

Sí. El sitio, el panel y la API funcionan en inglés y en árabe. Las páginas en árabe se reflejan de derecha a izquierda, y los platos se guardan con un nombre y una descripción en los dos idiomas.

¿Puedo manejar varias cocinas?

Sí. Cada cocina tiene su propio horario, su zona horaria, sus códigos postales de entrega y sus cuentas de personal. El sitio le dice al cliente si una cocina reparte a su código postal, si está cerrada o si otra cocina puede aceptar el pedido.

¿Qué proveedores de pago funcionan?

Stripe Checkout y PayPal. Ambos llevan al cliente a su propia página y confirman el pedido mediante un webhook firmado. Usas tus propias cuentas, y sus comisiones no forman parte del precio de la plantilla.

¿Necesito Docker?

No, pero es el inicio más rápido. Sin Docker necesitas Node.js 24 o superior y Yarn a través de Corepack, y ejecutas cada app con yarn dev. La API no necesita un servidor de base de datos, porque usa SQLite por defecto.

¿Pueden pedir los clientes sin una cuenta?

Sí. Los clientes pueden pagar con un nombre y un correo, y seguir el pedido con su número y ese correo. Una cuenta añade puntos de recompensa, platos y direcciones guardados, y un botón para repetir el pedido.

¿Envía correos de confirmación de pedido?

No. La plantilla no envía correos de confirmación de pedido. Los clientes ven el pedido en las páginas de confirmación y de seguimiento, y el panel avisa al equipo. El correo de restablecimiento de contraseña funciona a través de Resend cuando añades sus claves.

¿Puedo usar MySQL en lugar de SQLite?

Sí, con un cambio de configuración. Crea una base de datos vacía, define el controlador y la conexión en el .env de la API y ejecuta la carga inicial o la creación de tablas antes del primer arranque en producción.

Pruébalo tú mismo

Haz un pedido en el sitio de pedidos de demostración y luego abre la demostración del panel del personal para ver el otro lado. Lee la documentación de Food Studio para ver cada ajuste de esta guía, o consulta la página del producto para ver los paquetes. Encontrarás más opciones en la categoría de plantillas para restaurantes. Food Studio es además una de las diez plantillas del Next.js Templates Bundle.