Como Construir um App de Pedidos para Restaurante com IA

Resposta rápida

Um app de pedidos para restaurante precisa de quatro peças funcionando juntas: QR codes que abrem um cardápio ao vivo em cada mesa, um cardápio que atualiza no instante em que um prato acaba, uma tela de cozinha que recebe o pedido no segundo em que ele é feito, e atualizações de status que voltam para o cliente sem que ninguém precise tocar em um tablet na recepção. A Greta constrói essas quatro peças como um único app conectado, no seu próprio banco de dados, para você parar de pagar por pedido a uma plataforma SaaS por uma infraestrutura que poderia ser sua.

Por que os restaurantes ainda pagam por pedido por algo tão simples?

O Toast cobra uma taxa de plataforma mais uma porcentagem de cada pedido online. O complemento de pedidos online do Square funciona do mesmo jeito. O ChowNow cobra uma mensalidade fixa que sobe assim que você adiciona uma unidade. Nenhum desses números é segredo --- estão publicados nas próprias páginas de preços dos fornecedores --- e todos partem da mesma suposição: a de que um restaurante não conseguiria rodar o próprio sistema de pedidos.

Essa suposição fazia sentido em 2015. Não faz mais. Um fluxo de pedidos para consumo no local é um cardápio, um carrinho, um registro de pedido e um campo de status ao vivo. Isso é um projeto de fim de semana para um bom construtor de apps com IA, não um projeto de engenharia de seis meses --- e, uma vez construído, não existe fornecedor nenhum entre você e cada transação.

Faça a conta para um restaurante de porte médio: 120 clientes por noite, metade pedindo pelo QR code da mesa, com uma taxa de $1,50 por pedido. São $90 por noite, algo como $2.700 por mês, para sempre, por uma funcionalidade que é basicamente um formulário e uma escrita no banco de dados.

O que um app de pedidos próprio realmente precisa ter?

Não muita coisa, e esse é o ponto. Quatro peças, cada uma fazendo um trabalho:

• Pedido por QR na mesa --- cada mesa tem um código que abre um cardápio vinculado àquele número de mesa, então o pedido sabe exatamente para onde ir sem que um garçom precise digitar nada.
• Gestão de cardápio ao vivo --- o dono ou o gerente muda preços, tira um prato do ar ou adiciona um especial do dia direto do celular, e isso fica visível em todo lugar na hora. Sem revisão de loja de app, sem esperar o ciclo de atualização de um fornecedor.
• Sincronia com a tela da cozinha --- a comanda aparece na tela da cozinha no instante em que o pedido é feito, organizada por mesa e horário, substituindo a impressora que trava bem na hora do rush de sexta.
• Atualizações de status do pedido --- "recebido", "em preparo", "pronto" empurrados direto para o celular do cliente, então ninguém fica rondando o balcão para saber se a comida está saindo.

O modelo de dados por trás disso

É mais simples do que parece. Um Restaurant tem registros de Table, cada um com um QR code e um ID. Os itens de MenuItem pertencem a categorias e carregam um booleano available que a cozinha ou o gerente alterna em tempo real. Cada Order está ligado a uma mesa (ou a um horário de retirada, no caso de pickup) e guarda registros de OrderItem com quantidade e observações. Um campo status no pedido --- feito, confirmado, em preparo, pronto, concluído --- é a fonte única de verdade que tanto a tela da cozinha quanto o celular do cliente consultam. A Greta estrutura isso em Postgres via Supabase com Prisma, e o conjunto inteiro cabe confortavelmente em cinco ou seis tabelas.

Como a tela da cozinha se mantém sincronizada na prática?

Essa é a parte que a maioria das tentativas caseiras erra. Consultar o banco de dados a cada poucos segundos em busca de pedidos novos funciona bem numa demo e desmorona às 19h30 de um sábado --- a tela da cozinha atrasa, as comandas se acumulam fora de ordem, e um garçom acaba tendo que voltar para conferir.

A Greta resolve isso com as assinaturas em tempo real do Supabase em vez de ficar consultando o banco. No instante em que uma linha da tabela orders muda, todo cliente inscrito --- a tela da cozinha, a página de status do cliente, o painel do gerente --- recebe a atualização empurrada por uma conexão websocket. Sem botão de atualizar, sem atraso de cinco segundos, sem comanda perdida. É o mesmo padrão em tempo real por trás de vários apps colaborativos por aí; só que aqui é exatamente o que uma cozinha precisa.

Comparação: alugar a plataforma vs ser dono do app

E o pickup e a retirada, não só o consumo no salão?

O mesmo sistema, com uma entrada diferente. Um pedido de retirada pula a etapa de mesa e recebe, em vez disso, um horário estimado de prontidão --- que na prática é só um campo de data/hora no mesmo modelo de Order, com um fluxo diferente ligado a ele: sem QR de mesa, mas com a mesma tela de cozinha, o mesmo pipeline de status, o mesmo cardápio. Você não está mantendo dois apps; está mantendo um único modelo de pedido com duas portas de entrada. Mande uma mensagem de texto para o cliente quando o pedido estiver pronto usando o Twilio, ou deixe que ele mesmo acompanhe a página de status mudar de "em preparo" para "pronto" no próprio celular.

Erros comuns ao construir isso

• Copiar a lista de funcionalidades do SaaS em vez do fluxo real do restaurante. A maioria dos restaurantes de unidade única não precisa de pontos de fidelidade ou carteira de recompensas no dia um. Lance pedido na mesa, cardápio ao vivo, sincronia com a cozinha, atualizações de status --- e só depois adicione o que os clientes realmente pedirem.
• Tratar a tela da cozinha como um detalhe secundário. É a parte mais usada, todo santo turno, sob pressão. Teste com uma tela de verdade numa cozinha de verdade antes de lançar, não só num notebook em cima da mesa.
• Pular o fluxo de "esgotado". Um cardápio que não consegue tirar um prato do ar em tempo real vai continuar recebendo pedidos de algo que não existe mais, e isso é uma experiência pior do que qualquer demora de loja de app.
• Assumir que uma unidade significa que você nunca vai precisar de duas. O modelo de dados acima escala para múltiplos restaurantes com quase nenhum trabalho extra, desde que Restaurant já seja uma tabela de primeira classe desde o início, em vez de ser encaixada depois.

Perguntas Frequentes

Ainda preciso de uma processadora de pagamentos como Stripe ou a maquininha do Square? Sim --- a Greta não substitui os trilhos de pagamento, ela substitui o software de pedidos e cardápio que fica em cima deles. O Stripe cuida da cobrança; seu app cuida de tudo ao redor dela.

Os clientes precisam baixar um app? Não. Um QR code abre uma página web. Isso é menos atrito do que instalar um app pela loja, e é por isso que a maioria dos fluxos de pedido modernos pula o app nativo do lado do cliente.

Quanto tempo leva para construir algo assim de verdade? O núcleo --- pedido por QR, gestão de cardápio, tela de cozinha, sincronia de status --- é realista em questão de dias com a Greta, não meses, porque o modelo de dados é pequeno e a camada em tempo real é um padrão conhecido, não um projeto de pesquisa.

Dá para rodar isso em várias unidades? Sim, se a relação entre Restaurant e Table for pensada assim desde o início. Adicionar uma segunda unidade vira um novo registro de restaurante, não um novo contrato mensal de SaaS.

E se eu quiser trocar de hospedagem depois? Nada dramático. É o seu código Next.js no seu GitHub e os seus dados no seu próprio banco Postgres --- exporta, reimplanta, pronto. É esse o ponto inteiro de não construir em cima de uma plataforma alugada.

Conclusão

A tecnologia aqui não é mais a parte difícil. Pedido na mesa, cardápio ao vivo, tela de cozinha sincronizada e atualizações de status formam um conjunto bem conhecido, e um construtor de apps com IA consegue montar isso rápido. A decisão de verdade é se você quer continuar pagando por pedido por isso ou construir uma vez e parar de pagar o pedágio.

Comece a construir seu app com a Greta hoje.