Construir ou comprar: o custo real de blog, registro de alterações e central de ajuda feitos em casa

saas

“É só um blog, dá para fazer isso em uma sprint.” Essa frase aparece cedo ou tarde em todo canal de engenharia de um SaaS, e até que é meio verdade. Uma tabela de posts, umas duas rotas, um campo de Markdown: uma sprint. O que essa estimativa deixa de fora é tudo o que falta na versão da sprint e tudo o que custam os anos depois dela. Eu construí essa stack, e o Kookee existe porque acho que a maioria das equipes não deveria construí-la. Aqui vai a conta honesta.

No que “é só um blog” se transforma

A versão da sprint não tem um editor digno do nome, então a expansão começa na hora:

  • O editor. O marketing não vai escrever em arquivos Markdown que só vão ao ar por pull request. Um editor de texto rico de verdade (imagens, embeds, blocos de código, um desfazer que funciona) leva semanas de trabalho, mesmo montado sobre um framework de editor open source, e nunca para de pedir atenção.

  • Mídia. Uploads, armazenamento, redimensionamento de imagens, um caminho pela CDN, limites de tamanho. Todo sistema de conteúdo acaba ganhando isso; o seu também vai.

  • Fluxo de trabalho. Rascunhos, publicação agendada, links de pré-visualização e um histórico de revisões que alguém vai implorar para ter na primeira vez que um editor sobrescrever uma hora de trabalho.

  • Os campos em volta do conteúdo. Slugs e a unicidade deles, tags, categorias, metadados de SEO, imagens Open Graph, datas.

  • Depois chega o segundo módulo. Um registro de alterações quer tipos e versões; uma central de ajuda quer categorias e busca; o feedback quer votos, status e comentários. Cada um é “pequeno”, cada um reimplementa a escrita, o armazenamento e a entrega com alguma variação, e cada um vira mais um produto interno, com você como único mantenedor.

Numa estimativa conservadora, blog, registro de alterações e central de ajuda com uma interface de administração usável custam meses de engenharia, não sprints. Com o custo típico de um engenheiro com encargos, isso é dinheiro de verdade antes que um único usuário veja uma página, e essa é a parte barata.

A linha do orçamento que todo mundo esquece: o “para sempre”

A estimativa de construção termina no lançamento. O sistema, não:

  • Segurança e dependências. O seu sistema de conteúdo agora é superfície de ataque (autenticação, uploads, uma API pública) que você corrige no seu próprio ritmo, para sempre. Atualizações de dependências, migrações de framework, a nova versão major da biblioteca do editor, que quebra compatibilidade: impostos anuais.

  • Infraestrutura. Hospedagem, banco de dados, armazenamento de objetos, CDN, monitoramento, backups. Cada item é pequeno; juntos, são uma conta fixa e um plantão fixo.

  • A esteira de funcionalidades. Uma busca que encontra as coisas de verdade (hoje isso significa busca semântica e embeddings), traduções quando você vai para outros países, respostas com IA quando as centrais de ajuda dos concorrentes ganham isso. Cada item é um projeto num sistema que ninguém quer assumir.

A manutenção de uma stack de conteúdo própria pode chegar a semanas de engenharia por ano, sem alarde, espalhadas em “correções rápidas” que nunca são rápidas. O custo mais fundo é o de oportunidade: cada hora ali é uma hora a menos no produto pelo qual os clientes pagam. Infraestrutura de conteúdo é commodity; o seu produto não é. Gastar horas escassas de engenharia com a commodity é o erro de verdade, seja qual for o valor da fatura.

Os motivos para construir mesmo assim

Textos sobre construir ou comprar que nunca reconhecem os motivos para construir são propaganda. Existem razões reais para construir:

  • Conteúdo é o seu produto. Se você é uma plataforma de publicação, uma empresa de documentação, ou se os fluxos de conteúdo são o seu diferencial, construa. A ferramenta genérica vai brigar com você.

  • Restrições rígidas. Ambientes regulados em que o conteúdo precisa ficar na sua infraestrutura, implantações isoladas da internet (air-gapped), regras de residência de dados que um fornecedor não consegue cumprir.

  • Modelos realmente incomuns. O seu conteúdo de fato não se parece com entradas com campos. Antes de concluir isso, porém, veja se os tipos de entrada personalizados de uma plataforma resolvem.

O que não se sustenta: “vamos construir exatamente o que precisamos, nada mais”. A lista de necessidades acima não é excesso de funcionalidades de um fornecedor: é para onde todo sistema de conteúdo converge, porque editores, profissionais de marketing e leitores continuam pedindo as mesmas coisas.

O que a compra deveria entregar

Se você comprar, cobre do fornecedor o padrão que justifica não construir:

  • O seu domínio e o seu frontend. Conteúdo entregue como JSON por uma API e um SDK, renderizado pelo seu app com o seu design system, para que o SEO fique com você e nada pareça enxertado. Se o fornecedor insiste em hospedar as suas páginas, você comprou um construtor de sites, não infraestrutura.

  • Sem lock-in. Tudo pode ser recuperado como JSON documentado com a sua chave de API. É justamente a porta de saída aberta que torna seguro entrar.

  • Tudo num sistema só. Blog, registro de alterações, central de ajuda, feedback, páginas: o valor se multiplica quando o quadro de feedback aponta para a entrada do registro de alterações e a central de ajuda alimenta as respostas da IA, com um painel e uma API em vez de quatro fornecedores costurados, cujas assinaturas somadas costumam passar do preço de uma plataforma única.

  • Um caminho gratuito para começar. Você deveria conseguir validar a integração antes de pagar qualquer coisa.

É nesse formato que o Kookee é construído: um backend de conteúdo com os módulos de que produtos SaaS de fato precisam, um SDK tipado e hooks React para a camada de renderização, um portal hospedado para o primeiro dia e entrega API-first, de modo que o único código seu é a parte fina que sempre foi sua: a renderização.

Um roteiro para decidir

  1. O conteúdo é o seu diferencial, ou há uma restrição rígida em jogo? Se sim, construa, de forma deliberada e com gente dedicada.

  2. Se não, faça um protótipo do caminho de compra: renderize a lista do seu blog e um artigo de ajuda pelo SDK de uma plataforma, no seu domínio. Reserve um dia.

  3. Faça a conta honesta da construção: os meses iniciais mais a manutenção anual, com encargos, contra a assinatura.

  4. Decida uma vez, por escrito, e pare de reabrir a discussão toda vez que alguém disser “é só um blog”.

O blog do tamanho de uma sprint existe: dá para tê-lo até sexta-feira. É com os cinco anos depois dessa sexta que se compara o preço da compra.