Titularidade de domínio e código em projeto de software: o que precisa estar no seu nome

**Titularidade de domínio e código em projeto de software: em nome de quem está cada conta**

**A titularidade de domínio e código em projeto de software não é detalhe contratual: é o que define quem consegue recuperar um acesso sozinho.** Os ativos ficam no nome de quem contrata; o fornecedor entra como usuário convidado, com permissão para trabalhar — não como dono da conta.

Titularidade, aqui, tem uma definição prática: quem consta como proprietário da conta onde o ativo vive. Em termos operacionais, quem consegue transferir, apagar ou recuperar o acesso sem depender da boa vontade de ninguém.

A decisão custa pouco no começo e costuma ser cara de reverter depois. São cinco ativos que precisam de titular declarado antes da primeira linha de código:

— **Domínio e DNS** — o endereço do site e a configuração que diz para qual servidor ele aponta.

— **Código-fonte** — o repositório onde o projeto fica versionado.

— **Hospedagem** — o servidor onde a aplicação roda.

— **Banco de dados e dados operacionais** — cadastros, pedidos, mensagens de formulário.

— **Contas de terceiros** — Meta Pixel, WhatsApp Business, e-mail transacional.

Duas coisas se misturam nessa conversa e precisam ficar separadas: **propriedade** (de quem é) e **operação** (quem mexe no dia a dia). São independentes. Dá para ser titular de tudo e não operar nada — é justamente o arranjo indicado para quem não tem equipe técnica interna.

Este texto não é modelo de contrato nem consultoria jurídica. É a lista de decisões técnicas que precedem qualquer cláusula: se elas estiverem erradas, nenhuma redação de contrato resolve o problema prático de recuperar um acesso.

O [escopo do projeto](/blog/escopo-de-projeto-de-software/) descreve o resultado esperado. A titularidade descreve onde esse resultado vai morar.

**Domínio e DNS: a conta que controla todo o resto**

Domínio é o endereço — projask.app, por exemplo. Registrador é onde esse endereço fica registrado: para domínios .br, o registro é feito diretamente no Registro.br; para .com, .app e afins, em registradores internacionais.

No .br há um detalhe que muita gente descobre tarde: o registro tem um campo de titular, vinculado a um CPF ou CNPJ, e é esse campo que define a quem o domínio pertence. Trocar o titular depois é um procedimento formal, com documentação — não um clique. Por isso vale abrir o registro já com os dados de quem contrata.

DNS é o sistema que traduz o domínio no endereço do servidor — na prática, a tabela de registros que diz para onde o site aponta. Quem controla essa tabela aponta o site para onde quiser. Não é preciso ter o código nem o servidor para tirar um site do ar: basta ter o DNS.

O padrão saudável é simples. A conta no registrador é aberta com o e-mail e o CPF/CNPJ de quem contrata. O fornecedor recebe acesso delegado à zona de DNS, ou apenas as instruções de apontamento para executar.

O padrão problemático também é simples: o domínio registrado na conta do fornecedor “para facilitar”. Funciona enquanto a relação vai bem. Quando ela acaba — por preço, por prazo, por qualquer motivo — vira negociação, e você negocia do lado fraco.

Domínio tem validade e expira. Se ninguém renova, o site cai e o endereço pode ser registrado por terceiros. Defina por escrito quem paga a renovação e quem recebe o aviso de vencimento — e confira se o e-mail de contato do registro é seu, não do fornecedor. Aviso que chega numa caixa de entrada que você não lê é o mesmo que aviso nenhum.

O certificado HTTPS — o que permite a conexão criptografada entre visitante e servidor, o cadeado do navegador — hoje costuma ser emitido e renovado de forma automática pelo próprio servidor, sem custo. É operação, não posse. Mas a emissão exige provar controle sobre o domínio, por registro de DNS ou pelo servidor para onde ele aponta: sem o DNS na sua mão, você não reemite o certificado em outro lugar.

**Código, banco de dados e contas de terceiros: onde cada ativo deve ficar**

**Repositório de código** é o lugar onde o código-fonte fica versionado, com histórico de cada alteração — GitHub e GitLab são os mais usados. Ele deve estar na organização ou na conta de quem contrata, com o fornecedor adicionado como colaborador.

Vale distinguir duas coisas que soam iguais: receber o site no ar não é receber o código. O site publicado é o resultado; o código-fonte é o material com que ele foi feito. Sem o código, qualquer alteração futura depende de quem o tem — ou de refazer.

E há o que o repositório não resolve sozinho: pagar pelo projeto não transfere automaticamente os direitos sobre o código. A cessão, ou a licença de uso, precisa estar escrita no contrato. O repositório na sua conta garante o acesso ao material; o contrato define o que você pode fazer com ele.

**Hospedagem** pode ser compartilhada, uma VPS (servidor virtual alugado, com acesso administrativo) ou uma plataforma gerenciada. Em qualquer uma delas, a regra é a mesma: conta no seu nome e no seu cartão significa que o servidor não some junto com o fornecedor.

**Banco de dados e dados operacionais** são seus por definição — o que o sistema guarda é informação do seu negócio. O que importa é a via de saída: um dump (arquivo de exportação do banco inteiro) ou um export em CSV, que você consiga solicitar e receber quando quiser, sem que isso vire um projeto à parte.

**Contas de terceiros** seguem a mesma lógica. O Meta Pixel fica no Gerenciador de Negócios da sua empresa, com o fornecedor adicionado como parceiro. No WhatsApp, separe os dois casos: o aplicativo WhatsApp Business roda sobre um número de telefone, e essa linha precisa estar no nome da empresa; a versão por API fica vinculada ao Gerenciador de Negócios, que também deve ser seu.

O **e-mail transacional** — o serviço que dispara mensagens automáticas do sistema, como confirmação de cadastro — fica na sua conta, porque a reputação do domínio remetente é sua e acompanha você. A autenticação desses envios (SPF e DKIM, registros que autorizam quem pode enviar em nome do seu domínio) mora no seu DNS, o que reforça o ponto anterior.

O número de WhatsApp Business é um ativo comercial, com histórico de conversa acumulado. Número na linha do fornecedor é uma dependência difícil de reverter: seu cliente já aprendeu aquele contato, salvou na agenda e volta por ele.

O funil que usa esses ativos está detalhado no artigo sobre [landing page com WhatsApp e Meta Pixel](/blog/landing-page-que-converte-whatsapp-pixel/) — e, quando a venda é consultiva, no artigo sobre [landing pages B2B que convertem visita em agendamento](/blog/landing-pages-b2b-que-convertem-demonstracao-tecnica/).

**O que a mensalidade cobre: infraestrutura ou serviço de operação**

Mensalidade de site costuma somar duas naturezas de custo bem diferentes num número só.

Natureza: Infraestrutura · O que é: Domínio, servidor, serviços pagos de terceiros · Se você trocar de fornecedor: Continua existindo, no mesmo valor

Natureza: Serviço de operação · O que é: Deploy, monitoramento, backup verificado, correção de defeito, pequenas evoluções, atualização de dependências por segurança · Se você trocar de fornecedor: Some com o fornecedor

Deploy, aqui, é o ato de publicar uma nova versão do sistema no servidor — o último passo do ciclo descrito em [da descoberta ao deploy](/blog/da-descoberta-ao-deploy-com-fabrica-de-software/). É trabalho humano recorrente, não item de prateleira.

A pergunta que separa as duas naturezas é uma só: “se eu levar o projeto para outro fornecedor amanhã, quais desses itens eu continuo pagando do mesmo jeito?”. O que sobra é infraestrutura. O que some é serviço.

Peça a mensalidade discriminada em duas linhas, não em um valor único. Não porque valor único seja desonesto — não é —, mas porque só o detalhamento permite comparar propostas e decidir o que faz sentido internalizar. As faixas do projeto em si estão no [guia de quanto custa criar um site](/blog/quanto-custa-criar-um-site-em-2026/); aqui o assunto é o que vem depois da entrega.

Há um caso em que manter a infraestrutura na conta do fornecedor faz sentido: projeto pequeno, sem ninguém do seu lado para administrar cartão, renovação e recuperação de senha. É escolha legítima — desde que declarada no começo, e não descoberta no dia em que você precisa sair.

Existe ainda uma terceira coisa que a mensalidade às vezes esconde: licença de uso. Se o que você paga é aluguel de uma plataforma proprietária, parar de pagar significa perder o site.

**Site próprio e site em plataforma fechada: a diferença aparece na saída**

Plataforma fechada é um construtor ou sistema proprietário onde o site só funciona dentro daquele ambiente: você não recebe o código e não consegue hospedar em outro lugar.

O que você recebe · Site próprio: Código-fonte, banco e infraestrutura reproduzível · Plataforma fechada: Uma assinatura ativa

Se você parar de pagar a mensalidade · Site próprio: Continua no ar enquanto domínio e servidor estiverem pagos · Plataforma fechada: O site sai do ar

Como é a saída · Site próprio: Migra de servidor · Plataforma fechada: Exporta conteúdo, não o site — e às vezes nem isso

Plataforma fechada é a escolha certa e honesta em alguns cenários: validação rápida de uma ideia, orçamento muito curto, ninguém disponível para operar nada. O custo aparece depois, quando o negócio cresce e passa a precisar de integração com outros sistemas, de [publicar conteúdo com estratégia própria de busca](/blog/seo-de-conteudo-para-marcas-de-tecnologia-e-servicos/) ou de controle fino de SEO técnico — o tipo de controle sobre HTML e build discutido no artigo sobre [SEO em SPA React](/blog/seo-para-spas-react-sem-next/).

O ponto de virada é prático, não ideológico: a partir do momento em que o site passa a gerar oportunidade comercial de verdade, o custo de estar preso supera a conveniência de não administrar nada.

**Titular de tudo ou fornecedor operando tudo: o trade-off honesto**

**Arranjo A — o fornecedor opera tudo.** Menos trabalho para você, um único interlocutor, renovações e incidentes resolvidos sem te acionar. O preço é dependência: a velocidade de sair depende da boa vontade do outro lado.

**Arranjo B — você é titular de tudo.** Autonomia real, mas a gestão de acessos passa a ser sua: cartão válido no provedor, e-mails de renovação lidos por alguém, senhas em gerenciador de senhas e não em conversa de WhatsApp, acesso revogado quando um funcionário sai.

Ser titular sem gerenciar é o pior dos dois mundos: conta no seu nome que ninguém acompanha, cartão vencido, domínio expirado — e o fornecedor sem permissão para resolver.

O meio-termo costuma resolver: titularidade sempre sua, operação contratada com o fornecedor, acesso administrativo dele como convidado, revogável a qualquer momento sem derrubar nada.

A higiene de acesso que sustenta esse arranjo é curta:

— Conta principal com autenticação em dois fatores.

— E-mail de recuperação corporativo, não o pessoal de quem abriu a conta.

— Revisão periódica de quem ainda tem acesso e a quê.

Operação séria é trabalho recorrente e medido, não disponibilidade vaga — é o que está descrito em [DevOps e observabilidade](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/), e é exatamente isso que se compra quando se paga operação.

**Roteiro de handover: trocar de fornecedor sem refazer o projeto**

Se a titularidade estava certa desde o começo, handover é transferência de acesso, não reconstrução. Refazer do zero costuma ser sintoma de titularidade errada — ou de código que ninguém mais consegue entender.

1. **Inventário.** Listar cada ativo, onde ele está hospedado e em qual conta. Quem não tem esse inventário não sabe o tamanho do problema que tem.

2. **Recuperar o que está fora.** Transferir o domínio para o seu registrador, criar a conta no provedor de hospedagem no seu nome, abrir a organização no serviço de repositório.

3. **Exportar dados.** Dump do banco e export dos registros de formulário, com data e conferência de que o arquivo abre e está completo. Backup que ninguém testou não é backup.

4. **Receber o mínimo operável.** Código no repositório, variáveis de ambiente e segredos entregues por canal seguro, instruções de build e deploy, e onde estão os backups.

5. **Virada e revogação.** Reduzir antes o TTL do DNS (o tempo que o apontamento antigo fica em cache), subir em infraestrutura sua, apontar o DNS, confirmar HTTPS válido — e só então revogar os acessos do fornecedor anterior. Nessa ordem.

Se você já está no cenário ruim, com tudo na conta do fornecedor, peça a transferência por escrito e de forma cordial antes de anunciar a troca. Acesso e relação costumam andar juntos, e a sequência inversa encarece a saída.

O handover de saída se combina na entrada — é um dos itens do [checklist para escolher uma fábrica de software](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/).

**Perguntas para fazer antes de assinar — e o que a Projask pratica**

Copie e mande para o fornecedor:

— Em qual conta o domínio é registrado e quem paga a renovação?

— Para onde vai o código e quem tem acesso?

— Em nome de quem fica a conta da hospedagem?

— Como eu exporto o banco de dados e os registros de formulário?

— Em qual Gerenciador de Negócios ficam o Meta Pixel e o WhatsApp Business?

— A mensalidade é infraestrutura ou operação, e quanto é cada parte?

— Se eu sair, o que exatamente eu recebo?

Nenhuma dessas perguntas é agressiva, e a reação a elas já é informação. Fornecedor que responde sem rodeio costuma ter o processo organizado. Resposta evasiva sobre domínio merece atenção antes de qualquer assinatura.

O que a Projask pratica: deploy em VPS com domínio e HTTPS gerenciados, e titularidade dos ativos no nome de quem contrata. A operação é contratada à parte de quem é dono do quê — são duas conversas diferentes, e continuam diferentes até o fim do contrato.

Se você quer conferir a titularidade do que já tem hoje, ou combinar isso antes de começar um projeto novo, a conversa é pelo WhatsApp.

**Em qual conta o domínio do meu site deve ser registrado e por que isso importa?**

A conta no registrador deve ser aberta com o e-mail e o CPF/CNPJ de quem contrata, e o fornecedor recebe acesso delegado à zona de DNS ou apenas as instruções de apontamento. Importa porque quem controla o DNS aponta o site para onde quiser: não é preciso ter o código nem o servidor para tirar um site do ar, basta ter o DNS. No .br, o registro tem um campo de titular vinculado a CPF ou CNPJ, e trocar esse titular depois é um procedimento formal, com documentação — não um clique.

**Quem é o dono do código depois que eu pago pelo projeto?**

Pagar pelo projeto não transfere automaticamente os direitos sobre o código: a cessão, ou a licença de uso, precisa estar escrita no contrato. São duas camadas distintas — o repositório na sua conta garante o acesso ao material, e o contrato define o que você pode fazer com ele. Vale lembrar também que receber o site no ar não é receber o código: o site publicado é o resultado, o código-fonte é o material com que ele foi feito.

**O que exatamente a mensalidade cobre: infraestrutura ou serviço de operação?**

Costuma cobrir as duas naturezas em um número só. Infraestrutura é domínio, servidor e serviços pagos de terceiros — continua existindo, no mesmo valor, se você trocar de fornecedor. Serviço de operação é deploy, monitoramento, backup verificado, correção de defeito, pequenas evoluções e atualização de dependências por segurança — some junto com o fornecedor. A pergunta que separa as duas é: se eu levar o projeto para outro fornecedor amanhã, quais desses itens eu continuo pagando do mesmo jeito? Peça a mensalidade discriminada em duas linhas, porque só o detalhamento permite comparar propostas.

**O Meta Pixel e o WhatsApp Business devem ficar na conta de quem?**

Na conta da sua empresa. O Meta Pixel fica no Gerenciador de Negócios da empresa, com o fornecedor adicionado como parceiro. No WhatsApp, separe dois casos: o aplicativo WhatsApp Business roda sobre um número de telefone, e essa linha precisa estar no nome da empresa; a versão por API fica vinculada ao Gerenciador de Negócios, que também deve ser seu. O número é um ativo comercial, com histórico de conversa acumulado — número na linha do fornecedor é uma dependência difícil de reverter, porque seu cliente já salvou aquele contato na agenda.

**Quem renova o domínio e o que acontece se ele vencer?**

Domínio tem validade e expira. Se ninguém renova, o site cai e o endereço pode ser registrado por terceiros. Defina por escrito quem paga a renovação e quem recebe o aviso de vencimento, e confira se o e-mail de contato do registro é seu, não do fornecedor — aviso que chega numa caixa de entrada que você não lê é o mesmo que aviso nenhum. Já o certificado HTTPS hoje costuma ser emitido e renovado de forma automática pelo próprio servidor, sem custo: é operação, não posse. Mas a emissão exige provar controle sobre o domínio, então sem o DNS na sua mão você não reemite o certificado em outro lugar.