# Criei um produto com IA — como melhorá-lo sem estragar o que funciona > Como manter um produto criado com IA: git, reversão, testes, segredos, alojamento, cópias de segurança e seis prompts para melhorar sem estragar. Source: https://ailoot.ai/blog/pt-pt/ai-product-maintenance-after-launch/ Canonical: https://ailoot.ai/blog/pt-pt/ai-product-maintenance-after-launch/ Language: pt-PT Publisher: Ailoot (https://ailoot.ai/) Translation: guide-033 Revision: sha256-f16f0d4b1517d16d824669a4230b731a39866f48125733179bf7991e78f704d6 Saiba mais sobre como trabalhar com modelos na [documentação da Ailoot](https://ailoot.ai/docs/). ## Porque é que o trabalho mais dispendioso começa depois do lançamento?
Principal conclusão Criar um produto com IA é a parte menor do trabalho. De cada dólar investido no desenvolvimento com IA, apenas 18 cêntimos chegam a um produto acabado, enquanto 44 cêntimos são gastos a corrigir erros criados pela própria IA. Tudo isto acontece depois do lançamento. É a manutenção, e não a criação, que consome a maior parte do dinheiro e dos nervos.
Criou uma aplicação numa noite, publicou um link e enviou-o aos amigos. Funciona. Depois, uma semana mais tarde, aparece a primeira pessoa a usá-la a sério, clica em algo da forma errada e metade das funcionalidades deixa de funcionar. Pede ao Claude que corrija o problema — ele corrige uma coisa e estraga outra. Soa-lhe familiar? É aqui que surge a questão principal: o que fazer depois de lançar um produto, quando a euforia do primeiro protótipo funcional já passou e ainda tem de o manter de alguma forma? Poderíamos chamar-lhe vibe coding para adultos. Criar é entusiasmante e rápido. A manutenção exige cabeça fria: percebe o que está a alterar e mantém tudo sob controlo. A maioria das pessoas falha nesta segunda parte porque ninguém a prepara para isso. Um estudo do setor analisou mais de um milhão de alterações de código de 2 444 equipas e calculou para onde vai realmente o dinheiro gasto no desenvolvimento com IA. Eis o panorama: | Para onde vai o dólar | Montante | O que significa na prática | |----|----|----| | Chegou ao produto | **18 cêntimos** | Funcionalidades que realmente funcionaram para os utilizadores | | Correção de erros da IA | 44 cêntimos | Corrigir o que a IA já escreveu para impedir que tudo se desmorone | | Retrabalho | 27 cêntimos | Reescrever código criado pela IA que não cumpriu a tarefa | | Revisão | 11 cêntimos | Compreender o código e procurar erros | O guia [«O custo oculto do vibe coding»](https://ailoot.ai/blog/pt-pt/custo-vibe-coding-tempo/) explica estes valores com mais detalhe. Aí, a questão era aquilo por que está a pagar. Aqui, a questão é diferente: 44 cêntimos de cada dólar vão para a correção de erros — e este artigo inteiro é sobre impedir que essa parcela aumente. O trabalho de a manter sob controlo chama-se manutenção. A diferença entre alguém que faz vibe coding para adultos e alguém que se limita a tomar conta de uma rede neuronal torna-se visível depois do lançamento. A base de código da primeira pessoa cresce, são feitas melhorias e nada se estraga. Um mês depois, o produto da segunda transformou-se numa geringonça cheia de fugas em que tem medo de mexer. A seguir, explico como ficar no primeiro grupo. ## O que se estraga realmente: 5 desastres após o lançamento
Principal conclusão Os produtos criados com IA avariam sempre devido à mesma pequena lista de problemas: há fugas de chaves e bases de dados, a IA apaga a produção e desconhecidos cobram dinheiro aos clientes. Cada desastre tem uma medida preventiva.
São análises públicas de incidentes reais de produtos criados com IA, com números e datas. Pense nelas como um mapa de um campo minado — cada mina já explodiu para alguém e sabe-se como contorná-la. | O que aconteceu | Como exatamente | O que teria evitado | |----|----|----| | **Fugiram 1,5 milhões de chaves** | A chave pública da base de dados estava diretamente no código da página e o acesso à base de dados estava aberto, sem palavra-passe | Ativar a segurança ao nível das linhas (RLS) em todas as tabelas | | **170 aplicações expostas** | As aplicações ligavam-se diretamente à base de dados a partir do navegador, usando uma chave pública, sem regras de acesso definidas | Verificar as permissões de acesso à base de dados antes de vender e não confiar nas predefinições | | **A IA apagou a base de dados de produção** | Foi dado ao agente acesso à base de dados de produção e ele apagou-a, apesar de ter sido proibido de o fazer | Isolar fisicamente a base de dados de produção do ambiente do agente | | **Chaves de pagamento no navegador: \$87,500** | As chaves do sistema de pagamentos foram parar ao código da página; foram encontradas e foram cobrados valores a 175 clientes | Guardar os segredos apenas no servidor, nunca no navegador | | **72 000 fotografias e documentos expostos** | O armazenamento de ficheiros não tinha palavra-passe, pelo que qualquer pessoa com o link podia descarregar selfies e documentos de identificação | Exigir autenticação para o armazenamento de ficheiros por predefinição | Os cinco casos têm a mesma causa fundamental. Por predefinição, a IA faz com que as coisas funcionem agora, não com segurança daqui a um mês, sob carga. Não consegue ver a diferença enquanto desenvolve no seu computador. Ela torna-se evidente quando aparece o primeiro desconhecido com más intenções. O problema não é não escrever o código à mão — muitas pessoas trabalham assim. O problema é não perguntar: «A base de dados está segura?» A seguir, vou mostrar-lhe um prompt que faz essa pergunta por si. ## A primeira rede de segurança é o git e a reversão para «como estava ontem»
Principal conclusão A principal rede de segurança após o lançamento é poder reverter qualquer alteração. Há duas camadas que funcionam em conjunto: o git, como histórico permanente do projeto, e os instantâneos locais do Claude Code, para um rápido «anular a última coisa». Um repositório privado e um ficheiro de segredos na lista de ficheiros ignorados são o mínimo necessário antes de deixar outras pessoas usar o produto.
Quando o Claude estraga alguma coisa, precisa de um botão para «voltar a pôr tudo como estava ontem». Tecnicamente, esse botão chama-se git e é mais simples do que parece. Há três termos que uma pessoa que não programa precisa de compreender: 1. **Repositório** — a pasta do projeto guardada na nuvem (normalmente no GitHub). Uma cópia de todo o seu código que não está apenas no seu computador. 2. **Commit** — um ponto de regresso. Na prática, está a dizer ao código: «guarda neste estado». Cada commit é um marco ao qual pode voltar. 3. **Deploy** — uma transferência. O código estava localmente, no seu computador, e só funcionava para si. O deploy envia-o para um servidor externo, para que funcione para todos. Desde que tenha pontos de regresso recentes, pode reverter qualquer problema com uma frase. Literalmente.
Prompt: Reverter para uma versão funcional ``` Estraguei alguma coisa — ontem tudo funcionava, mas hoje já não funciona. Encontra o último commit em que estava tudo bem, mostra-me o que mudou desde então e reverte o projeto para esse estado. ```
Duas regras a pôr em prática imediatamente, antes de outras pessoas verem o produto: - **O repositório tem de ser privado.** Não público. Caso contrário, qualquer pessoa pode ler o seu código e tudo o que está nele. - **Coloque o ficheiro de segredos na lista de ficheiros ignorados.** As chaves, as palavras-passe e as credenciais de acesso à base de dados ficam num ficheiro separado (normalmente `.env`), e esse ficheiro nunca entra no repositório. Adicione uma linha para `.env` ao `.gitignore`, e os segredos ficam consigo. Existe um guia separado sobre como reverter alterações em segurança no Claude Code: [Como reverter alterações no Claude Code](https://ailoot.ai/blog/pt-pt/claude-code-undo-changes/). Sem pontos de regresso, está a andar numa corda bamba sem rede de segurança e, mais cedo ou mais tarde, vai cair. ## O que é que `/rewind` reverte e o que não reverte?
Principal conclusão O Claude Code tem um comando `/rewind` — cria um instantâneo antes de cada edição e reverte o código e a conversa para um ponto selecionado. Mas só reverte os ficheiros que o próprio Claude alterou. Não mexe nos pacotes instalados, nos carregamentos para a nuvem, nas alterações à base de dados nem nas chamadas a serviços externos. O git é o histórico permanente; `/rewind` é um rápido «anular» local.
O Claude Code cria um instantâneo do estado antes de cada alteração que faz. O comando `/rewind` (ou carregar duas vezes em Esc) reverte os ficheiros e a conversa para um ponto selecionado. É prático: se estragou uma funcionalidade há cinco minutos, pode voltar cinco minutos atrás. Mas há uma armadilha que leva os principiantes a perder dados. `/rewind` não reverte tudo: | O que `/rewind` reverte | O que NÃO reverte | |--------------------------------------|-------------------------------------| | Edições de ficheiros feitas pelo Claude | Instalação de pacotes (`npm install`) | | A conversa nesta sessão | Carregamento de código para a nuvem (`git push`) | | O estado local do projeto | Alterações à base de dados | | \- | Chamadas a serviços externos e pagamentos | A própria Anthropic explica-o claramente: os instantâneos são um botão local para «anular», enquanto o git é o histórico permanente. Os instantâneos complementam o controlo de versões, mas não o substituem.

Os instantâneos são uma opção local para «anular», enquanto o Git é o histórico permanente. Os instantâneos complementam o controlo de versões completo, mas não o substituem.

— Documentação do Claude Code, https://code.claude.com/docs/en/checkpointing
A lição prática para quem não programa: `/rewind` vai salvá-lo de uma situação como «o Claude acabou de estragar uma funcionalidade». Mas, se ele tiver conseguido apagar uma linha da base de dados ou carregar código para a nuvem, só o git e uma cópia de segurança da base de dados o poderão recuperar. Por isso, mantenha as duas camadas: instantâneos para reversões rápidas e commits para o histórico permanente do projeto. ## Como melhorar sem estragar o que já funciona?
Principal conclusão O principal perigo ao fazer melhorias é o desvio lógico: pede à IA que corrija uma coisa e ela altera discretamente a lógica adjacente, porque o vibe coding é não determinístico. A regra de ouro é a proteção: não faça deploy de código que não consiga explicar a outra pessoa. Faça alterações pequenas, cada uma através de um commit, e reveja sempre exatamente o que mudou.
Uma em cada duas pessoas acaba presa neste ciclo. Pede à IA que corrija um pequeno erro. Ela sugere uma alteração razoável. Essa alteração estraga outra coisa. Pede-lhe que corrija o novo problema e surgem mais dois. E assim sucessivamente. O ciclo acontece porque o vibe coding é não determinístico. O mesmo prompt dá-lhe código diferente duas vezes. Por isso, cada edição pode alterar discretamente a lógica envolvente: o limite do desconto passa de 10 para 12 por cento ou uma regra de validação muda de comportamento — sem que faça verificações nem receba um único aviso. A isto chama-se desvio lógico, e prejudica silenciosamente precisamente aquilo que gera dinheiro: preços, acesso e pagamentos. Há uma regra para prevenir esse desvio, simples o suficiente para a pôr na parede: não faça commit de código que não conseguisse explicar a outra pessoa, palavra por palavra. Na prática, isto transforma-se num procedimento pronto a usar antes de qualquer alteração ao código funcional. Faz com que a IA avance em pequenos passos e lhe mostre exatamente o que mudou.
Prompt: Planear uma alteração segura ``` Antes de alterares o código, faz o seguinte: Guarda o estado funcional atual como um ponto de regresso separado (commit). Descreve por palavras exatamente o que planeias alterar e em que ficheiros. Faz a alteração mais pequena possível — apenas o que resolve a minha tarefa, sem nada extra. Mostra-me o que mudou e explica cada alteração de forma que eu a consiga explicar a outra pessoa. Não mexas na lógica de preços, acesso ou pagamentos, a menos que te peça. ```
Outro princípio que poupa semanas é a disciplina na definição dos limites das tarefas. Um problema, uma alteração, uma implementação rápida. Não peças à IA que reescreva metade do projeto num único prompt. Por vezes, programadores profissionais começam a construir um Uber inteiro quando só precisavam de um botão — e arrastam o projeto durante meses. Não precisa disso. Tudo o que descrevo assenta numa coisa: a gestão do contexto. Para impedir que a IA estrague a lógica adjacente, precisa de conhecer as regras do seu projeto. ## Como verificar uma alteração antes de a publicar?
Principal conclusão Antes de lançar uma alteração para os utilizadores reais, percorra os cenários principais: pagamento, registo, acesso e preços. A melhor opção é fazer a verificação final numa cópia de teste do ambiente de produção (chamada staging nas ferramentas de desenvolvimento). A sequência é: desenvolver, verificar numa cópia de teste e fazer deploy para produção. Cada versão traz riscos; a cópia de teste elimina-os.
Entre «funciona no meu computador» e «funciona para toda a gente» existe uma etapa intermédia que os principiantes ignoram: uma cópia de teste. É uma cópia separada do ambiente de produção, onde verifica uma alteração antes de as pessoas reais a verem. O ciclo de trabalho é o seguinte: 1. Desenvolva e verifique a alteração (desenvolvimento). 2. Faça deploy em staging — uma cópia da produção, mas sem utilizadores reais. 3. Percorra os cenários principais e confirme que nada mudou. 4. Só então faça deploy para produção. Porque é que isto importa após o lançamento: cada versão traz riscos. Uma pequena alteração de código pode impedir o início de sessão na conta. Uma definição em falta pode deitar abaixo todo o produto. O staging deteta estes problemas sem consequências; em produção, perde clientes. Para não ter de verificar tudo manualmente de cada vez, dê à IA um prompt para comparar o comportamento da nova versão com o da antiga nas áreas críticas.
Prompt: Verificação de regressões antes do lançamento ``` Estou prestes a fazer deploy de uma alteração. Percorre os cenários principais do produto pela ordem indicada e verifica se cada um continua a funcionar como antes: Registo e início de sessão de um novo utilizador. Pagamento e concessão de acesso após o pagamento. Direitos de acesso — um utilizador normal não consegue ver os dados de outra pessoa nem a área de administração. Os valores principais da lógica de negócio (preços, descontos, limites) não mudaram. Se alguma coisa se comportar de forma diferente da versão anterior, para e mostra-me exatamente o que mudou. ```
## Onde estão os seus segredos? A maior falha de segurança de um principiante
Principal conclusão O erro mais comum e dispendioso após o lançamento é ter segredos no código da página. As chaves da base de dados, do sistema de pagamentos e dos serviços externos devem ficar apenas no servidor, em variáveis de ambiente, e nunca no navegador. Esta falha já custou a um produto 1,5 milhões de chaves expostas e aos clientes de um fundador $87,500 em cobranças.
Vou explicar detalhadamente a maior mina, porque derruba mais produtos do que qualquer outra. Quando a IA escreve código, o mais fácil é pôr uma chave onde funcionará de imediato — diretamente no código da página que se abre no navegador. Não vai notar a diferença durante o desenvolvimento. Mas qualquer pessoa pode ler tudo o que chega ao navegador abrindo as ferramentas de desenvolvimento. O fundador cujos clientes foram cobrados $87,500 disse mais tarde que um único prompt poderia ter evitado o problema. As cobranças foram finalmente anuladas, mas as taxas não reembolsáveis e a perda de tranquilidade mantiveram-se. Eis o prompt.
Prompt: Verificar onde estão guardados os meus segredos ``` Verifica todo o projeto e confirma que nenhuma chave secreta vai parar ao navegador: Encontra todas as chaves da base de dados, do sistema de pagamentos e dos serviços externos. Confirma que cada uma está guardada apenas no servidor, em variáveis de ambiente, e não no código da página. Verifica o histórico do projeto — alguma chave foi parar lá por engano anteriormente? Mostra-me uma lista de todos os locais onde encontraste segredos e o que é preciso fazer em cada caso. ```
A mina seguinte, que fica por perto, é verificar as permissões de acesso apenas no navegador. Se o seu produto decidir no código da página se deve «mostrar a área de administração», qualquer pessoa pode contornar essa decisão. As permissões de acesso têm de ser sempre verificadas no servidor. A base de dados só deve devolver dados a quem tem direito a eles — é para isso que serve a segurança ao nível das linhas (RLS), que tem de estar ativada em todas as tabelas. Antes de vender o acesso ou deixar entrar outras pessoas, faça uma auditoria de segurança geral ao produto.
Prompt: Auditar o projeto após o lançamento ``` Analisa o projeto como um atacante e encontra falhas de segurança: Há chaves secretas guardadas em código que vai para o navegador ou no histórico do projeto? A segurança ao nível das linhas (RLS) está ativada em todas as tabelas da base de dados e as permissões de acesso são verificadas no servidor, e não apenas no navegador? Está configurada uma cópia de segurança automática da base de dados e já verifiquei se a consigo restaurar? A base de dados de produção está isolada do ambiente onde o agente de IA é executado? Para cada ponto, diz-me se está tudo bem ou exatamente o que precisa de ser corrigido. ```
Existe um guia completo separado sobre a segurança do vibe coding: [Como proteger uma aplicação criada com vibe coding](https://ailoot.ai/blog/pt-pt/vibe-coding-security/). A regra é simples: considere tudo o que a IA fez por predefinição como não seguro até verificar o contrário. ## Onde alojar o produto: a escada do alojamento
Principal conclusão O local onde o produto está alojado depende de quem o usa. O alojamento gratuito serve para testes e projetos pequenos sem dados pessoais. Para um produto com base de dados e utilizadores reais, use uma plataforma que permita fazer deploy com um único comando. Um servidor próprio é o passo seguinte quando a carga é elevada. Não comece por algo complicado.
Não precisa de alugar já um servidor próprio e configurá-lo manualmente — no início, é uma tarefa complicada que lhe vai consumir tempo. Pode subir uma escada à medida que o produto cresce: 1. **Alojamento gratuito** (por exemplo, Vercel) — para si, para testes e para projetos pequenos. Funciona se a plataforma estiver disponível para o seu público e não guardar dados pessoais das pessoas. 2. **Plataforma com deploy através de um único comando** (Railway) — quando tem um backend e uma base de dados. Faz deploy com um comando e não precisa de configurar um servidor. A barreira de entrada é mínima. 3. **Servidor dedicado próprio** — quando a carga é elevada e precisa de controlo total. Mude para esta opção mais tarde, quando atingir o limite da plataforma. Para quem não programa e acabou de lançar um produto, a opção mais fácil é uma plataforma com deploy através de um único comando, sem configuração manual do servidor. Passe para o seu próprio servidor mais tarde. Se quiser seguir este percurso com um exemplo concreto, consulte o guia sobre [como fazer deploy de um projeto criado com vibe coding no seu próprio servidor com o Coolify](https://ailoot.ai/blog/pt-pt/coolify-claude-code-deploy/). ## Quando deve separar a aplicação, a base de dados e as cópias de segurança?
Principal conclusão Enquanto o produto é pequeno, a aplicação e a base de dados estão no mesmo computador. Está na altura de as separar quando a carga de pico se mantém acima de 70–80 por cento ou quando a base de dados e a aplicação começam a tornar-se mais lentas uma por causa da outra. As cópias de segurança seguem a regra 3-2-1: três cópias, em dois tipos de suporte, com uma fora do local. E têm de ser feitas automaticamente, não «quando me lembrar».
Há três coisas que não devem estar todas no mesmo cesto: a aplicação, a base de dados e as cópias de segurança. Enquanto há poucos utilizadores, tudo fica junto, e não há problema. Mas há um sinal claro de que chegou a altura de as separar. - **Coloque a aplicação e a base de dados em computadores diferentes.** O sinal: na carga de pico, a utilização do CPU e da memória mantém-se acima de 70–80 por cento, os pedidos ficam mais lentos e a aplicação e a base de dados disputam os mesmos recursos. Depois de as separar, pode reforçar a base de dados sem mexer na aplicação, e vice-versa. - **Siga a regra de cópias de segurança 3-2-1.** Três cópias dos dados, em dois tipos de suporte diferentes, com uma fora do local. Isto protege contra falhas de hardware e ransomware. O essencial é que as cópias de segurança sejam automáticas. A frequência das cópias de segurança depende do custo de perder dados de várias horas. Num serviço de subscrição online em que perder uma hora de registos de pagamento seja inaceitável, o intervalo entre cópias tem de ser inferior a uma hora, ou precisa de registos de transações verificados e recuperação num ponto no tempo (PITR). Escolha o intervalo pela perda máxima tolerável e teste separadamente o tempo necessário para repor o serviço. Para um blogue, basta uma por dia. A lógica é simples: decida quanto dados pode perder e configure as cópias de segurança em conformidade.
Prompt: Está na altura de separar os servidores? ``` Ajuda-me a decidir se está na altura de transferir o meu produto para uma infraestrutura mais robusta. Verifica e pergunta-me sobre cada ponto: Qual é a utilização do CPU e da memória nos períodos de pico — mantém-se acima de 70–80 por cento ou não? A base de dados e a aplicação estão no mesmo computador ou em computadores diferentes? Está configurada uma cópia de segurança automática da base de dados e testei o restauro a partir dela? Existe uma cópia separada do ambiente (staging) para fazer verificações antes do deploy? Com base nos resultados, dá-me uma recomendação clara: o que deixar como está, o que separar primeiro e porquê. ```
Há ainda uma questão: base de dados gerida ou própria. Para uma equipa pequena, a gerida é quase sempre melhor: a própria custa menos em hardware, mas consome horas de manutenção. Se está por sua conta e o seu produto não é infraestrutura, essas horas custam mais do que a diferença no preço do servidor. ## Como pôr a manutenção em piloto automático?
Principal conclusão A manutenção não tem de ser manual. Dois sistemas de monitorização cobrem o básico: um verifica se o site está operacional e o outro deteta erros dentro do produto. Também pode configurar um agente de IA para fazer uma ronda matinal — ler os relatos dos utilizadores, descobrir o que está avariado e trazer uma correção pronta a aplicar. Mas os envios de correio e as operações em massa devem ser executados por lotes, não sobre toda a base de dados de uma só vez.
A manutenção manual é extenuante. Pode tirá-la das suas mãos de duas formas: monitorização e um agente de ronda. A monitorização utiliza duas ferramentas diferentes para duas tarefas diferentes: 1. **«O site está operacional?»** — um monitor de disponibilidade (por exemplo, UptimeRobot). Verifica o produto de poucos em poucos minutos e envia um alerta se ficar indisponível. Tem um plano gratuito. 2. **«O que se estragou exatamente?»** — um monitor de erros (por exemplo, Sentry). Recolhe erros dentro da aplicação e mostra onde e por que motivo algo falhou. O primeiro deteta que o produto ficou indisponível. O segundo mostra que funcionalidade falhou e porquê. Em conjunto, respondem à pergunta: «Vou saber que houve uma falha antes de um cliente escrever ao suporte?» O segundo nível do piloto automático é um agente de ronda. Imagine uma agência imobiliária: às sete da manhã, um agente de IA lê os pedidos enviados pelo site, percebe que o formulário de reserva está avariado, encontra a causa no código e traz-lhe uma correção pronta, acompanhada de uma explicação. Revê-a e diz «sim» — ela é implementada. A ordem importa: primeiro resolva o problema do utilizador (conceda acesso, peça desculpa) e depois investigue a causa e o dinheiro.
Atenção Não execute operações em massa sobre toda a base de dados de uma só vez. Envie um e-mail a todos ao mesmo tempo e o servidor ficará sobrecarregado, enquanto metade das mensagens acaba no spam. A forma correta é usar lotes: 100–1 000 por dia, distribuídos ao longo das horas. Isto aplica-se a qualquer base de dados de clientes: uma loja, uma clínica ou um serviço.
Mais uma regra sobre o acesso da IA à base de dados de produção: dê-lhe um utilizador apenas de leitura e oculte os dados pessoais atrás de uma camada intermédia, para que o agente veja «nome» em vez do nome verdadeiro de uma pessoa. Assim, mesmo que cometa um erro, não poderá apagar nem corromper fisicamente os dados de produção. O incidente da tabela acima, em que um agente apagou a base de dados de produção, é precisamente sobre a falta desta restrição. O guia [O que fazer se a IA apagou a sua base de dados](https://ailoot.ai/blog/pt-pt/ai-deleted-database-recovery/) explica o que fazer se o desastre já aconteceu. ## Quando é que está na altura de encerrar um produto?
Principal conclusão Nem todos os produtos devem ser mantidos; alguns devem ser encerrados. Dê duas semanas a uma ideia para provar que é viável, com um limite máximo rígido de três meses. Se não arrancar, encerre o produto, por muito que lamente o investimento feito. Não é o código mau que mata um produto; é as pessoas deixarem de o usar. Toda a gente tem um cemitério de projetos inacabados — é normal.
A parte mais subestimada da manutenção é saber quando deixar de a fazer. Quem cria muito tem um cemitério de projetos: criou um, experimentou mexer nele e depois abandonou-o. É normal e não é um fracasso. O fracasso é arrastar durante meses algo que ninguém usa por lamentar o tempo que investiu. Pode usar estes limites para tomar uma decisão: 1. **Duas semanas** — tempo suficiente para perceber se a ideia funciona. Se os primeiros utilizadores reais voltarem, continue. O silêncio é uma resposta. 2. **Três meses** — o limite máximo rígido. Se o produto não tiver arrancado em três meses, encerre-o. Com a rapidez do vibe coding, passar seis meses a testar uma ideia é demasiado tempo. É psicologicamente difícil encerrar um projeto, por isso trate-o como uma decisão, não como um sentimento. Desistir de um projeto em que investiu é como despedir um funcionário que não consegue fazer o trabalho: é desagradável, mas mantê-lo custa mais do que deixá-lo ir. A manutenção é o trabalho feito para manter um produto vivo e útil para as pessoas. Tudo o resto — git, cópias de segurança, monitorização — é apenas uma ferramenta que o ajuda a chegar ao ponto em que o produto começa a trabalhar para si todos os dias.
### Fontes - [Anthropic - Checkpointing no Claude Code](https://code.claude.com/docs/en/checkpointing) - [Anthropic - Modelo de segurança do Claude Code](https://code.claude.com/docs/en/security)
Criar um produto com IA numa noite é metade do trabalho. Mantê-lo vivo e seguro à medida que cresce — isso é o que significa vibe coding para adultos. Para o seu próximo passo — [Ailoot](https://ailoot.ai/). ## Perguntas frequentes ### Com que frequência devo copiar um serviço com pagamentos? Escolha o intervalo pela perda máxima de dados tolerável. Se perder uma hora for inaceitável, use cópias mais frequentes do que horárias ou uma configuração verificada de registos de transações/PITR; teste também quanto demora o restauro real. ### Um monitor de disponibilidade basta para verificar a saúde do produto? Não. Mostra se o site responde, enquanto um rastreador de erros identifica falhas dentro da aplicação. Verifique os percursos importantes em staging antes de lançar e confirme que é possível restaurar uma cópia de segurança. ## Ailoot · A empresa e a sua carteira de projetos A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI. A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões. A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.