Sistema sob medida ou software de prateleira: quando construir compensa (build vs. buy honesto)

**Quando construir um sistema web sob medida compensa?** Quando o fluxo de trabalho é diferencial competitivo, o custo por usuário cresce mais rápido que a operação, os dados precisam morar em base própria e o time já paga, em gambiarra, o preço de se adaptar à ferramenta. Fora desses casos, comprar pronto é a decisão certa.

— Na maioria dos casos, assinar o produto pronto é a escolha certa: o SaaS já pagou o custo de descobrir o problema com uma base ampla de clientes.

— Quatro sinais justificam construir: fluxo que é diferencial, custo por assento crescendo mais rápido que a operação, dado que precisa morar em base própria e gambiarra recorrente para caber na ferramenta.

— Quatro sinais indicam prejuízo: processo instável, poucos usuários, necessidade puramente fiscal ou contábil e ninguém dono do produto do lado do cliente.

— A comparação justa não é preço de construção contra mensalidade — sistema próprio tem custo de operação continuada que a mensalidade do SaaS embute e dilui.

— Se a resposta for construir, o menor risco é recortar a primeira entrega útil no fluxo que mais dói, não reescrever a operação inteira.

**Na maioria dos casos, comprar a ferramenta pronta é a decisão certa**

**Software de prateleira** é o produto pronto assinado por mensalidade — o que o mercado chama de SaaS, software entregue como serviço pela internet. **Sistema sob medida** é construído para um processo específico, com código e banco de dados próprios.

A Projask ganha mais em recusar o projeto errado do que em construí-lo: projeto que não deveria existir vira retrabalho, suporte e cliente insatisfeito.

O SaaS já pagou o custo de descobrir o problema com uma base ampla de clientes: casos de borda que ninguém previu, anos de correção. Ao assinar, você compra esse aprendizado, não só a tela.

**Quando construir um sistema web sob medida: os quatro sinais que justificam**

— **O fluxo de trabalho é o diferencial competitivo e nenhum produto o modela.** O jeito de fazer é parte do motivo pelo qual o cliente escolhe você. Trade-off: se o fluxo é igual ao do concorrente, construir só recria o que já existe, mais caro e com menos maturidade.

— **O custo por usuário cresce mais rápido que a operação.** Licença cobrada por assento — um valor mensal por usuário ativo — penaliza crescimento de time. O teste é projetar a mensalidade no número de usuários do ano que vem e comparar com construir *mais* operar, nunca com construir apenas.

— **Os dados precisam morar em base própria, consultável e exportável.** Cruzamento entre áreas, relatório que o produto não oferece, integração com o que já existe na casa. Vale aqui o mesmo princípio da [titularidade de domínio e código](/blog/titularidade-de-dominio-e-codigo-em-projeto-de-software/): o ativo fica no seu nome ou não é seu.

— **O time já paga, em trabalho manual, o preço de se adaptar à ferramenta.** Planilha paralela, recadastro do mesmo dado, campo usado para outra coisa, conferência humana no fim do mês. É custo real, pago em hora de gente, e não aparece na fatura.

Um sinal isolado raramente basta. Dois ou mais, sustentados por meses, é o que muda a conta. Uma semana ruim com a ferramenta atual não é sinal — é uma semana ruim.

**Os quatro sinais de que construir vai dar prejuízo**

— **Processo ainda instável.** O que muda toda semana não tem o que ser modelado. Software congela decisão, e congelar decisão provisória é caro: cada regra nova vira alteração de código.

— **Poucos usuários.** Com time pequeno, a mensalidade quase nunca supera o custo de construir mais manter. O assento sai barato exatamente onde ele é pouco.

— **Necessidade puramente contábil ou fiscal.** Obrigação legal muda por fora, no calendário de terceiros. Manter isso em dia é trabalho contínuo que o produto de mercado já faz para todos os clientes ao mesmo tempo.

— **Ninguém dono do produto do lado do cliente.** Sem uma pessoa que decide e responde, o projeto vira arbitragem de preferência alheia — o mesmo efeito de comitê que [estoura prazo em qualquer projeto de software](/blog/prazo-entrega-software/).

Nesses quatro casos, a resposta honesta é adaptar o processo à ferramenta pronta e revisar a decisão em alguns meses. Não é "nunca"; é "ainda não".

**Mensalidade e custo de propriedade: as duas contas que a comparação esquece**

**Custo de propriedade** é tudo que o sistema consome depois de pronto: deploy, certificado HTTPS renovado, backup verificado — backup que ninguém testou é esperança, não backup —, observabilidade, correção de defeito e atualização de dependências por segurança.

A mensalidade do SaaS embute esse custo e o dilui entre todos os clientes. No sistema próprio, ele aparece como linha separada e recorrente no seu orçamento, e [o que se mede e se alerta](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/) se dimensiona pelo custo de uma hora fora do ar.

Comparação justa: mensalidade do SaaS × (investimento de construção amortizado + operação continuada). Comparar só o preço de construção contra a mensalidade é comparar coisas diferentes — e erra nos dois sentidos.

A faixa pública da Projask entra como referência de partida: R$ 2.500 para sistema web sob medida. É partida, não estimativa do seu caso, que depende do escopo escrito. As faixas estão no [guia de quanto custa criar um site](/blog/quanto-custa-criar-um-site-em-2026/) e a lógica de data, no [texto sobre prazo de entrega](/blog/prazo-entrega-software/).

O trade-off é declarável: o sistema próprio troca despesa previsível por ativo controlado — e por responsabilidade de operar.

**O meio-termo que resolve mais casos do que os dois extremos**

O que é commodity — emissão fiscal, folha, e-mail, contabilidade — continua em produto pronto, e deve continuar. Sob medida entra só no fluxo que é diferencial, o que costuma ser uma fatia estreita da operação, não a operação inteira.

O critério para separar é simples: se um concorrente pode assinar a mesma ferramenta e obter o mesmo resultado, aquilo não é diferencial. É infraestrutura de negócio, e infraestrutura se compra.

A ressalva honesta: dois sistemas convivendo significa o mesmo dado em dois lugares. Alguém precisa decidir qual é a fonte da verdade — qual sistema manda quando os dois discordam — e como o dado atravessa de um para o outro. Esse é o preço do meio-termo.

**Se a resposta for construir, comece pelo fluxo que dói mais**

Recorte a **primeira entrega útil**: a menor versão que já entra em uso real, no fluxo que mais dói hoje — é o que um ciclo [da descoberta ao deploy](/blog/da-descoberta-ao-deploy-com-fabrica-de-software/) entrega em fatias, com risco medido a cada uma. Não é demonstração de reunião e não é o sistema completo.

Escopo em uma página, com critério de aceite — a frase verificável que decide sozinha se algo está pronto. [Escrever esse escopo antes de pedir orçamento](/blog/escopo-de-projeto-de-software/) é exercício curto que evita retrabalho caro depois.

Reescrever a operação inteira de uma vez é o caminho de maior risco — pelo mesmo motivo que [refazer um site sem plano de migração](/blog/plano-migracao-site/) sai caro. Concentra erro, adia o aprendizado e só revela o problema quando todo o orçamento já foi gasto.

Defina na entrada o que fica no seu nome: domínio, repositório, banco de dados e contas de terceiros. Isso se resolve no primeiro dia ou vira negociação ruim no dia da saída.

Depois da primeira entrega, o uso real corrige a hipótese. As fatias seguintes ficam mais baratas de acertar, porque deixam de ser chute.

**O que perguntar antes de pedir orçamento de um sistema sob medida**

1. Qual fluxo, nomeado, entra na primeira entrega — e o que fica de fora dela?

2. Quanto custa a operação continuada depois do go-live, e o que ela inclui?

3. Em nome de quem ficam domínio, código, servidor e banco de dados?

4. Como eu exporto os dados se eu quiser sair?

5. Já existe produto de mercado que resolve a maior parte disso — e por que o que sobra justifica construir?

A reação às perguntas já é informação. Fornecedor com processo responde sem rodeio e costuma devolver perguntas. Quem não recomenda comprar pronto em nenhum cenário está vendendo, não avaliando — é o mesmo sinal que o [checklist para escolher uma fábrica de software](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/) usa para separar proposta de promessa.

**Build vs. buy: a decisão cabe em uma frase**

Construa quando o fluxo é o diferencial e o mercado não o modela. Compre quando o problema é comum e alguém já o resolveu melhor do que você resolveria — que é a maioria dos problemas de uma operação.

Na dúvida, compre pronto e refaça a conta quando os sinais se sustentarem por meses. A decisão adiada custa mensalidade; a decisão errada custa o projeto inteiro.

Quando construir for a resposta, o menor risco é começar estreito: um fluxo nomeado, escopo escrito, critério de aceite e os ativos no seu nome desde o primeiro dia.

**Quando faz sentido construir um sistema web sob medida em vez de assinar um SaaS?**

Construir compensa quando o fluxo de trabalho é diferencial competitivo e nenhum produto o modela. Também quando o custo por usuário cresce mais rápido que a operação (modelo de licença por assento), quando os dados precisam morar em base própria e consultável, ou quando o time já paga em trabalho manual o preço de se adaptar à ferramenta pronta.

Um sinal isolado raramente basta. Dois ou mais sinais sustentados por meses é o que muda a conta. Uma semana ruim com a ferramenta atual não é sinal — é uma semana ruim.

**Qual é a diferença real de custo entre construir e comprar software?**

A comparação justa não é preço de construção contra mensalidade. O correto é comparar a mensalidade do SaaS contra o investimento de construção amortizado mais o custo de operação continuada.

A mensalidade do SaaS já embute todos os custos de propriedade e os dilui entre clientes. No sistema próprio, esses custos aparecem como despesa recorrente separada no orçamento e precisam estar inclusos na decisão final.

**Qual é o custo oculto de manter um sistema próprio depois de pronto?**

Custo de propriedade inclui tudo que o sistema consome após o deploy: renovação de certificado HTTPS, backup verificado, observabilidade, correção de defeito, atualização de dependências por segurança e infraestrutura geral.

Esse custo é real e recorrente. O dimensionamento correto considera o custo de uma hora fora do ar, então deve estar incluído na projeção de viabilidade desde o início.

**Como reduzir o risco quando a decisão é construir um sistema?**

Comece com a primeira entrega útil: a menor versão que entra em uso real no fluxo que mais dói hoje. Isso reduz concentração de erro e deixa o aprendizado acontecer cedo.

Escreva o escopo em uma página com critério de aceite verificável. Defina na entrada o que fica no seu nome: domínio, repositório, banco de dados e contas de terceiros. Reescrever a operação inteira de uma vez é o caminho de maior risco.

**O que perguntar antes de pedir orçamento para um sistema sob medida?**

Qual fluxo específico entra na primeira entrega e o que fica de fora? Quanto custa a operação continuada e o que inclui? Em nome de quem ficam os ativos (domínio, código, servidor, banco)? Como exportar dados se quiser sair? Já existe produto de mercado que resolve a maior parte — por que o que sobra justifica construir?

A reação a essas perguntas já é informação valiosa. Fornecedor com processo responde sem rodeio. Quem nunca recomenda comprar pronto em nenhum cenário está vendendo, não avaliando.