Pular para o conteúdo
PRODUTO EM PRODUÇÃO
seeds.expostacker.com.br
SEEDS Experience — arte do produto
live preview

Plataforma full-stack para comunidade exclusiva de mulheres empreendedoras com 51 rotas, matchmaking via IA, realtime messaging e 40 tabelas com Row Level Security

Stack tecnológica: Next.js 15 React 19 Supabase Realtime AI Cloudflare Workers
51
Rotas na aplicação
40
Tabelas com RLS
Low
Stack serverless

Cliente

SEEDS Experience

Setor

Comunidade · Empreendedorismo · Networking

Linha do tempo

Projeto contínuo · 2026-08

Produto ao vivo

Usar agora

Resultados

Resultados reportados pelo cliente durante o rollout

51 Rotas na aplicação

Baseline: 0

Fonte: page.tsx + route.ts no src/app

40 Tabelas com RLS

Baseline: 0

Fonte: supabase/migrations — CREATE TABLE únicas

40+ Índices de banco

Baseline: 0

Fonte: schema.sql — CREATE INDEX

3 Integrações de IA

Baseline: 0

Fonte: Groq + Gemini + Cerebras nos API routes

24 Rotas /app/*

Baseline: 0

Fonte: src/app/(dashboard)/app — diretórios

8 Rotas /admin/*

Baseline: 0

Fonte: src/app/(admin)/admin — diretórios

Dados reportados pelo cliente

O desafio

O desafio

Uma empreendedora recebe um convite exclusivo por e-mail. Clica no magic link. Em segundos, está autenticada e dentro de uma plataforma com feed social, diretório de outras empreendedoras verificadas, eventos com RSVP, mensagens em tempo real, oportunidades de capital, trilhas de aprendizado e um assistente de IA que faz matchmaking entre perfis complementares. Tudo isso rodando em Cloudflare Workers com Supabase como backend, infraestrutura de baixo custo.

A SEEDS Experience precisava de uma plataforma digital que suportasse uma comunidade exclusiva de mulheres empreendedoras com networking verificado, matchmaking por IA, eventos com RSVP, mensageria em tempo real, fórum, trilhas de aprendizado, gamificação com conquistas, diretório de membros, oportunidades de capital, benefícios de parceiros e moderação administrativa. O sistema precisava ser invite-only, com autenticação por magic link, Row Level Security em todas as tabelas e performance em produção sem custo elevado de infraestrutura.

A abordagem

A abordagem

Arquitetamos uma aplicação full-stack com Next.js 15 App Router e Supabase como backend completo. O banco foi modelado com 40 tabelas distribuídas em 8 grupos funcionais: core, social, eventos, negócios, aprendizado, comunicação, reconhecimento e moderação. Row Level Security habilitado em todas as tabelas com policies por usuário. Triggers automáticos para contadores de reações, comentários e saves. Mais de 40 índices incluindo compostos e parciais. Autenticação invite-only via magic link com tabela de convites. Realtime via Supabase para mensagens e salas. Storage para avatares, imagens do feed e capas de eventos. Integrações de IA com Groq, Gemini e Cerebras para matchmaking e assistente. Deploy na Cloudflare Workers via @opennextjs/cloudflare para infraestrutura de baixo custo.

A solução

A solução

A plataforma SEEDS Experience é uma aplicação full-stack completa com 51 rotas, 40 tabelas com RLS, realtime messaging, 3 integrações de IA e área admin completa — tudo deployado na Cloudflare Workers com Supabase como backend.

  • 51 rotas: 4 públicas (home, login, privacidade, auth/callback), 26 protegidas em /app/* (feed, eventos, diretório, conexões, colaborações, fórum, grupos, mensagens, indicações, depoimentos, benefícios, capital, IA, match, mural, notificações, palestrantes, parceiros, perfil, produtos, ranking, salvos, trilhas, vagas, histórico) e 9 admin em /admin/* (convites, eventos, importar, lembretes, membras, métricas, moderação, parceiros)
  • 40 tabelas com RLS habilitado: profiles, invites, privacy_settings, connections, groups, group_members, feed_posts, feed_post_reactions, feed_post_comments, feed_post_saves, hashtags, feed_post_hashtags, feed_post_mentions, events, event_attendees, editions, speakers, collaboration_posts, partners, sponsorships, products, jobs, capital_opportunities, benefits, learning_tracks, lessons, forum_questions, forum_answers, rooms, room_members, messages, notifications, achievements, achievement_reactions, testimonials, post_reports, user_blocks, user_mutes, referrals, tags
  • Autenticação invite-only via magic link: e-mails fora da tabela invites são bloqueados. Primeiro admin criado via seed SQL. Convites enviados via /admin/convites
  • Realtime via Supabase para mensagens e salas de chat, com publicação supabase_realtime ativada nas tabelas messages e rooms
  • Storage Supabase para avatares, imagens do feed e capas de eventos, com buckets públicos e policies de acesso por usuário
  • 3 integrações de IA: Groq (inference rápida), Gemini (matchmaking de perfis) e Cerebras (assistente de conteúdo) — com rate limiting via Upstash Redis
  • Gamificação com achievements, achievement_reactions, testimonials e ranking — triggers automáticos para reaction_count, comment_count e save_count
  • Área admin completa: convites, gestão de eventos, importação de dados, lembretes, gestão de membras, métricas, moderação de denúncias e gestão de parceiros
  • Middleware de proteção de rotas, server-side auth checks em layouts de dashboard e admin, verificação de role admin
  • Deploy na Cloudflare Workers via @opennextjs/cloudflare com Node.js 22, env vars em runtime via Worker secrets, subdomínio seeds.expostacker.com.br

Linha do tempo

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Fase 1

Modelagem

  • Modelagem de 40 tabelas em 8 grupos funcionais
  • RLS habilitado em todas as tabelas com policies por usuário
  • Triggers automáticos para contadores (reações, comentários, saves)
  • Mais de 40 índices incluindo compostos e parciais

Fase 2

Desenvolvimento

  • 51 rotas com Next.js 15 App Router
  • Autenticação invite-only via magic link
  • Realtime para mensagens e salas
  • 3 integrações de IA com rate limiting

Fase 3

Deploy

  • Migração de Netlify para Cloudflare Workers
  • Configuração de @opennextjs/cloudflare
  • GitHub Actions com Node 22 para build e deploy
  • Subdomínio seeds.expostacker.com.br configurado

Metodologia

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

1

Modelar o banco relacional com RLS antes de codar as rotas

2

Usar Supabase como backend completo (Auth + DB + Storage + Realtime)

3

Habilitar RLS em todas as tabelas com policies por usuário

4

Criar triggers automáticos para contadores (reações, comentários, saves)

5

Proteger rotas com middleware + verificação de role admin

6

Migrar de Netlify para Cloudflare Workers via @opennextjs/cloudflare

Arquitetura

Usuária
magic link · invite-only
Next.js 15
App Router · Cloudflare Workers
Supabase
PostgreSQL · Auth · Storage · Realtime
Groq + Gemini + Cerebras (IA)
Upstash Redis (rate limiting)
Cloudflare Workers (edge)
  • → Next.js 15 App Router roda em Cloudflare Workers via @opennextjs/cloudflare
  • → Supabase cloud fornece PostgreSQL, Auth, Storage e Realtime
  • → Middleware protege rotas /app/* e /admin/* com verificação de sessão
  • → Server Components fazem queries diretas ao Supabase com RLS
  • → Client Components usam Realtime subscriptions para mensagens
  • → API routes integram Groq, Gemini e Cerebras com rate limiting via Upstash Redis
  • → Deploy automático: git push → GitHub Actions → opennextjs-cloudflare build → wrangler deploy

Diagrama conceitual — não reflete implementação real

Stack tecnológica

Escolhas técnicas e o que ficou para fora.

saas

Next.js 15

Por quê: App Router com Server Components e API routes. 51 rotas com renderização dinâmica.

Alternativa rejeitada: Pages Router — sem Server Components, menos DX

React 19

Por quê: Server Components por padrão, hooks atualizados e streaming.

Alternativa rejeitada: React 18 — sem Server Components nativos

Tailwind CSS v4 + shadcn/ui

Por quê: Design system com componentes acessíveis e CSS variables.

Alternativa rejeitada: Styled Components — runtime overhead e sem SSR nativo

saas

Supabase

Por quê: PostgreSQL + Auth + Storage + Realtime em um serviço. RLS no banco.

Alternativa rejeitada: Firebase — sem SQL completo, sem RLS

PostgreSQL + RLS

Por quê: 40 tabelas com Row Level Security e policies por usuário.

Alternativa rejeitada: MongoDB — sem transações ACID, sem RLS

Drizzle ORM

Por quê: ORM tipado com TypeScript para queries server-side.

Alternativa rejeitada: Prisma — mais pesado, menos compatível com edge

saas

Cloudflare Workers

Por quê: Hosting full-stack com baixo custo, edge global, deploy automático.

Alternativa rejeitada: Netlify — plano free limitado, sem edge global

@opennextjs/cloudflare

Por quê: Adapter que converte Next.js App Router para Workers.

Alternativa rejeitada: Vercel — excelente, mas custo maior em escala

Groq + Gemini + Cerebras

Por quê: 3 APIs de IA gratuitas para matchmaking e assistente.

Alternativa rejeitada: OpenAI — custo por token, menos adequado para free tier

Upstash Redis

Por quê: Rate limiting serverless para endpoints de IA.

Alternativa rejeitada: Rate limiting em memória — não funciona em edge serverless

Decision log

O que escolhi, o que rejeitei e por quê.

Supabase como backend completo em vez de stack separada

Por que: Supabase une PostgreSQL, Auth, Storage e Realtime em um só serviço. RLS no banco garante segurança em nível de linha sem precisar de middleware de autorização. Realtime nativo para chat sem WebSocket custom. Storage integrado para imagens. Tudo com um único SDK.

Alternativas rejeitadas: Avaliamos Firebase + Firestore, mas a falta de SQL completo e RLS era limitante. Avaliamos também Node.js + Prisma + PostgreSQL self-hosted, mas o custo de infraestrutura e a complexidade de operação não se justificavam.

Cloudflare Workers via OpenNext em vez de Netlify

Por que: Cloudflare Workers oferece infraestrutura de baixo custo no plano Free, deploy automático via GitHub Actions, edge network global e compatibilidade com Next.js App Router via @opennextjs/cloudflare. O subdomínio seeds.expostacker.com.br fica no mesmo ecossistema DNS dos outros projetos.

Alternativas rejeitadas: O projeto estava originalmente no Netlify. A migração para Cloudflare Workers unificou o ecossistema de deploy com os outros projetos do portfolio, eliminou custo e manteve o mesmo Supabase cloud como backend — sem migrar o banco.

RLS em todas as 40 tabelas em vez de middleware de autorização

Por que: Row Level Security no PostgreSQL garante que cada usuário só acessa seus próprios dados e dados públicos. Mesmo se houver uma brecha no middleware, o banco bloqueia o acesso. Policies por usuário com auth.uid() são declarativas e auditáveis.

Alternativas rejeitadas: Autorização apenas no middleware seria mais rápida de implementar, mas criaria um único ponto de falha. RLS no banco é defense in depth — segurança em múltiplas camadas.

Mecânicas de engajamento da comunidade

Conquistas

Sistema de achievements com reactions e categorias

Mural

Mural de conquistas público para reconhecimento social

Ranking

Ranking de membros por engajamento e contribuições

Depoimentos

Testimonials de membros com exibição pública

Conexões

Sistema de networking entre empreendedoras verificadas

Grupos

Grupos de interesse com membership e chat próprio

Indicações

Programa de indicações com código único

Trilhas

Trilhas de aprendizado com lições progressivas

Segurança e acesso

Segurança

  • Row Level Security em todas as 40 tabelas do schema public

  • Autenticação invite-only via magic link (e-mails fora da tabela invites são bloqueados)

  • Service role key nunca exposta client-side, apenas em Server Components e API routes

  • Middleware de proteção de rotas com verificação de sessão Supabase

  • Verificação de role admin em todas as rotas /admin/*

  • Rate limiting via Upstash Redis para endpoints de IA

  • Secrets de runtime configurados no Worker (não apenas no GitHub)

Lições aprendidas

Nem tudo saiu como planejado.

— O maior aprendizado foi que Supabase + Cloudflare Workers é uma combinação poderosa para aplicações full-stack com infraestrutura de baixo custo. A migração de Netlify para Workers via @opennextjs/cloudflare preservou o banco de dados intacto — só mudou a camada de hosting. RLS em todas as 40 tabelas provou que segurança no banco é mais robusta que middleware. E o fato de env vars precisarem estar em dois lugares (GitHub Secrets para build + Worker secrets para runtime) foi uma lição importante: sem o secret no Worker, o app quebra em runtime mesmo com build perfeito.

Quer um produto como esse?

Posso fazer o mesmo para o seu negócio. Vamos conversar.