Ontem à noite às 22h eu tinha uma ideia vaga sobre transformar um deployment Directus em um ativo de vendas. Esta manhã às 7h eu tinha um admin funcionando no Railway, três dashboards ao vivo, um blog demo público com cinco posts, um pillar de vendas de 2.400 palavras apresentando toda a solução como um serviço, e três bugs de produção que detectei e corrigi à meia-noite. O custo total da infraestrutura: $5 por mês. O tempo total: aproximadamente nove horas de trabalho focado espalhadas por uma noite e uma madrugada.
Este é o estudo de caso. O que foi construído, o que quebrou, o que aprendi, e os números reais por trás do build. Se você está avaliando se deve encomendar um projeto similar para seu negócio, os dados abaixo são a referência mais honesta que posso oferecer.
O que eu tinha como objetivo
Três objetivos, em ordem de prioridade.
Primeiro, fazer deploy do Directus conectado ao meu banco de dados Supabase Postgres existente. Objetivo: um admin CRUD genérico apontando para os mesmos dados que meu admin Astro customizado já gerencia. Razão: não para substituir o admin customizado (que tem edição inline estilo Monday que a equipe gosta), mas para adicionar a camada de operações que o admin customizado não tem. Bulk edits, saved views, permissões baseadas em role, schema browser, dashboards Insights.
Segundo, configurar os dashboards que queria há seis meses. Três painéis: pipeline de conteúdo (velocidade de publicação do blog, profundidade da fila de tópicos), saúde SEO (posições de ranking, taxa de presença em AI Overview, distribuição de intenção), uso de ferramentas (buscas por ferramenta AEO, buscas por ferramenta com marca, uso de consultor). Números concretos que consigo visualizar de relance às segundas-feiras para saber se o motor está funcionando.
Terceiro, transformar todo o projeto em um ativo de vendas. O admin Directus que faço deploy para mim é idêntico ao que faria deploy para um cliente. Então o deploy em si se torna a demonstração. Um cliente em potencial clica num botão na minha página de vendas, chega num admin Directus real preenchido com dados reais, digita no editor rich-text, vê como funcionam as saved views, depois volta para agendar uma call. Fricção total do loop de demo: aproximadamente quinze segundos desde chegar na página até o editor ao vivo.
Hora 0 a 4: deploy
Plano Railway hobby, template oficial do Directus, deploy com um clique. O template vem com Directus mais Redis mais um banco de dados PostGIS integrado mais um bucket de storage compatível com S3. Tempo total de deploy incluindo configuração: 35 minutos de uma conta Railway em branco até admin logado.
A primeira surpresa: o template Directus conecta seu banco de dados via variáveis de referência apontando para o serviço PostGIS integrado, não via campos individuais de host/porta/usuário/senha. Para redirecionar Directus para meu Postgres Supabase externo, precisei encontrar a variável de connection-string (DB_CONNECTION_STRING) e colar minha URL do Supabase Session pooler com credenciais.
A segunda surpresa: minha senha de banco de dados Supabase continha o caractere "#". Codificado em URL como %23 em uma connection string Postgres. Sem codificação, o parser de URL corta a string no # porque hash significa URL fragment. Directus logou ECONNREFUSED::1:5432 porque caiu na fallback para localhost quando a connection string estava malformada. Meia hora de confusão, depois rotacionei a senha para apenas alfanuméricos e a conexão conectou.
Assim que Directus conectou, todas as 12 tabelas do meu banco de dados Supabase foram auto-importadas como Collections do Directus. Zero migração de schema, zero movimento de dados, zero downtime. O admin Astro customizado e o admin Directus veem os mesmos dados, ambos escrevem neles, ambos refletem imediatamente as mudanças um do outro.
Hora 4 a 12: configurar, configurar, configurar
A maior parte do trabalho não foi deployment. Foi configuração em nível de campo para fazer Directus se comportar como um admin polido em vez de um navegador de banco de dados bruto. Cada coluna precisa de metadados de interface, formatação de display, ordem de sort, largura, grupo e decisões de visibilidade. Directus padrão mostra tudo; a versão polida mostra apenas o que o time precisa.
Três observações dessa fase.
Fazer isso pela interface administrativa do Directus clicando é lento. Aproximadamente dois minutos por campo, noventa-e-poucos campos em doze coleções, tempo total de cliques perto de três horas. Delegava para um agente de IA que dirige navegador (Claude no Chrome) que trocou para a API REST do Directus para configuração em massa. O agente postava chamadas PATCH /fields/{collection}/{field} em sequência, com o objeto meta completo como payload. Três minutos por coleção em vez de quarenta. Toda a fase de configuração foi comprimida de três horas para quarenta minutos.
A abordagem com REST API também me deu reprodutibilidade. Cada PATCH é um equivalente curl que eu poderia re-executar em um deployment fresco do Directus para restaurar a mesma configuração. A configuração é efetivamente código, não uma pilha frágil de cliques na interface.
O último quarto dessa fase foi construir os três dashboards do Insights. Cada painel é uma configuração JSON enviada para POST /panels. Os dashboards chegaram em aproximadamente vinte minutos uma vez que os metadados de campo estavam no lugar. Três boards, seis painéis, dados reais renderizando. Os números que eu tinha estado adivinhando há seis meses estavam finalmente na tela.
Horas 12 a 18: os três bugs que levaram mais tempo
Nenhuma build é real até quebrar em produção. Três bugs surgiram depois que eu enviei para main e atualizei o site ao vivo.
Bug 1: Cena do Spline bloqueada por CSP, com três causas empilhadas
Eu tinha também enviado um pilar web 3D-first com um robô hero NEXBOT do Spline. Depois do deploy, o robô ficou invisível em produção mas funcionava localmente. Três problemas empilhados em sequência.
Um: a tag script usando define:vars foi inline pelo Astro, o que significava que Vite não bundleou o import dinâmico de @splinetool/viewer, o que significava que o especificador de módulo puro era irresolvível no navegador. Dois: depois de consertar isso, o elemento spline-viewer estava dentro de um pai com o atributo hidden no tempo de upgrade, então o custom element Lit foi inicializado com dimensões 0x0 e nunca se recuperou. Três: depois de consertar isso, o visualizador Spline busca seu WASM de modelagem de unpkg.com no tempo de carregamento de cena, que minha CSP não tinha na whitelist. Cada fix revelou o próximo bug. Tempo total de debug: noventa minutos.
Debug apenas em produção é sua própria disciplina. O servidor de desenvolvimento resolve imports puros diferentemente da build de produção. O ambiente de desenvolvimento tem uma CSP padrão mais permissiva. Ambos os bugs eram impossíveis de revelar sem um deploy real em produção. Meu aprendizado: envie para um ambiente real cedo, mesmo quando local funciona bem.
Bug 2: booleano de AI Overview e avg() do Postgres
Um painel do Insights queria mostrar "que percentual de execuções SERP rastreadas exibem uma IA Overview." A tabela seo_serp_runs tem uma coluna booleana ai_overview_present. Instinto ingênuo: fazer avg() dessa coluna, multiplicar por 100, renderizar como percentual.
Postgres lança erro em avg(boolean). A função não existe para esse tipo. Várias tentativas de contorno falharam: Directus não expõe um agregado "percentage", contagem-de-verdadeiro com denominador codificado diverge conforme mais linhas chegam, casting em tempo de consulta não é exposto através das opções do painel do Insights.
O fix que funcionou: adicionar uma coluna gerada ai_overview_present_int que calcula como case when ai_overview_present then 100 else 0 end. avg() sobre uma coluna inteira funciona trivialmente e entrega o percentual direto. Migração SQL de uma linha, zero mudança no código da aplicação.
Bug 3: hosts de imagem em CSP
Seed do blog demo com cinco URLs de foto do Unsplash. O navegador bloqueou silenciosamente porque images.unsplash.com não estava na whitelist do img-src. Imagens de card preto sólido no blog demo público. Adicionei Unsplash ao CSP, as imagens renderizaram, aí percebi que tinha violado minha própria regra inegociável sobre usar FAL para todas as imagens armazenadas em Supabase Storage.
Fix correto: um script que puxa cada linha demo_posts, gera uma fotografia editorial por categoria via FAL flux-pro/v1.1-ultra, re-codifica com sharp para WebP em qualidade 82 max-width 1600, faz upload para um bucket público do Supabase Storage, atualiza featured_image para a URL do CDN storage. Build de vinte minutos, cinco gerações FAL custam menos de uma libra. Removi Unsplash do CSP. Imagens agora vivem na minha própria infraestrutura, sem dependências externas, sem a esteira de atualização-CSP-por-host daqui para frente.
Hora 18 a 24: o pilar de vendas
Com Directus funcionando e o blog demo renderizando corretamente, escrevi o pilar de vendas em /solutions/headless-cms-and-admin-tools/. Quatro tiers de serviço (CMS, admin ops interno, diretórios, bespoke), precificado em USD com GBP entre parênteses, seis FAQs, uma tabela de comparação contra WordPress e HubSpot e Notion e Airtable, uma seção "brief que não vou pegar" para desqualificar clientes de forma errada cedo.
O pilar linkeia direto para a demo ao vivo. Prospects clicando "OPEN THE EDITOR" caem no admin do Directus real com credenciais exibidas que eles colam. Segundos depois estão editando um post real em um editor real. O loop demo é quinze segundos de page-land até edição ao vivo.
Tempo total na página pilar: noventa minutos de escrita mais trinta minutos de schema markup, links internos e polish visual. A página em si levou menos tempo que dois dos três bugs.
Números
Detalhamento do custo de construção, já que este é o post de estudo de caso e essa é a pergunta que prospects vão fazer.
Plano Railway Hobby para Directus + Redis + bucket: $5 por mês, faturado mensalmente. Primeiros 30 dias grátis.
Supabase Postgres: infraestrutura existente, sem custo novo. Usando o plano Pro já em torno de $25 por mês para o banco de dados.
FAL API para cinco imagens hero: menos de uma libra no total, aproximadamente $1 USD.
DataForSEO para preenchimento retroativo de 42 keywords com volume de busca + intent + dificuldade: $0,04 no total.
Meu tempo, ponta a ponta incluindo os bugs e escrita: nove horas de trabalho focado. Na minha taxa diária de consultoria de cerca de $1.500 por dia, isso é aproximadamente $1.700 em custo de oportunidade.
Desembolso total em dinheiro para lançar o ativo de vendas funcionando: aproximadamente $6 em infraestrutura marginal mais $1 em taxas de API. Custo verdadeiro incluindo tempo: aproximadamente $1.700.
Comparação de referência: uma agência cotando um engajamento de "construção de ferramenta admin de CMS headless" normalmente cobraria $8.000 a $15.000 USD pelo escopo equivalente. Estou cobrando $8.000 a $19.000 USD na minha própria página de serviço. O gap entre custo-para-construir e preço-para-vender é o motor econômico inteiro do trabalho de agência. O estudo de caso é a prova de que o número de custo-para-construir é real.
O que isso prova para um cliente prospectivo
Três coisas, todas verificáveis nos próximos dez minutos.
Primeiro, a construção é real. Clique no botão OPEN THE EDITOR na página de vendas. Digite no editor de rich-text. Agende um post. Olhe os dashboards. A coisa existe. Não é um mockup, não é um arquivo Figma, não é uma screenshot. É o mesmo software que eu implantaria para seu negócio.
Segundo, a velocidade é real. Vinte e quatro horas de "ideia vaga" para "ativo de vendas implantado em produção com demo ao vivo." Um engagement de cliente não se movimentaria nessa velocidade porque engagements de cliente incluem discovery, revisão de design, aprovações de stakeholders e auditorias de segurança. Mas a velocidade de construção subjacente é o que determina se um timeline de seis semanas é honesto ou otimista. Vinte e quatro horas de esforço de construção solo correspondem a aproximadamente três semanas de tempo de engagement padrão de agência uma vez que o overhead é considerado. Essa matemática é o que produz o timeline de tier-1 de seis a oito semanas.
Terceiro, os modos de falha são reais. Três bugs de produção foram capturados e corrigidos em tempo real. Problemas de CSP, dynamic-import bundling, aritmética de generated-column. Estes são os mesmos bugs que aparecem em engagements de cliente. O fato de eu tê-los capturado e resolvido em um site ao vivo é a demonstração real de competência. Um case study polido sem bugs seria o suspeito.
O que eu faria diferente
Três pequenas reflexões, em ordem de utilidade.
Eu teria começado com o script de geração de imagem FAL antes do workaround do Unsplash. A dança de atualização-então-reversão de CSP custou dez minutos de churn desnecessário. A regra inegociável sobre imagens FAL existe exatamente por esse motivo e eu deveria tê-la escutado primeiro.
Eu teria usado a abordagem da REST API para configuração do Directus desde o início em vez de tentar o click-through da UI. A sequência de chamadas REST conduzida por agent foi três vezes mais rápida e produziu configuração reproduzível. A lição se generaliza além de Directus: qualquer admin que exponha uma REST API abrangente deve ser configurado através dessa API em vez de através de sua UI.
Eu teria escrito o post de case-study mais cedo. Este post está sendo escrito aproximadamente doze horas após a construção terminar. Na época em que estou escrevendo isto, alguns dos modos de falha já estão desaparecendo da memória. O case study honesto é aquele escrito no mesmo dia da construção, enquanto os bugs ainda estão frescos o suficiente para ser descritos com precisão.
Para onde ir a seguir
Se você está avaliando se seu negócio deve encomendar uma build similar, o loop de demo é o caminho mais rápido para uma resposta útil. Abra /solutions/headless-cms-and-admin-tools/, clique no botão de demo, faça login com as credenciais exibidas, passe quinze minutos clicando ao redor. Ao final você terá uma noção clara de se essa forma de ferramenta se encaixa no seu time ou não.
Se sim, agende a chamada de trinta minutos vinculada naquela página. Me conte sua stack existente, o tamanho do seu time, sua forma de dados. Ao final da chamada você tem uma escolha de tier, uma faixa de preço, e uma janela de entrega. A maioria dos engajamentos que pego duram seis a doze semanas a $8,000 a $50,000 USD dependendo do escopo. A metade que não pego, eu te conto o motivo na chamada.
Se você quer o pitch de vendas completo, a página pilar está em /solutions/headless-cms-and-admin-tools/. Se você quer pular direto para a demo ao vivo, as credenciais estão naquela página. Se você quer o próximo case study, o próximo blog post provavelmente será sobre uma build de fabricante do corredor asiático ou o mesmo padrão aplicado a um vertical diferente. Me diga qual é mais útil.