Projeto de portfólio — construído para um caso de uso real (rifa de certificação Linux da UPlinux).
Demo: https://rifa.uplinux.com.br
Rifa Online - Documento de Projeto
produto: o problema, o contexto, a estratégia e os resultados esperados.
1. Qual o problema que o projeto resolve?
Rifas organizadas manualmente — planilha, papel, grupo de WhatsApp — têm um conjunto previsível de falhas:
- Venda duplicada do mesmo número, quando duas pessoas reservam ao mesmo tempo e o organizador só percebe depois.
- Confirmação de pagamento manual, checando extrato bancário ou comprovante um a um, com atraso e risco de erro humano.
- Nenhuma trilha de auditoria: quando um participante contesta ("eu paguei o número 47"), não há registro confiável de quem reservou o quê e quando.
- Números "presos" indefinidamente por quem reservou e nunca pagou, reduzindo o estoque disponível sem necessidade.
- Sorteio sem prova de lisura — um sorteio feito "na mão" não convence ninguém de que foi justo.
O projeto nasceu de um caso real: a rifa de uma certificação Linux da UPlinux, que precisava de um jeito profissional de vender números e cobrar via Pix sem depender de controle manual.
2. Contexto da solução
A solução parte de uma constatação simples: Pix é o método de pagamento padrão no Brasil, e qualquer rifa que não oferece Pix instantâneo perde conversão. Ao mesmo tempo, plataformas SaaS de rifa cobram taxa por venda ou mensalidade fixa, o que corrói a margem de quem está arrecadando para uma causa ou um sorteio pontual.
A resposta é um sistema open source, auto-hospedado, que qualquer organizador com um mínimo de familiaridade técnica (ou ajuda de terceiros) pode colocar no ar sem pagar taxa por transação — só a infraestrutura (Supabase, Netlify), que tem camada gratuita suficiente para volumes pequenos e médios.
3. Em qual contexto se aplica?
- Organizações e criadores individuais no Brasil vendendo números para arrecadação, divulgação ou brinde — o caso de uso original é uma certificação profissional, mas o modelo serve para qualquer prêmio numerado.
- Rifas de porte pequeno a médio (a UI foi desenhada em torno de uma grade de 100 números por rifa, mas o sistema suporta várias rifas simultâneas).
- Quem valoriza transparência: a grade pública mostra em tempo real quais números estão disponíveis, reservados ou pagos, e o sorteio final é verificável (hash + seed registrados).
- Quem quer/precisa personalizar: por ser código aberto, pode ser adaptado (marca, regras, integrações) em vez de depender de uma plataforma fechada.
- Não se aplica a operações que exigem licença de jogo/aposta regulamentada — é uma
ferramenta de rifa/sorteio promocional, não uma plataforma de apostas.
4. A solução
Uma aplicação web full-stack com os seguintes módulos:
| Módulo | O que resolve |
|---|---|
| Grade pública em tempo real | Elimina venda duplicada: cada número mostra seu estado real (disponível/reservado/pago), sincronizado via Realtime entre todos os visitantes. |
| Reserva atômica | Uma função de banco com trava de linha garante que dois pedidos simultâneos pelo mesmo número nunca sejam ambos aceitos. |
| Pagamento Pix (AbacatePay) | QR Code e copia-e-cola gerados pela integração; confirmação automática por webhook, com verificação por polling como reforço. |
| Expiração automática (1h) | Reserva sem pagamento libera o número sozinha — ninguém trava estoque indefinidamente. |
| Notificação por e-mail (opcional) | Envia o Pix e a confirmação de pagamento por e-mail via Resend, sem exigir isso do participante. |
| Painel administrativo | Confirmação manual, busca, filtros, exportação, log de auditoria completo de toda ação sensível. |
| Sorteio verificável | Animação de sorteio entre os números pagos, com hash de integridade e seed registrados — qualquer pessoa pode conferir que o resultado não foi manipulado. |
| Painel de configuração | Diagnostica quais chaves/segredos essenciais estão configurados no ambiente de produção, com instruções — pensado para quem faz fork do projeto conseguir colocá-lo no ar sozinho. |
| Marca personalizável | Nome e logo trocáveis pelo admin, sem precisar mexer em código. |
5. Qual a estratégia em utilizar o projeto
- Fork do repositório — o código é público e pensado para reuso, não só para a UPlinux.
- Provisionar a infraestrutura própria: criar um projeto no Supabase e rodar os
scripts em
docs/*.sql(schema, RLS, expiração automática, integração de pagamento). - Configurar o pagamento: criar conta na AbacatePay, obter a chave de API.
- Publicar (Netlify, ou qualquer host compatível com Node/Nitro) e configurar as
variáveis de ambiente — o painel
/admin/configuracao, já no ar, confere o que falta e orienta onde obter cada valor. - Personalizar a marca pelo próprio painel admin, sem precisar de deploy novo.
- Criar a rifa, divulgar o link público, e acompanhar reservas/pagamentos pelo painel — a confirmação de pagamento é automática na maior parte dos casos.
- Rodar o sorteio quando a rifa encerrar, com o resultado já verificável e pronto para exportar (PDF/JSON) e compartilhar.
A estratégia central é reduzir a fricção operacional de quem organiza (nada de planilha, nada de conferir comprovante um a um) e aumentar a confiança de quem participa (grade em tempo real, sorteio auditável).
6. Quais os resultados que o projeto pode trazer?
- Zero venda duplicada — a trava atômica no banco torna esse erro estruturalmente impossível, não apenas improvável.
- Confirmação de pagamento quase instantânea, contra o atraso de horas/dias de uma checagem manual.
- Menos tempo administrativo por rifa: o organizador não precisa mais reconciliar planilha com extrato bancário.
- Maior taxa de conclusão de compra, por oferecer Pix nativo em vez de redirecionar para fora do fluxo.
- Confiança do participante, por ver o status em tempo real e poder auditar o sorteio.
- Menor custo por venda, por não depender de uma plataforma que cobra taxa por transação.
- Rastreabilidade completa para resolver qualquer disputa ("quem reservou o número X e quando"), via log de auditoria.
- Portfólio técnico: o projeto demonstra, de ponta a ponta, controle de concorrência, integração de pagamento real, segurança de dados (RLS, segredos isolados do banco) e atenção a acessibilidade — não é um CRUD de vitrine.
7. Quais os próximos passos para melhorar o sistema?
- Suporte a outros meios de pagamento além de Pix, para mercados fora do Brasil ou participantes sem conta bancária brasileira.
- Notificação automática por WhatsApp, hoje só manual (link
wa.mepré-preenchido). - Internacionalização do texto da interface, hoje fixo em português.
- Os itens de acessibilidade/UX identificados na última auditoria (contraste, foco,
prefers-reduced-motion) já foram todos corrigidos — o próximo ciclo de revisão de UI deve olhar para o fluxo administrativo (rifas, sorteio) com o mesmo rigor aplicado à grade pública.
8. Quais as tecnologias e conceitos aplicados
Frontend — React 19, TanStack Start/Router, TanStack Query, TypeScript, Tailwind CSS v4 (tokens semânticos), shadcn/ui sobre Radix, tema claro/escuro.
Backend — Postgres via Supabase (PostgREST, Realtime, Storage, Auth), pg_cron para
tarefas agendadas, funções SECURITY DEFINER para lógica de negócio sensível.
Pagamento — AbacatePay (Pix QR Code, API Checkout Transparente v2), com reconciliação por webhook e por polling.
E-mail — Resend (API transacional), envio opcional e não-bloqueante.
Infraestrutura — Netlify (build Nitro/Vite), gerenciamento de dependências com Bun.
Conceitos de engenharia aplicados:
- Controle de concorrência via trava de linha (
SELECT ... FOR UPDATE) para reservas atômicas. - Row Level Security (RLS) como camada de autorização no próprio banco, independente do código da aplicação.
- Separação estrita entre segredos de servidor e dados de cliente — nenhuma chave sensível chega ao bundle enviado ao navegador, reforçada por um scanner de segredos automático no build.
- Idempotência em operações críticas (confirmação de pagamento pode ser chamada mais de uma vez sem duplicar efeito).
- Degradação graciosa: funcionalidades opcionais (e-mail, teste de chave) nunca quebram o fluxo principal se falharem.
- Verificabilidade criptográfica do sorteio (hash + seed).
- Acessibilidade como requisito, não afterthought: contraste WCAG AA calculado (não
estimado), suporte a
prefers-reduced-motion, navegação por teclado. - Diagnóstico auto-guiado: o painel de configuração transforma "erro de variável de ambiente faltando" em orientação acionável, em vez de mensagem de erro genérica.
9. Qual a conclusão
O projeto resolve um problema concreto e validado — a rifa da UPlinux — com uma solução que vai além do suficiente para aquele caso específico: é auditável, segura por padrão, performática em tempo real e pensada desde o início para ser reaproveitada por qualquer pessoa que precise da mesma coisa. A escolha por código aberto e auto-hospedagem troca a comodidade de um SaaS fechado por custo menor, controle total dos dados e liberdade de personalização — um trade-off deliberado, não uma limitação.
Desenvolvido por Waldo Eller para a UPlinux — www.uplinux.com.br
