Quanto custa um software sob medida: o que pesa no preço

Quanto custa um software sob medida: a resposta curta

O custo de um software sob medida é, no fundo, o custo do tempo de uma equipe. Pessoas que analisam, desenham, programam, testam e publicam, durante um certo número de semanas ou meses. Todo o resto (tecnologia, hospedagem, ferramentas) é secundário na maioria dos projetos.

Por isso a pergunta útil não é qual o preço de um sistema, e sim quantas semanas de trabalho de qual tipo de equipe o seu problema exige. Um cadastro com três telas e um relatório é um problema pequeno. Um sistema com faturamento, estoque, aplicativo de campo e integração com o ERP da empresa é outro bem diferente, mesmo que os dois sejam chamados de sistema.

Na prática, projetos parecidos na aparência podem ter preços muito distantes, e projetos com preços parecidos podem entregar coisas bem diferentes. É por isso que o preço de sistema sob medida só faz sentido quando vem acompanhado de um escopo e de um prazo.

Do que o preço de um sistema sob medida realmente depende

Estes são os fatores que, na nossa experiência, mais movem o orçamento, mais ou menos em ordem de peso. A ordem muda conforme o projeto, mas as regras de negócio e as integrações aparecem quase sempre no topo.

Telas são o que o cliente vê, por isso ganham atenção demais. O que custa de verdade costuma estar embaixo delas.

• Regras de negócio: cálculo de comissão, aprovação em várias etapas, exceções por tipo de cliente. Cada regra precisa ser entendida, implementada e testada, e as exceções multiplicam os casos de teste.
• Número de perfis de usuário: administrador, gerente, operador e cliente final enxergam e podem fazer coisas diferentes. Cada perfil adiciona telas, permissões e testes.
• Quantidade e complexidade das telas: uma tela de listagem simples é barata; uma tela com filtros combinados, edição em lote e gráficos não é.
• Integrações: ligar com ERP, meio de pagamento, nota fiscal, e-mail, mensageria ou sistemas de terceiros. Cada integração depende da qualidade da documentação do outro lado e da estabilidade da API deles.
• Migração de dados: trazer a base do sistema antigo costuma ser subestimado. Dados sujos, duplicados e sem padrão dão trabalho.
• Plataformas: web, Android, iOS ou todas. Um aplicativo para lojas de aplicativos também envolve publicação, revisão das lojas e atualizações.
• Requisitos não funcionais: segurança, auditoria, desempenho com muitos usuários, funcionamento offline, conformidade com regras de proteção de dados.
• Equipe e senioridade: uma equipe mais experiente cobra mais por hora e costuma gastar menos horas e errar menos em decisões de arquitetura.
• Prazo: querer tudo rápido exige mais gente em paralelo, e isso aumenta o custo de coordenação. Prazo apertado quase nunca sai de graça.
• Infraestrutura e manutenção: onde o sistema roda, quem monitora, quem corrige, quem evolui. Falamos disso mais adiante.

Modelos de contratação: preço fechado, tempo e material e squad dedicado

O modelo de contratação define quem carrega o risco de o projeto custar mais do que o previsto. Não existe o melhor modelo; existe o que combina com o grau de incerteza do seu projeto.

No preço fechado, a software house se compromete com um valor para um escopo definido. A vantagem é a previsibilidade: você sabe quanto vai pagar. O ponto fraco é que qualquer mudança vira pedido de alteração, com negociação e custo extra. E, como o fornecedor assume o risco, ele coloca uma margem de segurança no preço. Funciona bem quando o escopo é claro e estável, como um módulo bem especificado ou a reconstrução de algo que já existe e que todo mundo conhece.

No tempo e material, você paga pelas horas ou semanas efetivamente trabalhadas, com um valor combinado por profissional. A vantagem é a flexibilidade: o escopo pode mudar a cada ciclo, e você paga só pelo que foi feito. O ponto fraco é que o orçamento final é uma estimativa, e sem acompanhamento próximo ele pode crescer. Funciona bem quando há incerteza real, como um produto novo cujo caminho vai ser descoberto durante o desenvolvimento. Exige um cliente presente, que priorize e diga não.

No squad dedicado, uma equipe fica alocada ao seu produto por um período longo, com custo mensal previsível. A vantagem é o conhecimento acumulado e a velocidade constante. O ponto fraco é que você paga a equipe inteira mesmo nos meses em que a fila de demandas é menor. Funciona bem para produtos em evolução contínua, não para projetos com começo, meio e fim bem definidos.

Um arranjo que vemos funcionar com frequência é híbrido: preço fechado para uma primeira versão bem delimitada, e depois tempo e material ou mensalidade para evoluir e manter. Você ganha previsibilidade no começo, quando a confiança entre as partes ainda está sendo construída, e flexibilidade depois, quando o uso real mostra o que importa.

Como escrever o escopo e o prazo do software sem virar contrato de 200 páginas

Quase todo estouro de custo começa num escopo vago. O escopo e prazo de software andam juntos: sem o primeiro, o segundo é palpite. E escopo não é uma lista de desejos; é uma descrição do que será entregue, em que condições, e do que fica de fora.

Você não precisa de um documento técnico. Precisa de clareza sobre o problema e sobre o que significa estar pronto.

• Comece pelo problema, não pela solução: quem sofre hoje, com qual processo, e o que muda quando o sistema existir.
• Liste os perfis de usuário e o que cada um precisa fazer, em frases simples como o operador registra uma entrada de material e o gerente aprova.
• Descreva os fluxos principais do começo ao fim, incluindo as exceções que acontecem toda semana. As exceções raras podem esperar.
• Separe o que é indispensável na primeira versão do que é desejável. Essa separação é a ferramenta de controle de custo mais eficiente que existe.
• Liste as integrações com nome, e peça acesso à documentação delas antes de fechar o prazo.
• Diga o que está fora do escopo. Escrever que relatórios avançados e aplicativo para iOS ficam para uma segunda fase evita muita discussão depois.
• Defina o critério de aceite: como vocês vão concluir juntos que cada entrega está pronta.
• Registre as premissas: por exemplo, que o cliente responde às dúvidas em até dois dias úteis e fornece os dados para migração até certa data.

Como pedir e comparar orçamentos de desenvolvimento de software

O erro mais comum que se vê é pedir três orçamentos com três descrições diferentes, de forma verbal, e depois comparar os números. O resultado é comparar coisas que não são comparáveis. Um orçamento de desenvolvimento de software só ajuda se todos os fornecedores partirem do mesmo material.

Entregue o mesmo documento de escopo a todos, mesmo que seja de uma página, e responda às mesmas dúvidas para todos. Depois, olhe além do valor total.

Na hora de ler as propostas, pergunte e compare estes pontos:

• O que está dentro e o que está fora, item por item. Uma proposta barata muitas vezes deixa de fora testes, publicação nas lojas, migração de dados ou treinamento.
• Como o valor foi composto: número de pessoas, perfis, semanas. Proposta sem esse detalhe esconde premissas.
• Como mudanças de escopo serão tratadas e quanto custa uma hora ou semana adicional.
• Quem é dono do código e da documentação ao final, e se você consegue levar o projeto para outra equipe.
• Como funcionam as entregas: de quanto em quanto tempo você vê algo funcionando, e não só relatórios de andamento.
• O que acontece depois da entrega: garantia, correção de erros, suporte e evolução.
• Quem de fato vai trabalhar no projeto, e não só quem aparece na reunião comercial.

O que faz estourar prazo e custo em projetos de software

Estouro quase nunca vem de programadores lentos. Vem de decisões que ficaram para depois. Os motivos mais frequentes são sempre os mesmos, e todos podem ser reduzidos com conversa franca no começo.

O primeiro é o escopo que cresce sem ser registrado. Cada pequeno só mais uma coisa parece inofensivo, e a soma de vinte deles muda o projeto. A saída é ter um jeito simples de registrar cada pedido novo e dizer o que ele desloca ou quanto custa.

O segundo é a demora do lado do cliente. Aprovações paradas, dúvidas sem resposta e dados que não chegam travam a equipe, e o relógio continua correndo. Se a equipe fica parada esperando, alguém paga por isso.

O terceiro é a integração que se mostra pior do que parecia. Documentação desatualizada, ambiente de testes que não existe, API que cai. Por isso recomendamos validar as integrações críticas nas primeiras semanas, e não no final.

O quarto é a regra de negócio que ninguém sabia que existia. Em empresas com anos de operação, boa parte do processo está na cabeça das pessoas e em planilhas. Ela aparece durante os testes, quando o usuário diz que ali não é bem assim. Conversar com quem opera o processo no dia a dia, e não só com quem o gerencia, evita boa parte dessas surpresas.

O quinto é decidir tudo de uma vez e ver o resultado só no fim. Quanto mais tempo se passa sem ver o software funcionando, maior o risco de construir a coisa errada com perfeição. Entregas curtas e frequentes, com o usuário real testando, são o melhor antídoto.

Custos que quase ninguém conta: manutenção, hospedagem e evolução

O orçamento inicial é só uma parte do custo total. Software não é uma obra que se entrega e se esquece; ele precisa de manutenção, porque sistemas operacionais mudam, bibliotecas ficam desatualizadas, lojas de aplicativos mudam regras e usuários descobrem coisas que querem de diferente. Esse custo é recorrente: acompanha o sistema enquanto ele estiver em uso e precisa entrar no orçamento desde o início, não depois.

Ao planejar o orçamento, considere pelo menos estes itens:

• Hospedagem e infraestrutura: servidores ou nuvem, banco de dados, armazenamento, backups, certificados e monitoramento. O custo cresce com o uso.
• Manutenção corretiva: erros que aparecem com o uso real e precisam de conserto.
• Manutenção preventiva: atualização de dependências, correções de segurança, compatibilidade com novas versões de Android e iOS.
• Serviços de terceiros: envio de e-mail e SMS, mapas, meios de pagamento, notificações. Muitos cobram por volume.
• Contas de desenvolvedor nas lojas de aplicativos, quando houver aplicativo.
• Evolução: novas funcionalidades pedidas depois que o sistema entra em uso. É o sinal de que o software está sendo útil, e deve ter orçamento próprio.
• Suporte e treinamento de novos usuários.

Como reduzir o risco começando pequeno

A forma mais segura de gastar bem em software é não comprar tudo de uma vez. Comece pela menor versão que já resolve uma dor real, ponha na mão dos usuários e deixe o uso decidir o que vem depois. Isso é mais barato do que parece, porque a maior parte do desperdício em software vem de funcionalidades construídas e nunca usadas.

Antes do código, vale ver o produto. Um protótipo navegável mostra telas e fluxos em poucos dias, e é nele que o cliente descobre que faltava um perfil de usuário ou que um fluxo não funciona como imaginava. Corrigir isso num protótipo custa quase nada; corrigir depois de programado custa semanas. É por isso que, na SKAD, você pode ver o seu aplicativo no protótipo grátis com orçamento aproximado antes de decidir contratar qualquer coisa.

Se você já tem um sistema antigo, o caminho mais barato muitas vezes não é reescrever tudo. É trocar por partes, mantendo a operação rodando, com cada módulo novo entrando no lugar de um velho. É o que fazemos na modernização de sistemas legados, de forma incremental e acelerada com IA, sem parar a empresa. O risco fica distribuído em etapas pequenas, e você pode parar ou mudar de direção a cada uma.

Por fim, escolher bem quem vai construir pesa tanto quanto o modelo. Reunimos as perguntas que importam em como escolher uma software house, e vale lê-las antes de assinar. E, para planejar o que vem depois da entrega, veja o que normalmente entra em contratos de manutenção de software.

Perguntas frequentes

Conclusão

Antes de pedir qualquer orçamento, escreva em uma página o problema, os perfis de usuário e as três coisas que o sistema precisa fazer na primeira versão. Com isso na mão, você consegue comparar propostas de forma justa e sabe o que cortar se o valor passar do que você pode investir. O próximo passo mais barato é ver o aplicativo antes de contratá-lo: peça o protótipo grátis da SKAD e receba, junto com ele, um orçamento aproximado para decidir com algo concreto na mão.