Caso de sucesso: eclipseando.com, uma web e um backend de ecommerce feitos de raiz em 19 dias

A 12 de agosto de 2026 houve um eclipse total do sol sobre Espanha. A 24 de julho o eclipseando.com não existia: nem domínio, nem design, nem uma linha de código. Dezanove dias depois o site estava publicado, com uma página por cada município de Espanha, uma loja que cobrava com Stripe e uma cadeia logística que fazia encomendas a quatro fornecedores diferentes. Contamo-lo aqui porque é o projeto que melhor mostra como trabalhamos quando o pedido é «uma web e um backend de raiz», e porque cada peça está em produção e pode ser visitada.

O pedido: uma web com data de validade

O projeto era nosso, não de um cliente, e isso torna-o um exemplo mais honesto: não havia orçamento para esticar nem prazo negociável. A data era marcada pelo céu. Os requisitos saíram de uma investigação prévia e eram concretos: responder a «a que horas e quanto se vê desde a minha terra?» para qualquer município de Espanha, vender óculos certificados e recordações personalizadas por município, e fazê-lo também em catalão, inglês, alemão, francês, italiano e português, porque parte do público vinha de fora.

Descartámos o Shopify e o WooCommerce antes de começar. Não por preço, mas porque o difícil do projeto não era a loja: eram as 8 132 páginas calculadas, o mapa, a previsão de nuvens e umas integrações logísticas que nenhuma plataforma traz de origem. Quando o valor está no que não vem de origem, a plataforma atrapalha mais do que ajuda. Aplicamos esse mesmo critério quando um cliente nos pergunta se deve fazer o seu site sobre o Odoo Website ou à parte.

O que se construiu, peça a peça

O frontal: 8 132 páginas que se calculam, não se escrevem

Cada município de Espanha tem a sua página com a hora de início, o máximo, o fim, a percentagem de ocultação e, na faixa de totalidade, os segundos de escuridão. Esses dados não os escreveu ninguém: calculam-se no momento de gerar o site a partir dos elementos do eclipse e das coordenadas de cada município, e há um teste que compara uma amostra de resultados com os que publica o Instituto Geográfico Nacional. Se o cálculo se desviar, o site não é publicado. Além de Espanha, há índices para Portugal, França, Itália, Alemanha, Irlanda, Islândia, Gronelândia, Marrocos, Países Baixos e Reino Unido.

O multilinguismo é real, não uma tradução automática por cima: cada idioma tem a sua própria rota (/ca/, /en/, /de/…), os seus próprios textos e as suas próprias páginas de loja, e há testes que verificam que as sete versões de cada modelo existem e se ligam entre si. É a mesma regra que aplicamos em flexigotech.com e em pernocta.eu.

O backend: uma API pequena que faz de caixa, armazém e balcão

Tudo o que é estático é servido pelo nginx. O dinâmico depende de /api/* e é uma aplicação FastAPI com o estado em SQLite. Parece modesto, e é de propósito: é mantido por uma pessoa, corre num servidor de poucos euros e aguentou o pico do dia do eclipse sem mudar nada. As decisões que importam estão lá dentro:

• O carrinho é valorizado no servidor. O navegador guarda as linhas, mas cada preço é recalculado face ao catálogo em vigor ao criar a sessão de pagamento. Se não, qualquer pessoa abre a consola e compra um casaco por um euro.
• O webhook do Stripe manda. Um pagamento considera-se cobrado quando o Stripe o confirma com assinatura verificada, não quando o navegador volta à página de agradecimento. Se, ao cobrar, a encomenda ao fornecedor falhar, a API responde com erro para que o Stripe volte a tentar, e uma tabela com o identificador da sessão evita fabricar duas vezes.
• O produto digital entrega-se com uma ligação assinada (HMAC, expira às 72 horas, cinco descarregamentos no máximo) e a caixa de renúncia ao direito de livre resolução é exigida antes de cobrar: a API rejeita o checkout do kit se não vier marcada.
• Os e-mails não se perdem. Cada confirmação sai pelo Brevo; se o Brevo não responder, fica numa fila em SQLite que um temporizador esvazia de quinze em quinze minutos. Um comprador sem o seu e-mail de confirmação é uma reclamação, por isso esta regra não tem exceções.

As interfaces de logística: quatro fornecedores, quatro maneiras de comunicar

Aqui está a parte que mais se parece com o que os clientes nos pedem. A loja vendia coisas que saíam de sítios diferentes, e cada sítio comunicava à sua maneira:

• Uma gráfica com API e webhook. Ao cobrar, a API gera o ficheiro de impressão (um modelo SVG com o nome do município, a hora e a duração, rasterizado a 300 ppp), cria a encomenda e espera o webhook de «enviado» para dar ao comprador o seu seguimento.
• Uma segunda gráfica com fábrica em Barcelona para a roupa, porque a primeira não fabricava vestuário em Espanha e o prazo não chegava. Mediu-se contra as duas API com encomendas reais antes de decidir; a caneca ficou na primeira porque essa sim se fabricava cá.
• Um fabricante de óculos com API de dropshipping que envia para Espanha, França, Alemanha, Reino Unido e Portugal. A encomenda cria-se sozinha ao cobrar, e antes de cobrar consulta-se a sua disponibilidade real por país.
• Um distribuidor sem API. Envia os óculos em 24-48 horas dentro da Península e das Baleares, mas a encomenda é-lhe passada por e-mail. O painel produz com um clique exatamente o que ele precisa: destinatário, morada, telefone, artigo e quantidade, como texto e como CSV em anexo. E como os seus envios saem com a GLS, a API lê a caixa de correio de dez em dez minutos, classifica os e-mails da transportadora (a caminho, em ponto de recolha com data-limite, ausente) e avisa o comprador de cada um.

Uma consequência que parece pequena e não é: uma encomenda com óculos e uma t-shirt são dois pacotes de dois fornecedores. Por isso o seguimento vive por envio e não por encomenda, com uma linha por cada par encomenda-fornecedor. Um único campo «número de seguimento» teria funcionado até ao primeiro cliente que comprasse as duas coisas.

Os prazos medem-se, não se prometem

A API de cotação da gráfica respondia «entrega padrão, 5-10 dias» para tudo, até para produtos que depois rejeitava ao encomendá-los a sério. Descobrimo-lo com uma venda que não pôde ser entregue. Desde então, um temporizador cria todas as madrugadas uma encomenda em rascunho por cada combinação de produto e país, lê a transportadora e os dias reais que a gráfica devolve, e apaga-a. Esses números, e não os da documentação, são os que o comprador vê na ficha antes de pagar. É a mesma lição que aplicamos aos conectores do Odoo: um teste verde contra um mock não prova nada; é preciso medir contra o sistema real.

O que corre sozinho

Sete unidades de systemd fazem o que, numa loja pequena, costuma fazer uma pessoa à mão: ler a caixa de correio da transportadora de dez em dez minutos, esvaziar as filas de e-mail e voltar a tentar de quinze em quinze as encomendas cobradas sem fabricar, atualizar de três em três horas a previsão de nuvens da AEMET para os municípios mais consultados e medir diariamente os prazos da gráfica. Nenhuma chama um serviço externo no percurso de um pedido web: as páginas leem a cache, e há um teste que o garante.

O que disto serve para a sua loja

Quase tudo, trocando o eclipse pelo seu catálogo. O que um cliente nos pede quando diz «quero um site de ecommerce de raiz» é exatamente esta lista: um frontal rápido e multilingue, uma caixa que não se possa enganar, integrações com quem fabrica e com quem envia, seguimento que chegue ao cliente sem que ninguém o copie à mão, e tarefas que corram sozinhas. Quando o cliente já tem Odoo, essa API é substituída pelo próprio ERP e as integrações são conectores de transportadora dentro do Odoo; quando não o tem, ou o seu negócio não cabe num ERP, constrói-se como aqui.

Perguntas frequentes

Ligações úteis dentro da FlexigoTech

O que fazemos sobre isto