Acontece cada vez mais em Portugal, e quase sempre da mesma maneira. Alguém na empresa, muitas vezes de fora do departamento de informática, abre o ChatGPT, o Codex, o Claude Code ou o Gemini e, ao fim de algumas tardes, tem uma aplicação a funcionar. Registo de horas, controlo de pedidos, um portal para os clientes consultarem encomendas, um painel que junta finalmente números que viviam em quatro folhas de cálculo diferentes. Funciona. As pessoas usam. E o processo que estava há dois anos na lista de espera deixou de estar.
A nossa posição sobre isto é simples: quem fez, fez bem. Durante muito tempo, a distância entre uma boa ideia de negócio e a possibilidade de a mostrar a funcionar era grande o suficiente para matar a ideia pelo caminho. Hoje não é. Levar ao decisor um protótipo que já corre, com resultados visíveis e uma noção concreta do que aquilo faz, é uma vantagem real. Vale mais do que qualquer documento de trinta páginas a descrever o mesmo.
O que se segue não é uma lista de razões para desconfiar do que a sua equipa construiu. É a lista do que muda quando aquilo passa a servir a empresa a sério.
A resposta curta: o protótipo não está errado, está incompleto
Um protótipo responde muito bem a uma pergunta: isto faz sentido? Responde mostrando o fluxo, os ecrãs, os campos que interessam e o que as pessoas pensam quando finalmente têm a coisa à frente.
Há outra pergunta a que não responde, porque não foi feito para isso: isto pode suportar o trabalho da empresa? Aqui entram assuntos que não aparecem enquanto o utilizador é uma pessoa só, que conhece o sistema por dentro e sabe o que não deve tocar.
A pergunta deixa de ser “isto funciona?” e passa a ser outra: o que acontece quando isto falhar numa quinta-feira à tarde, com quinze pessoas dependentes dele e sem quem o construiu por perto?
Profissionalizar um protótipo é responder a essa segunda pergunta sem perder o que a primeira já provou.
O que o protótipo já provou, e vale dinheiro
Num projeto de software convencional, a fase mais demorada e mais arriscada não é escrever código. É o levantamento: perceber como o processo funciona realmente, que exceções existem e o que as pessoas vão fazer de facto quando tiverem o sistema à frente. É onde se perdem semanas em reuniões e onde nascem os mal-entendidos que só aparecem no fim.
Quando existe um protótipo a funcionar, boa parte desse trabalho está feita, e está feita da melhor forma possível: em software, com uso real. Concretamente, já se sabe que:
- o processo é real e tem quem o queira, porque houve pessoas a usar aquilo sem ninguém as obrigar;
- a estrutura de dados está esboçada, com as entidades e os campos que a operação usa mesmo, e não os que alguém imaginou numa reunião;
- as regras e as exceções apareceram, porque um protótipo em uso encontra em duas semanas os casos estranhos que uma especificação demora meses a prever;
- os ecrãs foram validados por quem trabalha no processo, que é a única validação que conta;
- há um caso de negócio demonstrável, com um antes e um depois que se consegue explicar a quem decide.
É por isso que quase nunca recomendamos começar de novo. O código pode mudar inteiro e o valor mantém-se, porque o valor está no conhecimento do processo que ficou lá dentro.
O que muda quando o protótipo passa a ser um sistema da empresa
Quem entra e o que cada pessoa pode ver
Num protótipo é normal não haver contas individuais, ou existir uma palavra-passe partilhada, ou o acesso ser controlado por um endereço que “ninguém de fora conhece”. Assim que a aplicação passa a tratar dados de clientes, valores ou informação de pessoal, isto tem de mudar: contas individuais, permissões por perfil e a garantia de que um utilizador não consegue ver, alterando um número no endereço, aquilo que não lhe pertence.
Onde ficam os dados e as credenciais
Duas coisas aparecem quase sempre juntas na primeira auditoria. A primeira é a localização dos dados: uma base de dados no computador de quem construiu a aplicação, ou num serviço pessoal, sem cópias de segurança testadas. A segunda são as chaves de acesso escritas dentro do código, o que significa que quem tem o código tem tudo, incluindo a conta de faturação do modelo de IA.
A correção é conhecida e não é dramática: dados em infraestrutura controlada pela empresa e alojada na União Europeia, credenciais num gestor de segredos, cópias de segurança com restauro testado, e permissões separadas para desenvolvimento e produção.
O que acontece quando falha
Um protótipo falha em silêncio, e quem o construiu dá por isso porque está a olhar. Um sistema em produção precisa de tratamento de erros, de registo do que correu mal e de alguém a ser avisado quando um processo não terminou. O problema não é a falha em si, é o tempo que passa até alguém dar por ela e o trabalho de reconstituir depois o que ficou a meio.
Quem consegue mexer nisto daqui a seis meses
Este é o ponto que mais preocupa a direção, e com razão. Um protótipo tende a ter um único autor, sem testes que confirmem que uma alteração não parte o resto, sem histórico organizado das versões e sem nada escrito sobre as decisões que foram tomadas. Funciona bem enquanto essa pessoa estiver disponível e se lembrar de tudo. Deixa de funcionar no dia em que muda de funções, entra em férias numa semana de fecho, ou simplesmente já não se lembra porque é que aquela regra existe.
O que custa a funcionar
Aplicações que usam modelos de IA têm um custo por utilização. Num protótipo com três utilizadores, esse custo não se nota. Com cinquenta, e sem limites de consumo nem controlo de quem chama o quê, a fatura mensal passa a ser uma surpresa. Definir limites, guardar resultados repetidos e escolher o modelo certo para cada tarefa costuma reduzir esse custo de forma significativa, e torna-o previsível, que é o que interessa a quem aprova orçamentos.
Sinais de que o protótipo chegou ao limite
Vale a pena olhar para esta lista com honestidade. Dois ou três destes pontos são normais. Cinco ou mais significam que a aplicação já é um sistema da empresa, mas ainda não está tratada como tal:
- há pessoas a depender daquilo para fazer o trabalho diário;
- se a aplicação parar durante um dia, alguém tem de voltar ao Excel;
- só uma pessoa sabe como aquilo funciona por dentro;
- não existe cópia de segurança que já tenha sido restaurada com sucesso;
- os dados incluem informação de clientes, colaboradores ou valores;
- há clientes ou fornecedores externos a usar a aplicação;
- ninguém sabe dizer quanto custa por mês a manter;
- já houve uma alteração que estragou algo que funcionava.
Três respostas erradas a este problema
Deitar fora e recomeçar de zero. É a resposta mais comum de quem olha para o código e não gosta do que vê. É também a que sai mais cara, porque deita fora um levantamento que já está pago e volta a pôr a empresa a discutir requisitos em reuniões, com meses de atraso.
Deixar como está e esperar. Também acontece, quase sempre por falta de tempo, e é a opção que corre pior. Um sistema informal cresce: mais utilizadores, mais dados, mais dependência. O momento em que a correção é mais barata é agora, não quando houver um incidente.
Passar a manutenção a quem o construiu, como segunda função. É injusto para essa pessoa e frágil para a empresa. Quem construiu o protótipo é normalmente quem melhor conhece o processo, e é essa a contribuição que se deve manter. Ser também responsável por segurança, disponibilidade e integrações, em cima do trabalho que já tem, é outra coisa.
Como se leva um protótipo a produção
1. Auditoria do que existe
Uma a duas semanas a olhar para o código, para os dados e para a forma como a aplicação está a ser usada. No fim, ficam claras três coisas: o que se aproveita, o que tem de ser refeito e o que é urgente por razões de segurança ou de conformidade. Esta fase começa com um diagnóstico gratuito, e não exige decisão nenhuma para acontecer.
2. Decidir o âmbito com quem construiu
Sentamo-nos com a pessoa ou a equipa que fez o protótipo. É a conversa mais produtiva de todo o projeto, porque é onde se percebe a intenção por trás de cada decisão e onde se separa o que foi escolha deliberada do que foi atalho para mostrar a ideia. Daqui sai o plano, o prazo e o investimento.
3. Endurecer a base
Autenticação, permissões, dados em infraestrutura própria, credenciais fora do código, tratamento de erros, registo de utilização e testes nas partes que não podem falhar. Nesta fase o utilizador não vê grande diferença, e é precisamente esse o objetivo: o comportamento mantém-se, as fundações mudam.
4. Integrar com o que a empresa já usa
A maioria dos protótipos vive isolada, com dados introduzidos à mão que já existem noutro sítio. É aqui que se liga o ERP, o CRM, a faturação ou o correio eletrónico, para a aplicação deixar de ser uma ilha e passar a fazer parte do processo.
5. Produção, entrega e continuidade
Entrada em produção com utilizadores reais, acompanhamento nas primeiras semanas e entrega formal: código, infraestrutura, documentação e formação. O sistema fica propriedade da empresa, sem dependência de licenças nossas para continuar a funcionar.
Quanto custa e quanto tempo demora
Para um protótipo com âmbito delimitado, um processo, um tipo de utilizador e uma ou duas integrações, o investimento situa-se tipicamente entre 7.500€ e 20.000€, com 6 a 12 semanas até produção. Quando a aplicação abrange várias áreas da empresa, tem utilizadores externos ou precisa de ligações a sistemas sem API utilizável, o âmbito sobe e o prazo acompanha.
Há duas coisas que mexem mais no valor do que qualquer outra. A primeira é a qualidade da estrutura de dados do protótipo: se as entidades e as relações estiverem bem pensadas, aproveita-se quase tudo; se os dados estiverem espalhados sem estrutura, há trabalho de migração. A segunda é o número de sistemas externos a integrar, e se esses sistemas têm ou não uma forma documentada de aceder aos dados.
Em regra, profissionalizar sai mais barato do que construir o mesmo sistema a partir do nada, porque a fase de definição já está feita e validada com uso real.
O que decidir antes de avançar
Antes de falar de tecnologia, vale a pena responder a cinco perguntas:
- Quantas pessoas dependem hoje desta aplicação para trabalhar?
- Que informação sensível é que ela guarda ou trata?
- Se parar amanhã, qual é o impacto real na operação?
- Que sistemas é que ela devia consultar e ainda não consulta?
- Quem, dentro da empresa, tem autoridade para decidir o âmbito?
Quem consegue responder a isto tem já metade de uma especificação, e é uma conversa muito diferente daquela que começa com uma folha em branco.
As aplicações feitas com IA levadas a produção são exatamente este trabalho: pegar no que a sua equipa construiu, torná-lo seguro para uso interno e prepará-lo para crescer com a operação. Se já tem um protótipo em uso, pode pedir um diagnóstico gratuito. Olhamos para o que existe, sem compromisso, e devolvemos uma proposta com âmbito, prazo e investimento definidos.