Em Angola, mais ideias fracassam pelo preço do que por falta de mérito. E quase sempre porque ninguém analisou o modelo antes de olhar para o número.
Quem nos contacta pela primeira vez costuma começar pela mesma pergunta: «quanto custa?». É uma pergunta legítima, mas parte de um equívoco. O custo de uma aplicação não está no código que a faz funcionar; está nas decisões que se tomam à volta dele. E é precisamente para essas decisões que raramente se olha antes de assinar um contrato.
Duas aplicações iguais por fora, incomparáveis por dentro
Considerem-se duas aplicações aparentemente semelhantes. Ambas apresentam produtos e ambas exigem autenticação. Uma serve apenas para consultar um catálogo; a outra processa pagamentos, emite faturas, controla o stock e notifica o cliente sempre que a encomenda muda de estado.
Na interface, distinguem-se pouco. No esforço que exigem, pertencem a categorias diferentes. Esta é a primeira variável de qualquer orçamento: o que a aplicação faz de facto, e não o número de ecrãs que apresenta. Cada funcionalidade acrescenta horas de análise, de design e de engenharia que não se veem no resultado final, mas que se pagam.
Seguem-se as plataformas. Disponibilizar uma versão web e aplicações para iOS e Android, todas com o mesmo nível de acabamento, não equivale a fazer o mesmo trabalho três vezes, mas também não corresponde a fazê-lo uma só vez. Uma arquitetura bem concebida permite partilhar grande parte da lógica entre plataformas e reduz substancialmente esse esforço; nenhuma o elimina por completo.
Resta a variável mais discreta, e a que mais custa a quem a ignora: a escala. Uma aplicação dimensionada para cem utilizadores e outra preparada para cinquenta mil podem ser indistinguíveis na interface e profundamente diferentes na infraestrutura. O preço desse descuido apresenta-se sempre no pior momento: no dia em que o produto começa a ganhar tração e a estrutura não acompanha.
O gasto que mais pesa não é o que se faz a mais. É o que se investe em construir o produto errado, que obriga a recomeçar meses depois.
O que os orçamentos raramente incluem
Há uma parte do custo que quase nunca entra na conversa inicial, e é justamente a que se prolonga no tempo. Uma aplicação não termina no lançamento; é aí que começa a operar. Precisa de alojamento fiável, de segurança capaz de resistir a tentativas de intrusão e de manutenção contínua para acompanhar cada nova geração de dispositivos e de sistemas operativos.
Quando estes custos não constam do orçamento à partida, não desaparecem; apenas mudam de data. Reaparecem meses mais tarde, em regra quando o negócio menos os espera, e raramente por um valor menor.
O obstáculo é financeiro antes de ser técnico
É neste ponto que muitos projetos terminam, e a razão pouco tem que ver com tecnologia. Em Angola, poucas ideias fracassam por falta de mérito; fracassam no momento em que é exigido um investimento avultado, pago adiantado, apenas para começar. O empreendedor conhece o problema e tem o mercado identificado. Falta-lhe o capital inicial.
Foi precisamente esta constatação que nos levou a adotar outro modelo. Assumimos o custo de construção e entramos como parceiros do produto, não como fornecedores à espera de uma transferência. O empreendedor paga uma mensalidade que acompanha o crescimento do negócio, faturada trimestralmente, em vez de comprometer todo o capital antes de existir uma primeira versão no mercado.
Não se trata de generosidade nem de engenharia financeira; trata-se de alinhamento de interesses. Só ganhamos se o produto que construímos tiver sucesso, o que nos obriga a pensar como sócios desde a primeira reunião. O risco deixa de estar concentrado num só lado da mesa.
Como orçamentar sem surpresas
O ponto de partida não é o preço; é a clareza. Quanto mais precisa for a resposta à pergunta «para quem é este produto e que problema resolve melhor do que as alternativas», mais rigoroso será o orçamento apresentado. Um pedido vago gera sempre um valor inflacionado por precaução, porque quem orça protege-se da incerteza; um pedido claro permite um número em que se pode confiar.
Convém igualmente resistir à tentação de construir tudo de uma vez. A primeira versão não existe para impressionar; existe para colocar o produto perante utilizadores reais e observar o que acontece. Uma semana de utilização genuína ensina mais do que um caderno de requisitos, e corrige o rumo antes de os erros se tornarem dispendiosos.
Construir uma boa aplicação em Angola está hoje mais acessível do que há cinco anos. O que mudou não foi apenas a tecnologia; foi a possibilidade de escolher o modelo certo. E o preço certo nunca é o mais baixo que aparece. É aquele que permite lançar o produto sem colocar o negócio em risco.