Plataforma para criadores · Node.js, PostgreSQL e Next.js

Bioo

Plataforma de página única para criadores e pequenos negócios que reúne links, loja, agenda, cursos, gorjetas, contatos e automações, com pagamentos a criadores, comissão por plano e isolamento de dados no banco.

Papel
Produto próprio: direção de produto, arquitetura e desenvolvimento
Organização e período
Setembro a outubro de 2026
Plataformas
Web responsiva (desktop e celular) · Página pública do criador · Painel do criador
Página inicial do Bioo com o título Um link para tudo o que você faz, campo para escolher o endereço da página e a demonstração de um perfil ilustrativo em moldura de celular.
Página inicial da versão 0.11, com front em Next.js

01 / Contexto

História e problema

Para quem
Criadores de conteúdo, profissionais autônomos e pequenos negócios que precisam de uma página pública com links e também de ferramentas comerciais: vender produtos digitais, agendar serviços, receber gorjetas, captar contatos e responder seguidores.
Problema
A base anterior (0.5) era um editor de página com backend em Cloudflare Pages e D1/SQLite. O diagnóstico de 02/10/2026 apontou credencial de edição guardada no navegador sem expiração, moderação protegida por uma chave administrativa compartilhada sem MFA e autorização feita só na aplicação, sem isolamento no banco. Para virar uma plataforma com dinheiro de terceiros, dados de contatos e equipes, o produto precisava de outra fundação.
Restrições
Escopo sem IA por decisão de produto, confirmação de conta apenas por e-mail, moeda única em dólar, provedores externos isolados em adaptadores e testes com dados sintéticos. Migrações de banco imutáveis, com backup cifrado antes de qualquer mudança.
  1. Até 24/09/2026

    Base 0.5: editor de página em Cloudflare Pages com D1/SQLite.

  2. 02/10/2026

    Diagnóstico do backend e modelo de ameaças com a proposta de migração para Node.js e PostgreSQL com RLS.

  3. 05/10/2026

    Versões 0.6 a 0.10: backend PostgreSQL validado, nova identidade, fluxo de acesso, redes sociais e editor com imagens e planos.

  4. 06/10/2026

    Primeiro commit da 0.11 em repositório privado; fases de base comum, assinatura, vendas e automações concluídas.

  5. 07/10/2026

    Front refeito em Next.js 16, regras de dinheiro, agenda e cursos, indicações, selo de verificação, retenção de dados, dez idiomas e consentimento de cookies.

  6. 08/10/2026

    Etapas 1 a 12 do plano de 24 concluídas, com a versão completa do criador entregue.

02 / Papel

Minha responsabilidade

Liderança e direção

  • Defini o produto, a matriz comercial (Gratuito, Pro a US$ 1,99 e Premium a US$ 4,99 por mês) e as regras de dinheiro: comissão de 10%, 5% e 2% por plano mais as taxas do provedor, reembolso parcial, contestação e troca de plano com prorrateio.
  • Aprovei a migração da base Cloudflare D1 para Node.js e PostgreSQL com RLS a partir do modelo de ameaças, e decidi refazer todo o front em Next.js.
  • Registrei as decisões de produto (indicações, selo de verificação, retenção de dados, idiomas, agenda e cursos) e mantive um único documento de pendências como fonte de verdade para o projeto.
  • Estabeleci a regra de integrar cada provedor externo por um adaptador próprio, com transporte de teste determinístico, e de exigir evidência de teste para cada entrega.

Execução técnica direta

  • Conduzi a construção do servidor Node 24 (API, webhooks, mídia, filas e workers), das 64 migrações PostgreSQL e do front Next.js 16 com next-intl.
  • Revisei e validei as entregas de cada fase por meio das baterias de testes e das avaliações das telas em desktop e celular.

03 / Arquitetura

Arquitetura documentada

O navegador fala com um servidor Node 24 que concentra API, webhooks, mídia e cabeçalhos de segurança, e repassa as páginas ao front em Next.js. Os dados ficam em PostgreSQL 18 privado, acessado por papéis sem permissão de contornar RLS, com conteúdo privado cifrado. Workers separados tratam e-mail, listas, campanhas, redes sociais e conciliação de cobrança. Provedores externos entram por adaptadores isolados.

Arquitetura do Bioo 0.11
  1. Navegador
    • Site e página do criador
    • Painel do criador
  2. Front
    • Next.js 16 + next-intl
    • CSP com nonce
  3. Servidor
    • Node 24: API e webhooks
    • Workers e filas
  4. Dados
    • PostgreSQL 18 com RLS
    • Arquivos cifrados
  5. Provedores
    • Stripe Connect
    • Resend
    • Didit
    • Redes sociais

Camadas e tecnologias

Front
Next.js 16, React 19, TypeScript e Tailwind 4, com Radix UI, React Hook Form, Zod, TanStack Query, dnd-kit para ordenar blocos e Motion para animações com movimento reduzido. Telas do site público, conta, editor, página do criador, telas do visitante e painel. Uma camada de proxy gera um nonce por requisição para a CSP e trata idioma e o endereço público do criador.
Idiomas
Dez idiomas (pt, en, es, fr, de, it, ja, ko, id, tr) com um arquivo por idioma para telas, frases do painel, 49 artigos de ajuda, matriz de planos e e-mails. Detecção na primeira visita, seletor com nomes nativos e idioma salvo na conta. Um verificador confere chaves, marcadores e listas em todos os catálogos.
Servidor
Node 24 com módulos por domínio (autenticação, catálogo, comércio, comissão, agenda, acesso a cursos, indicações, verificação, mensagens, campanhas, redes, consentimento). Sessões opacas em cookie HttpOnly, MFA por TOTP obrigatório para administradores com sessão mais curta, conferência de host, limites de requisição, CSRF e cabeçalhos de segurança. Dependências diretas mínimas: pg, argon2, jose, otpauth e sharp.
Dados
PostgreSQL 18 compilado a partir do código oficial, acessível só por socket local. 64 migrações; RLS habilitada e forçada nas tabelas de proprietário, com mais de 60 políticas, e papéis de aplicação criados sem BYPASSRLS. O contexto do usuário é definido dentro de cada transação para não vazar entre conexões do pool. Conteúdo privado cifrado com AES-256-GCM e hash Argon2id na autenticação.
Pagamentos
Modelo de cobrança de destino da Stripe Connect: a venda é repassada à conta do criador e a comissão do plano mais a taxa estimada do provedor seguem como taxa da plataforma. O webhook confere assinatura, valor, moeda, destino e taxa antes de marcar o pedido como pago. Assinaturas com teste de 30 dias, troca de plano com prorrateio e conciliação de eventos fora de ordem.
Operação e privacidade
Workers de e-mail, listas, campanhas e redes sociais, conciliação de cobrança, limpeza com prazos de retenção definidos, backup cifrado com restauração testada, interruptores de emergência por provedor e por espaço e verificação de prontidão. Consentimento de cookies que bloqueia medição e marketing até a escolha do visitante.

04 / Decisões

Decisões técnicas e compromissos

Isolamento de dados no banco, não só na aplicação

Problema
Na base anterior, a autorização existia apenas no código da aplicação. Em uma plataforma com equipes, contatos e vendas de terceiros, um erro de consulta pode expor dados de outro espaço.
Decisão
Migrar para PostgreSQL com RLS habilitada e forçada nas tabelas de proprietário, papéis de aplicação sem BYPASSRLS e contexto do usuário definido por transação, além da autorização na aplicação.
Motivo
Duas camadas independentes reduzem o impacto de falhas de consulta, e o PostgreSQL oferece esse controle nativamente, o que o D1/SQLite não oferecia.
Compromisso
Mais complexidade em migrações e testes, que precisam cobrir operações sem contexto e tentativas entre proprietários. RLS não protege contra comprometimento total do servidor.

Operações com provedores tratadas como incertas

Problema
Em cobranças, reembolsos e publicações, a resposta do provedor pode se perder depois que a operação já aconteceu. Repetir às cegas pode cobrar ou publicar duas vezes.
Decisão
Persistir a intenção cifrada e a chave de idempotência antes de chamar o provedor, controlar execução por lease com expiração e marcar como desconhecido o resultado sem confirmação, exigindo conferência antes de novo envio.
Motivo
Separar erro definitivo, erro recuperável e resultado desconhecido evita efeitos duplicados em dinheiro e em contas de redes sociais.
Compromisso
Mais estados para a interface e para a operação; algumas situações dependem de conferência manual antes de um novo envio.

Comissão cobrada na própria transação de pagamento

Problema
A comissão varia por plano (10%, 5% e 2%) e precisa ser coerente com o valor efetivamente repassado ao criador.
Decisão
Calcular a comissão pelo plano efetivo na criação do pedido, enviá-la como taxa da plataforma na cobrança de destino e registrar um livro de comissões por pedido; o webhook recusa pagamentos cuja taxa difere da esperada.
Motivo
O repasse e a receita da plataforma saem da mesma transação, o que simplifica conciliação, reembolsos parciais e contestações.
Compromisso
A taxa do provedor é uma estimativa configurável repassada ao criador, e não o valor exato cobrado em cada transação.

CSP estrita com nonce e terceiros só após consentimento

Problema
Páginas de criadores podem usar pixels de medição e players incorporados, o que normalmente leva a políticas de segurança permissivas.
Decisão
CSP com nonce por requisição e strict-dynamic no front; o site do Bioo não carrega terceiros, e Google Analytics, Meta Pixel e players de vídeo e música só entram em páginas que os usam e depois da permissão do visitante. A verificação de identidade usa página hospedada pelo provedor, sem embutir scripts.
Motivo
Mantém a superfície de XSS pequena e faz a escolha de cookies corresponder ao que de fato é carregado.
Compromisso
Cada integração nova exige ajuste explícito da política e teste de navegador; algumas experiências incorporadas exigem um clique a mais.

Provedores atrás de adaptadores com transporte intercambiável

Problema
Testar pagamentos, e-mail e redes diretamente contra os provedores mistura falhas de produto com falhas de configuração e torna difícil reproduzir erros e repetições.
Decisão
Integrar Stripe, Resend, Didit, login Google e Apple e redes sociais por adaptadores isolados, cada um com transporte de teste intercambiável, e cobrir todas as jornadas com testes automatizados.
Motivo
Permite testar regras de negócio, falhas e repetições de forma determinística, inclusive cenários difíceis de provocar no provedor, como respostas perdidas e eventos fora de ordem.
Compromisso
O transporte de teste não substitui a prova ponta a ponta com cada provedor, que exige contas e configuração próprias.

05 / Funcionamento

Fluxo e modelo

Venda de um produto digital (exemplo com dados sintéticos)

  1. Um criador no plano Pro publica um guia em PDF por US$ 20,00.
  2. O visitante informa um e-mail de teste e o servidor registra a intenção de checkout com chave de idempotência.
  3. A cobrança de destino é criada com repasse à conta do criador e taxa da plataforma de 5% mais a taxa estimada do provedor.
  4. O webhook confirma o pagamento; o servidor confere assinatura, valor, moeda, destino e taxa antes de marcar o pedido como pago.
  5. O comprador recebe o link de entrega protegido e o painel do criador mostra bruto, comissão, taxas e líquido.

Modelo lógico simplificado

Espaço de trabalho
id, proprietário, plano, validade do plano, teste usado, estado da cobrança
Item
id, espaço, página, tipo (produto, pedido, agendamento...), conteúdo cifrado, status, versão
Operação com provedor
id, espaço, pedido, tipo (checkout ou reembolso), status (preparada, em execução, desconhecida, concluída...), requisição cifrada
Comissão
pedido, espaço, plano, taxa em pontos-base, moeda, bruto, comissão, taxas do provedor

06 / Evidências

Resultados e próximos passos

Resultados e evidências

  • 08/10/2026: 339 testes automatizados (unidade e PostgreSQL real em bancos descartáveis) e 101 verificações HTTP aprovados.
  • 08/10/2026: 1.058 verificações em baterias de navegador (site e painel, consentimento, agenda, financeiro, indicações, publicação, recuperação, acesso federado e segurança), sem erros de JavaScript ou violações de CSP nas jornadas verificadas.
  • 08/10/2026: auditoria de layout e acessibilidade com 217 verificações em dez idiomas e cinco larguras de tela. É uma verificação automatizada, não certificação de acessibilidade.

Próximos passos

  • Os números de testes são de baterias automatizadas com dados sintéticos e não representam uso real.
  • RLS não protege contra comprometimento total do servidor; ela complementa, não substitui, a segurança da aplicação e da infraestrutura.
  • Próximo passo: revisão jurídica e linguística humana dos textos legais e das traduções.
  • Algumas baterias de navegador tiveram timeouts isolados que passaram na repetição; próximo passo é identificar a causa.
  • Próximo passo: medir em campo as metas de desempenho (LCP até 2,5 s, INP até 200 ms, CLS até 0,1).

07 / Telas

Galeria

Próximo estudo de caso

Caio Andaluz
Todos os projetos