Índice do artigofaltam 7 min de leitura
Nenhum cliente vai escolher você porque o seu login funciona. Construa o que ele escolhe e conecte o resto.
Todo projeto de plataforma começa com uma lista de funcionalidades, e essa lista quase sempre mistura duas coisas muito diferentes: o que só você pode fazer e o que o mercado já resolveu para todo mundo.
Separar as duas antes de orçar costuma mudar o tamanho do projeto. É a diferença entre construir um produto e reconstruir a infraestrutura que qualquer produto usa.
Resumo do artigo
- Toda lista de funcionalidades tem itens que diferenciam o produto e itens que são obrigação de qualquer software, e o segundo grupo costuma ser maior do que parece.
- O teste de uma pergunta: um cliente escolheria você por causa disso? Se não, é candidato a conectar em vez de construir.
- Componente regulado por terceiro envelhece sozinho, e assumir a manutenção dele significa herdar mudanças que você não controla.
- O erro simétrico existe: montar um produto só com peças de terceiros produz algo que qualquer concorrente monta igual.
A conta que muda o projeto: o que é seu e o que é de todo mundo
A lista de funcionalidades de um sistema novo engana porque trata todos os itens como iguais. "Cadastro de usuário" e "cálculo de rota de entrega otimizada" ocupam uma linha cada, e só um dos dois é o motivo pelo qual alguém compraria o seu produto.
O corte que organiza o projeto é entre diferencial e commodity. Diferencial é o que você faz melhor que o resto do setor, o que veio do seu conhecimento de operação, o que um concorrente teria dificuldade de copiar. Commodity é tudo que todo software precisa ter e ninguém elogia.
| Tipo de item | O que fazer com ele |
|---|---|
| Diferencial | Construir. É o que veio do seu conhecimento de setor e o único motivo pelo qual alguém escolhe você. |
| Commodity | Conectar a um serviço que já existe. Precisa funcionar e nunca é elogiado. |
| Estrutura de apoio | Montar com peças prontas, ajustando só o que o seu produto exige. |
A proporção entre os três grupos muda bastante de projeto para projeto, e não temos uma divisão padrão para recomendar. O que se repete é a ordem de importância: o diferencial costuma ser o menor dos três grupos e é o único que justifica o projeto existir.
O teste de uma pergunta para separar commodity de diferencial
Uma pergunta resolve a classificação da maior parte dos itens: um cliente escolheria você por causa disso?
Ninguém troca de fornecedor porque o login funciona. Ninguém recomenda um sistema porque ele envia e-mail. Ninguém paga mais caro porque a senha pode ser recuperada. Esses itens precisam existir e são invisíveis quando funcionam, o que é a definição prática de commodity.
Agora aplique a mesma pergunta ao que veio do seu conhecimento de setor: o controle que ninguém faz direito, o relatório que todo dono do ramo quer e nenhum sistema entrega, a regra que evita a perda que sempre acontece. Aí a resposta muda.
Essa parte precisa ser construída, e precisa ser construída bem. É o único lugar do projeto em que gastar mais tempo tem retorno direto em venda.
Existe um caso intermediário que confunde: algo que é commodity no mercado geral e diferencial no seu setor. Emissão de documento é commodity; emissão de documento com as particularidades do seu ramo pode ser exatamente o motivo da compra. A pergunta continua servindo, desde que você a faça pensando no seu comprador e não em software em geral.
O que quase nunca vale construir do zero
Alguns componentes quase nunca compensam ser construídos, e o motivo não é dificuldade técnica: é que eles mudam por decisão de terceiros e obrigam manutenção permanente.
- AutenticaçãoRegras de segurança mudam e erro aqui compromete tudo.
- Cobrança recorrenteMeio de pagamento, retentativa e conciliação são um produto inteiro.
- Mensagens e notificaçãoEntrega depende de reputação e de regras de operadoras e plataformas.
- Emissão fiscalA regra é do governo e muda sem pedir licença ao seu roteiro.
- Mapas e endereçoBase geográfica precisa ser atualizada continuamente por alguém.
- Armazenamento de arquivoCusto por volume e disponibilidade já são resolvidos e baratos.
O que esses seis têm em comum: a regra que governa cada um pertence a outra pessoa. Assumir a construção significa assumir também o acompanhamento da mudança dela, para sempre, num time que deveria estar trabalhando no que diferencia o produto.
O que quase sempre vale construir
Vale construir tudo aquilo que carrega o seu conhecimento de setor, porque é a única parte que o comprador não encontra em outro lugar. A regra é simples de enunciar e difícil de seguir, porque essa costuma ser a parte mais trabalhosa do projeto e a mais fácil de adiar.
Três categorias concentram quase todo o diferencial de uma plataforma de setor: a regra de negócio que traduz como aquele mercado funciona, a leitura dos dados que transforma operação em decisão, e o fluxo de trabalho que faz a equipe do cliente conseguir usar sem treinamento longo.
O terceiro item é o mais subestimado. Fluxo de trabalho não aparece em lista de funcionalidades e é o que decide se o cliente continua usando depois do primeiro mês. Um sistema com as funcionalidades certas na ordem errada perde para um mais simples que respeita a rotina de quem trabalha.
Comprar pronto, integrar ou construir: como decidir cada item
Cada item da lista tem três destinos possíveis, e a escolha depende de duas coisas: o quanto ele diferencia o produto e o quanto ele é regulado por terceiros. Colocar os dois eixos juntos resolve a maior parte das dúvidas.
O quadrante superior direito é o que mais gera erro de escopo. Ali estão os casos em que a regra do seu setor é diferencial e a execução é obrigação legal, e a resposta certa é dividir: a inteligência fica do seu lado, a execução regulada fica com quem já a mantém.
Isso destrava custo de duas formas. O projeto encolhe porque você para de reconstruir o que já existe, e a manutenção futura encolhe porque a parte que muda por decisão de terceiros deixa de ser sua responsabilidade.
A planilha que força a decisão
Uma lista de funcionalidades com custo ao lado de cada linha muda a conversa de escopo. É o artefato que usamos junto das propostas: em vez de um valor total fechado, o cliente recebe o preço de cada funcionalidade e monta a primeira versão escolhendo o que entra.
O efeito é imediato. Quando cada item tem um preço visível, a pergunta deixa de ser "cabe no orçamento?" e passa a ser "isso vale o que custa?". Itens que pareciam obrigatórios saem sozinhos, e sobra verba para o que realmente diferencia.
É também o momento em que a classificação deste artigo vira dinheiro: marcar quais linhas são diferencial e quais são commodity, e verificar se o gasto está concentrado no grupo certo. Uma primeira versão que gastou a maior parte do orçamento em commodity foi cara e não construiu vantagem nenhuma.
O erro de comprar tudo
O erro simétrico existe e é menos comentado: montar o produto inteiro com peças de terceiros e não construir nada. O resultado é rápido de entregar e não tem nada que sustente uma venda.
O que a montagem entrega
- Primeira versão no ar em menos tempo.
- Custo inicial menor e mais previsível.
- Componentes maduros, com problemas já resolvidos.
- Menos gente necessária para começar.
O que ela não entrega
- Qualquer coisa que um concorrente não monte igual.
- Controle sobre preço e condição dos fornecedores.
- Liberdade para mudar o que o componente não prevê.
- Um motivo para o cliente escolher você em vez do vizinho.
Existe ainda um risco concreto de dependência: preço, disponibilidade e condição de serviços de terceiros mudam por decisão deles. Isso se administra escolhendo componentes substituíveis e mantendo a regra de negócio do seu lado, de modo que trocar um fornecedor seja trabalhoso e não impossível.
A régua honesta: montar é a decisão certa para tudo que não diferencia, e é uma decisão insuficiente como estratégia de produto inteira.
O que fazer com o que ficou de fora da primeira versão
O que saiu da primeira versão não é lixo, é fila. Registrar essa fila com o motivo de cada corte é o que impede a discussão de recomeçar do zero a cada nova reunião.
O critério de reentrada que funciona é a demanda real, não a saudade do escopo original. Um item volta quando um cliente pagante pede, quando ele bloqueia uma venda concreta, ou quando o uso mostra que a ausência dele está gerando trabalho manual repetido.
Sem esse critério escrito, a fila vira uma lista de desejos antiga que ninguém consulta, e a decisão de escopo é refeita do zero em toda reunião.
Vale registrar junto de cada item cortado a razão do corte: se era commodity que passou a ser conectada, se era diferencial adiado por prazo, ou se era pedido de uma operação só. As três voltam por caminhos diferentes, e a terceira normalmente não volta. Como tratar essa terceira categoria está em Um cliente pediu um campo novo. Os outros trinta e nove vão herdar?.
Quer ver o custo por funcionalidade do seu projeto?
Solicite um orçamento e monte a primeira versão escolhendo o que entra.
Perguntas frequentes
Pergunte se um cliente escolheria você por causa dela. Login, cobrança, notificação e emissão fiscal ninguém escolhe. O que você faz melhor que o resto do setor é o que ele escolhe, e só isso precisa ser construído do zero.
Dá controle e cobra manutenção. Cada componente construído passa a ser seu para sempre, inclusive quando a regra externa mudar. Faz sentido no que é diferencial e raramente faz no que é obrigação de todo mundo.
Preço, disponibilidade e mudança de condição, que você não controla. Isso se administra escolhendo componentes substituíveis e mantendo a regra de negócio do seu lado, para que a troca seja trabalhosa e não impossível.
Autenticação, cobrança recorrente, envio de mensagem, emissão fiscal, mapas e armazenamento de arquivo. São problemas resolvidos, regulados por terceiros e que envelhecem sozinhos se você assumir a manutenção.
Não, porque a montagem também custa e porque um produto feito só de peças de terceiros não tem nada que o diferencie. O erro simétrico ao construir demais é montar um sistema que qualquer concorrente monta igual.
Listando cada funcionalidade com um custo ao lado e marcando qual delas é diferencial. A conversa deixa de ser sobre o valor total e passa a ser sobre quais itens merecem ser construídos agora.
Fontes e método
Este artigo descreve o método comercial e de escopo que a X-Apps aplica em propostas de plataforma, incluindo a prática de entregar alternativas de projeto acompanhadas de uma planilha com custo por funcionalidade, em que o cliente monta a primeira versão. O caso que originou o texto é uma negociação de agosto de 2026 com um operador de restaurante que pretende vender software para outros restaurantes, e foi anonimizado.
A classificação entre diferencial e commodity apresentada aqui é um critério de decisão, não uma medição. Não usamos proporções de mercado porque não temos base própria para afirmá-las.
