Quanto custa realmente uma aplicação à medida: uma análise honesta e transparente

Pergunte a três agências quanto custa uma aplicação à medida e obterá três números que nem sequer partilham um dígito. Uma diz quatro mil, outra quarenta, e a terceira diz baixinho «depende» e marca uma segunda reunião. Nenhuma está propriamente a mentir, mas nenhuma lhe está a dizer aquilo que realmente precisa de saber: para onde vai o dinheiro e porque é que a sua aplicação em concreto fica onde fica. Abramos então o capô.

Já redigi mais orçamentos de aplicações do que consigo contar, para empresas que vão desde o artesão em nome individual até à cadeia regional. A reação mais comum perante um preço não é o choque com o total, mas a confusão com a amplitude. Como pode o mesmo briefing de três palavras («uma aplicação de reservas») produzir estimativas que diferem num fator de dez? A resposta honesta é que «uma aplicação de reservas» não é um briefing. É um desejo. O preço vive nas cem pequenas decisões escondidas por baixo.

Este artigo é a análise que gostaria que todo o empresário tivesse em mãos antes da sua primeira chamada com um programador. Sem enchimentos, sem táticas de medo, sem venda forçada. Apenas as verdadeiras componentes do custo, as coisas que duplicam um orçamento em silêncio e algumas formas honestas de gastar menos sem acabar com algo de que se arrependa.

Porque é que dois orçamentos para «a mesma aplicação» diferem 10x

O software não é um produto que se tira de uma prateleira: é trabalho, medido nas horas de pessoas qualificadas. Por isso, o preço de uma aplicação à medida é, no fundo, simplesmente âmbito × tarifa horária × risco. Tudo o resto é uma nota de rodapé a estas três coisas. Quando dois orçamentos divergem muito, um destes três números está a ser lido de forma muito diferente, e normalmente ninguém o disse em voz alta.

O âmbito é o fator óbvio. «Uma aplicação de reservas» pode significar um único ecrã onde os clientes escolhem um horário, ou pode significar calendários de pessoal, pagamentos, lembretes, um acesso de cliente, um painel de administração, reembolsos e um relatório que o dono lê à segunda-feira. As mesmas três palavras, dez vezes o trabalho. O orçamento barato pressupõe muitas vezes a versão pequena; o caro pressupõe em silêncio a grande. Nenhum lhe perguntou a qual se referia.

Depois há o risco, a parte que ninguém gosta de orçamentar. Um briefing vago, um cliente que ainda não decidiu o que quer, uma integração com um sistema antigo e frágil: isto não acrescenta apenas horas, acrescenta incerteza. As equipas experientes deixam margem para a incerteza porque já se queimaram com ela. Um orçamento mais barato muitas vezes nem sequer orçamentou o risco, e é precisamente por isso que por vezes dispara a meio do caminho.

Para onde vai realmente o dinheiro

Quando se imagina o desenvolvimento de uma aplicação, imagina-se programar. Programar é real, mas raramente representa sequer metade da fatura. Uma aplicação à medida está mais próxima de construir uma casa pequena do que de escrever um documento: em torno da parte visível há projeto, canalizações, vistoria e papelada. Eis como se reparte um orçamento típico quando se contabiliza tudo.

Duas coisas costumam surpreender naquela tabela. Primeiro, quanto do orçamento ocorre antes de se escrever uma única linha de código funcional: levantamento e design não são um luxo, são o lugar mais barato para corrigir um erro. Mudar um ecrã num esboço custa minutos; mudá-lo depois de construído custa dias. Segundo, quão real é a linha dos testes. Saltá-la não poupa dinheiro, apenas transfere o custo para a sua semana de lançamento, com juros.

Levantamento e design: a parte que toda a gente quer saltar

O levantamento é onde transforma «uma aplicação de reservas» numa lista precisa de ecrãs e regras. Parece um custo acessório porque ainda nada está a ser construído. Mas cada hora aqui poupa várias mais à frente, porque é onde a ambiguidade é eliminada enquanto ainda é barata. Uma equipa que lhe indica um preço sem fase de levantamento ou está a adivinhar, ou tenciona faturar-lhe o levantamento mais tarde com outro nome.

Desenvolvimento central: o motor visível

É o código que faz a sua ideia funcionar: os ecrãs em que as pessoas tocam, a lógica por detrás deles e a base de dados que recorda tudo em silêncio. É a maior fatia isolada e cresce quase diretamente com o âmbito. Cada funcionalidade que acrescenta é mais para construir, mais para testar e mais para manter para sempre. É a linha onde «era bom que...» se torna caro depressa.

Integrações: a parte enganadoramente cara

Ligar a sua aplicação a outros sistemas — receber um pagamento com cartão, enviar um lembrete por SMS, sincronizar um calendário, extrair dados do software de contabilidade que já usa — parece pouco numa lista de funcionalidades e pesa surpreendentemente na fatura. Cada ligação é um pequeno projeto por si só, com as suas próprias particularidades e modos de falha. Uma integração de pagamentos bem comportada não é problema. Cinco integrações emaranhadas com um sistema interno envelhecido é onde os orçamentos vão morrer.

Os custos que ninguém põe no orçamento

É aqui que muitos empresários levam uma surpresa desagradável ao fim de doze meses. A construção é um número único; uma aplicação não é uma coisa de uma só vez. O software é vivo — os telefones atualizam-se, as regras mudam, o seu negócio cresce — e uma coisa viva precisa de ser alimentada. O orçamento que assina é o preço do nascimento, não o preço da posse.

Nada disto é uma fraude nem uma armadilha escondida: é apenas a parte que não cabe bem num orçamento de uma página, por isso os parceiros mais fracos deixam-na de fora para parecerem mais baratos. Um bom parceiro fala-lhe disto à partida, ainda que isso faça o seu primeiro número parecer maior. Pergunte explicitamente: quanto me custa manter isto a funcionar durante um ano após o lançamento? A qualidade da resposta diz-lhe muito sobre com quem está a lidar.

O que duplica o preço em silêncio

Algumas coisas acrescentam custo em proporção ao valor que trazem: justo. Outras acrescentam custo de forma totalmente desproporcionada, normalmente por causa de como o trabalho está estruturado e não do que a aplicação faz. Vale a pena compreender estas alavancas, porque algumas estão inteiramente nas suas mãos.

• Duas plataformas em vez de uma. Uma aplicação nativa para iPhone e uma aplicação nativa para Android são, grosso modo, duas construções. Ferramentas multiplataforma ou uma aplicação web podem reduzir isso de novo para uma só. Esta única escolha pode mover o total mais do que qualquer funcionalidade.
• Design à medida em vez de opções predefinidas sensatas. Uma interface totalmente à medida e ajustada ao pixel custa dinheiro a sério para desenhar e construir. Uma limpa e convencional, assente em padrões comprovados, é mais rápida, mais barata e muitas vezes mais fácil de usar para os clientes.
• Mudar de ideias depois de a construção começar. As decisões são baratas num quadro branco e caras no código. A derrapagem de orçamento mais comum não é uma má estimativa, mas um âmbito que não parou de crescer porque nada estava fechado.
• Tempo real, offline ou dados pesados. «Tem de funcionar sem rede» ou «as atualizações têm de aparecer instantaneamente para todos» são pedidos razoáveis que multiplicam em silêncio a engenharia subjacente.
• Integrar com algo antigo e não documentado. Ligar a um sistema moderno e bem construído é rotina. Ligar a uma ferramenta interna de quinze anos sem documentação é arqueologia, e fatura-se à hora.

Um exemplo real: o orçamento de 60.000 € que se tornou uma aplicação de 14.000 €

Alguns detalhes foram alterados por privacidade, mas a essência disto é verdadeira e totalmente típica. Uma empresa de serviços regional — imagine uma dúzia de técnicos no terreno e um escritório movimentado — veio ter connosco frustrada. Queria uma aplicação à medida para que os seus clientes marcassem serviços, acompanhassem o progresso e pagassem. Já tinha recebido noutro lado um orçamento de cerca de 60.000 €, mais uma choruda mensalidade, e isso afastara-a da ideia toda durante quase um ano.

Quando mapeámos de facto aquilo de que precisava — e não o que lhe tinham orçamentado — o quadro era bem diferente. O primeiro orçamento pressupusera duas aplicações totalmente nativas, um design à medida de raiz, um sistema de despacho em tempo real e uma plataforma de administração à medida para substituir ferramentas que já possuía e com as quais estava discretamente satisfeita. Era, tecnicamente, uma aplicação perfeitamente boa. Era também a resposta a uma pergunta que não tinha feito.

O que fizemos na realidade

Dedicámos as primeiras sessões apenas ao levantamento, separando o desejo entre «o negócio para sem isto» e «aquilo seria bom um dia». Os indispensáveis eram mais reduzidos do que qualquer um esperava: uma forma limpa de os clientes pedirem e acompanharem um serviço, lembretes automáticos e pagamento online. O despacho em tempo real e o back office à medida revelaram-se soluções para problemas que o software existente já resolvia bem.

1. 1
   Cortar o âmbito para o trabalho real

   Eliminámos as funcionalidades que resolviam problemas que não tinham e mantivemos uma lista enxuta sem a qual o negócio realmente não conseguia operar.
2. 2
   Escolher uma única construção multiplataforma

   Em vez de duas aplicações nativas separadas, uma única aplicação multiplataforma cobria iPhone e Android, reduzindo para cerca de metade o desenvolvimento central.
3. 3
   Usar padrões de design comprovados

   Uma interface limpa e convencional em vez de uma à medida. Os clientes acharam-na mais fácil de usar e poupou semanas no calendário.
4. 4
   Ligar, não substituir

   Ligámos a aplicação ao software de escritório que já pagavam, em vez de o reconstruir. A dispendiosa «plataforma de administração à medida» simplesmente desapareceu do âmbito.

O resultado foi uma construção de cerca de 14.000 €, em produção em poucos meses, com custos de funcionamento que conseguiam prever. Não é tão extensa como a versão de 60.000 € — e não precisa de ser. Faz o trabalho que o negócio tinha de facto. Um ano depois, acrescentaram duas pequenas funcionalidades por cima, pagas com o dinheiro que a primeira versão lhes poupou. É todo este o padrão: começar pelo trabalho real, conquistar os extras com resultados.

Como manter o custo sob controlo sem cortar onde não deve

Gastar menos numa aplicação à medida não passa por regatear a tarifa horária nem por encontrar a equipa mais barata que conseguir. É assim que se acaba a pagar duas vezes. Passa por ser deliberado quanto ao âmbito, à sequência e às decisões: as três coisas que realmente movem o número. É aqui que vivem as verdadeiras poupanças.

Primeiro, construa a versão mais pequena que seja realmente útil e depois faça-a crescer. Um primeiro lançamento focado que faz bem uma só coisa coloca-o em produção mais depressa, custa uma fração do sonho tudo-em-um e — crucialmente — ensina-lhe o que construir a seguir a partir de clientes reais em vez de suposições. Segundo, tome as suas decisões antes de a construção começar; a indecisão é a coisa mais cara que pode levar para um projeto. Terceiro, ligue-se ao que já possui em vez de substituir ferramentas que funcionam, e só reconstrua algo quando este o estiver realmente a travar.

Perguntas frequentes