Decidir se precisas de uma aplicação própria

Uma aplicação própria faz sentido quando existe um trabalho específico que as ferramentas disponíveis não resolvem de forma adequada para a tua operação. Antes de construir, descreve o problema, quem o sente e como é tratado hoje. Compara o esforço de adaptação, integração e manutenção com o benefício que procuras obter.

Imagina uma equipa que distribui pedidos através de várias folhas e mensagens. Talvez baste organizar melhor a ferramenta existente. Talvez seja necessária uma interface que junte regras, disponibilidade e acompanhamento num único percurso. A decisão depende do trabalho concreto e das limitações observadas, não apenas da facilidade de gerar uma primeira página.

No livro que escrevi em 2022, contei uma experiência profissional ligada ao planeamento de uma aplicação para lavandarias. A análise ajudou a questionar o projeto antes de avançar. Hoje a IA pode acelerar a construção, mas continuo a querer compreender a necessidade e as condições do negócio antes de investir nessa execução.

Se o problema é sobretudo ligar ferramentas, começa por automação de processos empresariais. Uma aplicação acrescenta interface, utilizadores e responsabilidades de manutenção. Às vezes essa camada tem valor; noutras situações, um processo bem organizado chega para melhorar o trabalho sem criar mais um produto para manter.

Escrever o comportamento antes de pedir código

Um plano de aplicação deve explicar quem a usa, que informação introduz, que decisões o sistema toma e que resultado entrega. Inclui exceções e diferenças entre permissões. A IA consegue trabalhar com instruções mais concretas quando o comportamento esperado está escrito e acompanhado por exemplos que permitem verificar o resultado.

Na Sexta Ímpar #145, sobre construir uma aplicação com Claude Code, a preparação faz parte da demonstração. O projeto envolve utilizadores, regras de pontuação, horários e integrações. Esses elementos mostram que construir uma aplicação exige definir o que acontece para além do aspeto visual do primeiro ecrã.

Para um pedido de reunião, por exemplo, escreveria o que acontece se faltar disponibilidade, se o mesmo pedido entrar duas vezes e se alguém tentar consultar o pedido de outra pessoa. Acrescentaria quem pode alterar o estado e quem apenas o consulta. São decisões pequenas que mudam bastante a implementação.

Desenvolvo essa preparação no artigo sobre planear uma aplicação com Claude Code antes de programar. Nesta página, interessa-me o percurso completo até à utilização diária. O plano inicial deve continuar disponível quando aparecem alterações, para que o projeto não dependa da memória de uma conversa com a IA.

Construir uma primeira versão que permita aprender

A primeira versão deve completar um percurso útil, com os controlos necessários para os utilizadores previstos. Escolhe um objetivo pequeno e verifica a sequência do princípio ao fim. Essa versão permite observar dificuldades reais antes de acrescentar relatórios, personalizações e funcionalidades que ainda não tens evidência suficiente para priorizar.

Num exemplo de gestão de pedidos, começaria pela entrada, consulta autorizada, atribuição e atualização do estado. Um painel com dezenas de métricas pode esperar até percebermos que decisões a equipa precisa de tomar. Se a informação chega incompleta, melhorar gráficos não resolve a dificuldade inicial de trabalhar o pedido.

Pede à IA alterações delimitadas e revê o resultado depois de cada uma. Uma mudança no formulário pode afetar validação, gravação e mensagens de erro. Ver o ecrã atualizado é apenas parte da revisão. Interessa confirmar que os dados chegam corretamente ao destino e continuam acessíveis apenas a quem deve vê-los.

Uma aplicação pode incorporar um modelo para interpretar texto, mas também pode funcionar inteiramente com regras depois de construída. Na aula #151, sobre ferramentas para gestão de tráfego, essa diferença fica visível. Mantê-la clara ajuda a estimar custos e a perceber que partes exigem avaliação de respostas geradas.

Rever acessos e dados antes de convidar utilizadores

Antes de convidar utilizadores, verifica como a aplicação identifica cada pessoa, autoriza ações e protege os dados guardados. Testa acessos indevidos com contas separadas e confirma que segredos não chegam ao navegador. A revisão deve abranger o servidor e a base de dados, além dos botões e páginas visíveis na interface.

Se um utilizador altera o endereço de um pedido, a aplicação deve voltar a confirmar a autorização. Esconder o link para esse pedido não protege o recurso. O mesmo se aplica a downloads e operações de edição: cada ação precisa de saber quem a está a pedir e que acesso essa pessoa tem.

As minhas regras incluem permissões explícitas na base de dados, autorização no servidor, verificação de acesso por recurso, proteção de chaves e validação de inputs. Explico-as com exemplos na página de segurança de aplicações desenvolvidas com IA. São perguntas que devem acompanhar a construção desde o início.

Também separo os acessos da ferramenta de desenvolvimento dos acessos do produto final. A documentação de segurança do Claude Code descreve permissões e cuidados com conteúdo externo. Esses mecanismos ajudam a controlar a ferramenta, mas não substituem a revisão da aplicação que foi construída com ela.

Testar o trabalho real e preparar a publicação

Os testes devem verificar os percursos importantes, os erros previsíveis e os limites de acesso antes da publicação. Usa exemplos representativos, incluindo dados incompletos e ações repetidas. Prepara também a configuração de produção, as cópias de segurança e uma forma de recuperar quando uma alteração produz um resultado diferente do esperado.

Pede a alguém que execute uma tarefa sem lhe explicares cada clique. Onde hesita? Percebe o erro quando falta um campo? Consegue regressar ao trabalho depois de fechar a página? Essas observações ajudam a melhorar o produto e mostram problemas que uma revisão feita apenas por quem o construiu pode deixar passar.

Verifica o telemóvel, os estados de carregamento e as mensagens quando uma integração falha. Um botão sem resposta deixa o utilizador sem saber se deve tentar outra vez. Se a operação pode criar um pedido ou enviar uma mensagem, a aplicação deve ajudar a distinguir o que ficou concluído do que continua por confirmar.

Documenta a configuração necessária sem colocar credenciais no código. Antes de substituir uma versão em uso, confirma como voltar à anterior e como tratar eventuais alterações aos dados. Esta preparação faz parte do custo de pôr software a trabalhar numa empresa, mesmo quando escrever o código foi bastante rápido.

Assumir a manutenção como parte do projeto

Uma aplicação em uso precisa de acompanhamento de erros, revisão de dependências e decisões sobre novas funcionalidades. Define quem recebe problemas, quem pode publicar alterações e como se confirma que uma correção funcionou. A manutenção deve preservar o conhecimento do projeto, incluindo as razões por trás das regras que a equipa utiliza.

Quando chega um pedido de mudança, volta ao objetivo e ao comportamento existente. Uma nova permissão pode facilitar uma tarefa e expor informação a outras pessoas. Uma integração pode poupar cópias e criar uma dependência externa. Discutir essas consequências ajuda a escolher o que deve entrar e como deve ser verificado.

No Laboratório da IA revejo projetos em duas mentorias por mês. A mentoria de IA e negócios permite discutir decisões e dificuldades enquanto desenvolves o teu trabalho. Se a necessidade é preparar uma equipa, há também o caminho de formação de IA para empresas, com objetivo e formato definidos a partir do contexto.

Para uma implementação acompanhada pela equipa, apresenta o problema à SpartAds. Leva o processo atual, quem vai usar a aplicação e o que já tentaste. Isso permite avaliar a necessidade de software próprio e o trabalho que será necessário para o manter útil depois da primeira entrega.