Como criar uma loja online a partir de um único prompt

A maioria das pequenas lojas não deixa de vender online porque o dono não sabe desenhar um site. Elas falham porque uma loja não é um site: é um catálogo, um carrinho, um registro de pedidos, uma contagem de estoque que precisa continuar honesta, um login de cliente e um back office — e cada um deles é um projeto.

É esse o trabalho que um agente de IA agora consegue fazer em uma passada só. Você descreve a loja com as palavras que usaria para explicá-la a uma pessoa, e ele devolve as peças conectadas entre si e rodando.

Este guia acompanha um parágrafo sobre uma torrefação de café até um pedido feito, um estoque decrementado e uma etiqueta de enviado — e é franco com você sobre a única peça que não chega.

Prefere assistir?

A versão de um minuto do canal da Back4app: entra uma ideia, e sai uma loja com frontend, backend, banco de dados e APIs.

Watch it instead Building and Hosting an Online Store with AI

O que o seu prompt deve dizer, de fato?

Descreva a loja, não o software. O agente transforma substantivos em campos do banco de dados e verbos em funcionalidades, então o detalhe útil é o que você vende, o que um cliente faz e o que você faz.

Nomeie os campos de produto que importam para o seu ramo — para café, são nível de torra, origem e notas de degustação; para uma loja de bicicletas, seriam tamanho do quadro e grupo de transmissão. Depois diga o que cada pessoa precisa fazer: navegar e filtrar, comprar, ver pedidos anteriores; adicionar estoque, marcar pedidos como enviados.

Repare no que não está nesse prompt: nenhuma menção a login, e o agente adicionou um mesmo assim, porque um histórico de pedidos que só o cliente pode ver exige uma conta. Ele lê a implicação, não apenas a instrução.

O que volta?

Uma loja, estilizada e abastecida. A nossa abriu em uma vitrine com um título, botões de filtro por nível de torra, um dropdown com os oito países de origem que ele encontrou nos dados e um card por café mostrando preço, estoque e notas de degustação.

Por trás dela, as partes que você não pediu para ver: uma classe Product, uma classe Order, um sistema de contas de clientes, uma role admin e Cloud Functions para checkout, edição de produtos e status de pedidos.

Você descreveu uma loja em um parágrafo. O que voltou foi o schema, a vitrine, o fluxo de pedidos e o back office — conectados entre si.

O catálogo corresponde ao que você pediu?

Conte antes de confiar. Pedimos 12 cafés e a vitrine mostrou 48 — cada produto quatro vezes.

Vale entender a causa, porque ela vai se repetir. O agente tinha escrito dois caminhos de seed, um job em segundo plano e uma Cloud Function, cada um se protegendo ao contar as linhas primeiro e inserir só se a classe estivesse vazia.

Contar e depois inserir não é atômico: rode os dois ao mesmo tempo e cada um vê zero, então cada um insere a lista inteira.

Um prompt resolveu isso em 50 segundos — 36 duplicatas apagadas, um único caminho de seed mantido, e a verificação mudou de “a classe está vazia?” para “esse nome de produto já existe?”.

Um cliente consegue alterar o preço antes de pagar?

Não, e o motivo é a parte que vale conhecer. O checkout não é um formulário que envia um total; é uma Cloud Function que roda no servidor e reconstrói o pedido do zero:

// Stack: Parse Server 7.5.2 | File: cloud/main.js (generated)
const q = new Parse.Query('Product'); q.containedIn('objectId', ids)
const products = await q.find({ useMasterKey: true })
// …price and stock come from the database, never from the request
if (!p || p.get('stock') < quantity) throw new Parse.Error(142, 'An item is unavailable')
total += p.get('price') * quantity

O que quer que o navegador alegue que um item custa é descartado. O servidor consulta cada produto, recusa o pedido se o estoque for insuficiente, soma o próprio total e só então decrementa o estoque e grava o pedido com uma ACL que permite ao comprador e à role admin lê-lo, e a mais ninguém.

Essa é a diferença entre uma loja e uma página com cara de loja. As regras vivem onde o cliente não alcança.

Um pedido funciona mesmo de ponta a ponta?

Funciona, e vale percorrer o caminho uma vez antes de confiar. Adicionamos dois cafés, de £ 17,00 e £ 16,00, e a sacola totalizou £ 33,00.

O checkout pediu nome, e-mail e endereço de entrega — e nada mais, o que é o primeiro sinal visível de que não há pagamento envolvido.

Fazer o pedido retornou uma confirmação com uma referência, e a vitrine por trás dela se atualizou: os dois cafés comprados caíram de 21 para 20 e de 24 para 23, enquanto todos os outros produtos ficaram onde estavam.

O cliente vê o pedido na própria conta, com itens, total e status:

E o dono da loja vê o mesmo pedido em um back office, com um botão para avançá-lo. Marcar como enviado mudou o status nos dois lugares.

Como adicionar um assistente de loja que não consegue alterar preços?

Conecte o OpenRouter na aba Connections e descreva o assistente, incluindo o que ele não pode fazer.

Nomeie o modelo na mesma frase: a conexão usa openrouter/free por padrão, um roteador que escolhe qualquer modelo gratuito disponível, e esses devolvem respostas inutilizáveis com frequência suficiente para quebrar o widget.

O que chega é um botão Ask the roaster e um painel rotulado live catalogue · read only, apoiado por uma Cloud Function, de modo que a sua chave de IA fica no servidor e cada visitante tem um limite diário de uso.

Ele lê o catálogo direito. Quando pedimos uma torra escura com notas de chocolate abaixo de £ 17, o nosso indicou o Midnight Atlas a £ 15,50 e o Volcán a £ 16,50, com origens, notas de degustação e estoque — e deixou de fora, corretamente, o Sumatra de £ 17,00, que não está abaixo de dezessete.

Quando pedimos para definir um preço em £ 1 e apagar um produto, ele recusou, e o catálogo continuou igual: ainda 12 cafés, Midnight Atlas ainda a £ 15,50. A recusa é estrutural — a função só consulta e devolve texto.

Como o cliente recebe um e-mail de confirmação?

Conecte o Resend e diga quando enviar. A confirmação então sai como parte do checkout que já validou o pedido, de modo que o e-mail só pode descrever algo que realmente aconteceu.

O nosso chegou com o assunto Your Meridian order GBBMQS, com os itens, as quantidades, o total e o endereço de entrega. O cliente vê o mesmo pedido na própria conta, e o status dele acompanha o que o back office faz com ele.

Como receber o dinheiro?

Não com nada que o agente construa hoje. Esse é o limite honesto da abordagem: a loja registra pedidos e gerencia estoque, e nenhum cartão é cobrado em momento algum.

A aba Connections da plataforma oferece hoje modelos de IA, e-mail e SMS — nenhum provedor de pagamento —, então o pagamento com cartão tem de vir de você. O caminho mais leve é um link de pagamento hospedado por produto, que é uma URL, não uma integração; uma integração completa de checkout é mais trabalho e mais controle.

Planeje a sequência de acordo: construa e ajuste a loja com o agente, adicione o pagamento, depois abra. Catálogo, contas, pedidos e back office são as semanas de trabalho que isso elimina; o pagamento é a tarde que sobra para você.

O que fazer quando uma integração falha em silêncio?

Leia a aba Logs, depois leia o código. As nossas duas integrações falharam do mesmo jeito na primeira tentativa, e nenhuma avisou na tela.

O assistente respondeu “I’m having trouble reaching the roastery right now”, e o e-mail de confirmação simplesmente nunca chegou, enquanto o pedido em si foi salvo perfeitamente.

A causa era uma linha em cada um. O código gerado acessava o mundo externo com Parse.Cloud.httpRequest, uma API do Parse que não existe mais na versão do Parse Server que a plataforma provisiona, então a chamada lançou um erro e um catch o transformou em uma mensagem amigável.

// Stack: Parse Server 7.5.2 | File: cloud/main.js
// generated — fails silently, the API is gone
try { await Parse.Cloud.httpRequest({ method: 'POST', url, headers, body }) } catch (_) {}

// what works
const response = await fetch(url, { method: 'POST', headers, body: JSON.stringify(body) })
if (!response.ok) console.error(`Provider returned ${response.status}: ${await response.text()}`)

Vale saber: o agente escreveu fetch corretamente em outros projetos, então isso varia entre execuções. E, quando reportamos só o assistente, ele corrigiu o assistente e deixou a linha idêntica no caminho do e-mail — nomeie cada lugar afetado, ou peça para substituir todas as ocorrências.

Como colocar a loja no ar?

Clique em Publish. Até lá, tudo vive em um workspace de rascunho feito para iteração; publicar copia tudo para um servidor de produção com dados próprios e segredos próprios, e o diálogo conta o que está prestes a ser movido para você conferir antes.

Depois disso, os dois ficam separados. Você continua alterando o rascunho enquanto os clientes usam a loja publicada, e publica de novo quando uma mudança estiver pronta.

Quando este não é o jeito certo de abrir uma loja?

Quando você vende em um lugar que já funciona. Se o seu negócio roda em um marketplace, em uma loja social ou em uma plataforma existente em que os seus clientes confiam, uma loja própria é um problema de marketing, não de software.

Quando as regras comerciais são incomuns. Impostos entre países, assinaturas, preço sob encomenda e cotação de frete são exatamente o que as plataformas maduras de e-commerce passaram anos acertando.

E quando ninguém vai ser dono dela. Uma loja que recebe dinheiro precisa de alguém para guardar as chaves, acompanhar os pedidos e ler o que o agente escreveu antes de o primeiro cliente real chegar.

O que fazer primeiro?

Escreva o parágrafo. Não uma especificação — a descrição que você daria a um amigo que perguntasse o que a sua loja vende e quem compra, com os campos de produto que importam para o seu ramo.

Depois confira a contagem do catálogo, faça um pedido você mesmo e veja o estoque se mover. Quando essas três coisas estiverem certas, a única coisa entre você e uma loja funcionando é um provedor de pagamento — e esse é um problema muito menor do que aquele com que você começou.