Por que construí o aryrabelo.com do zero
Linktree é feio e caro para o que entrega. Cada shortener de link que eu testei guardava os dados dos cliques no banco deles. Meu portfólio ficava numa página estática que eu raramente atualizava, porque atualizar exigia deploy. E quando eu fazia campanha no Instagram pedindo “COMENTE: [palavra]”, o lead chegava no DM e sumia: sem histórico, sem pipeline, sem jeito de medir o que funcionou.
Isso é o contexto. Construí o aryrabelo.com pra resolver esses quatro problemas no mesmo lugar.
Quatro superfícies, um codebase
Captura de leads. Páginas em /g/[palavra] que entregam o ímã de conteúdo (PDF, template, artigo) e registram o contato no banco. Quando eu posto no Instagram “COMENTE: ferramentas” e mando o link no DM, a pessoa cai numa dessas páginas, preenche o e-mail, e o lead vai pro Cloudflare D1, não pra uma plataforma SaaS que vai me cobrar pra exportar mais tarde.
Encurtador rastreável. Todo link que eu divulgo passa por /r/[slug]. Cada clique é registrado com origem, horário e slug. Se eu postar o mesmo conteúdo no Instagram e no LinkedIn com slugs diferentes, eu sei qual canal converteu, sem depender de UTMs manuais que qualquer pessoa pode remover da URL.
Link-in-bio próprio. Em /l/[slug] tenho páginas com seções configuráveis no painel admin, substituindo Linktree e Liinks. Sem marca d’água, sem limite de links, com analytics que ficam no meu banco.
Portfólio bilíngue e este blog. PT-BR para audiência brasileira, inglês para clientes e parceiros internacionais. Mesmo conteúdo, escrito nativamente em cada língua. Não traduzido palavra por palavra, cada versão foi escrita do zero na língua certa.
“Link-in-bio” é aquela página que você coloca no perfil do Instagram porque o Instagram só permite um link. “Captura de leads” é quando você pede o e-mail de alguém em troca de algo útil, como um PDF ou guia. “Self-hosted” significa que o site roda em infraestrutura que eu controlo diretamente, não numa plataforma que pode mudar de preço, mudar de política ou simplesmente sumir amanhã.
Por que não usar ferramentas prontas
A questão não é só custo. Linktree Pro, um shortener com analytics e uma plataforma de captura de leads juntos saem bastante por mês, e no plano gratuito da Cloudflare esse mesmo conjunto de funcionalidades sai zero de infra. Mas o ponto mais importante é dependência: quando eu dependo de três plataformas separadas pra montar meu funil, qualquer mudança de preço, mudança de API ou produto que encerra quebra o fluxo. Com codebase próprio, eu controlo o que muda e quando.
Tem outro ponto que fica claro com o tempo: cada plataforma que você usa tem os dados dos seus usuários no banco delas. Não no seu. Portfólio de leads, histórico de cliques, comportamento de acesso. Tudo fica preso no ecossistema de outra empresa.
Cada lead que entra via /g/[palavra] vai pro seu banco de dados, não pro banco de uma plataforma SaaS. Isso parece detalhe até o dia que a plataforma muda a política de exportação, aumenta o preço ou simplesmente some. Ter o controle dos dados do seu funil é vantagem competitiva concreta, principalmente quando você começa a conectar captura, qualificação e CRM num pipeline só, sem depender de integrações de terceiro que cobram por cada zapier no meio.
A stack, e o porquê de cada escolha
Astro 6 no modo SSR com Tailwind v4 e MDX para o blog e as páginas de conteúdo. Hono rodando no mesmo Worker da Cloudflare para as rotas dinâmicas: admin, encurtador, lead magnets. oRPC conectando front e back com contratos de tipo compartilhados, sem schema separado, sem cliente gerado. Drizzle ORM sobre Cloudflare D1 (SQLite na edge). Better Auth para sessão e OAuth.
O monorepo usa Turborepo com pnpm. Um turbo build e tudo vai pro ar.
A decisão central foi manter tudo no mesmo repositório e no mesmo runtime. Quando eu preciso de uma nova rota de API, ela fica ao lado do componente que a consome, com os tipos compartilhados, sem contrato OpenAPI intermediário, sem geração de código. Isso não é elegância por elegância: é o que torna a manutenção viável quando você é o único desenvolvedor do projeto.
A Cloudflare foi escolha natural dado que é onde o Worker roda, o D1 fica, o KV fica e o deploy é um comando. O plano gratuito aguenta tráfego razoável sem custo de infra.
Astro 6 usa output: 'server' com prerender seletivo por rota. O Hono fica no mesmo entrypoint do Worker e lida com /admin, /r/*, /g/*, /l/* e a API interna. O oRPC gera contratos de tipo direto dos procedures TypeScript, sem geração de código ou schema intermediário. Drizzle sobre D1 dá migrations versionadas e queries typesafe sem ORM pesado. Better Auth cuida de sessão e OAuth sem banco separado, uma tabela de sessões no próprio D1 já resolve.
Surfaces editáveis sem redeploy
O painel em /admin permite criar e editar short links, páginas de lead magnet e link-in-bios sem nenhum deploy. Entro, crio um slug, e em 30 segundos a URL já funciona. Esse foi um requisito que eu tinha desde o início: não quero fazer deploy toda vez que precisar de um link novo pra uma campanha nova.
Está no começo, mas é o núcleo do que vai crescer. Posts sobre IA aplicada e automação em breve. Por enquanto, veja os projetos.
As decisões que seguraram este site são as mesmas que aparecem dentro de uma empresa: onde os seus dados moram, qual stack o custo real justifica, como traduzir uma escolha técnica em linguagem que a diretoria entende. Quando esse raciocínio encontra o processo repetitivo do seu negócio, vira consultoria. Veja como isso funciona.
Eu também escrevo a Em Paralelo, uma edição por semana sobre a engenharia que move o negócio: IA, dev tooling, performance. Sem hype, com a minha leitura do que importa. Assine a Em Paralelo.