Licas — Plataforma de encomendas online

Contexto

Projeto profissional, como developer contratado. Trabalhei sozinho: arquitetura, modelo de dados, backend, frontend, documentos legais e preparação para produção.

O problema

Uma encomenda de pastelaria artesanal não é uma compra de supermercado. Parte dos pedidos são bolos personalizados, que precisam de orçamento antes de existir preço; os restantes são produtos de catálogo com preço fixo. Há alergénios que têm de ser declarados. Há épocas em que o volume dispara e períodos em que a loja fecha. E há uma pessoa a gerir isto tudo, que não é técnica e não pode ter medo de carregar num botão.

O sistema tinha de suportar dois fluxos de compra diferentes sem se transformar em duas aplicações separadas.

Decisões técnicas

1. Supabase em vez de um backend próprio

   Escolhi Postgres gerido, com autenticação e políticas de acesso incluídas, em vez de escrever uma API de raiz. O ganho foi tempo: sozinho, um backend próprio significava semanas em autenticação, permissões e infraestrutura antes da primeira funcionalidade útil. O custo é dependência de um fornecedor e ter de pensar em segurança dentro do modelo do Postgres em vez de em código de aplicação — menos familiar e menos perdoador.

2. Permissões validadas na base de dados, não na interface

   Esconder um botão não é segurança. Todas as regras de acesso são aplicadas ao nível da base de dados, e a interface limita-se a refletir o que o servidor já decidiu. Um utilizador que manipule o frontend não ganha nada com isso. O custo é que cada funcionalidade nova obriga a pensar em permissões antes de pensar em ecrãs, o que abranda o desenvolvimento. Compensa: um erro de permissões numa loja com dados de clientes reais não é um bug, é um incidente.

3. Cupões com resgate atómico

   A primeira versão do sistema de cupões tinha um problema que só aparece com azar. Resolvi-o com uma restrição de unicidade ao nível da base de dados, em vez de uma verificação em código. A diferença é fundamental: uma verificação em código pode ser contornada por dois pedidos simultâneos; uma restrição na base de dados não pode ser contornada por nada.

4. Alergénios com três estados, não dois

   Havia uma distinção que o modelo inicial não conseguia representar. Um produto sem alergénios declarados não é a mesma coisa que um produto que ninguém verificou: o primeiro é informação, o segundo é ausência de informação. Separei os dois estados no modelo de dados. Parece um detalhe, mas num negócio alimentar é a diferença entre "este bolo não tem frutos secos" e "não sabemos se este bolo tem frutos secos".

O que correu mal

O maior desafio não foi técnico.

Ao longo do desenvolvimento, o cliente foi mudando de ideias: coisas que pedia e que depois deixavam de fazer sentido, funcionalidades que queria retirar, outras que apareciam a meio. Muitas vezes tive de ser eu a propor como é que uma ideia podia funcionar — algumas propostas ele aceitava, outras não eram o que tinha em mente.

A parte difícil foi perceber o que o cliente queria quando o que ele descrevia não era bem isso. Aprendi a mostrar em vez de perguntar: montar a coisa depressa, pô-la à frente dele, e deixar que fosse o que estava no ecrã a corrigir o que faltava explicar.

No fim correu bem e o sistema ficou como ele queria.

Resultado

Concluído e a aguardar autorização do cliente para publicar. O sistema está pronto; a decisão de abrir ao público é dele.

O que faria diferente

Pensaria no modelo de permissões antes de escrever o primeiro ecrã, e não à medida que as funcionalidades apareciam. Voltar atrás para acrescentar regras de acesso a um sistema já construído custou-me várias reescritas que uma tarde de desenho à frente teria evitado.