Quem já paga um sistema pronto e sente falta de alguma coisa tem três saídas, nesta ordem de custo: ligar o que o sistema já oferece, integrar em volta dele ou construir um módulo ao lado, e construir um sistema próprio. Numa auditoria que fizemos, três dos quatro pedidos de um cliente já existiam no sistema que ele pagava, desligados. O sistema próprio se paga quando o processo é o que o seu cliente compra de você, e mesmo assim ele pode conviver com o sistema pronto em vez de substituí-lo.
Por onde começar quando o sistema pronto não faz tudo#
Quem já paga um sistema pronto e sente falta de alguma coisa tem três saídas, que custam mais nesta ordem: ligar ou configurar o que o sistema já oferece, integrar em volta dele ou construir um módulo ao lado, e construir um sistema próprio. Vale testar as três nessa sequência, porque a maior parte das faltas se resolve nas duas primeiras.
A conversa costuma chegar assim: a empresa usa um SaaS ou um ERP de mercado, gosta dele na maior parte e tem uma lista de três ou quatro coisas que ele "não faz". Daí a pergunta vira se é hora de contratar um sistema sob medida, e ainda é cedo para ela.
Antes, cada item da lista passa por três perguntas, uma para cada saída. O sistema já faz isso e está desligado? O dado já está lá dentro e falta uma tela ou um fluxo em volta? Ou o que falta não tem lugar nenhum no sistema que existe? Cada item pode cair numa saída diferente, e é comum três se resolverem configurando e só um pedir software.
| Situação | Configurar o que existe | Integrar ou construir ao lado | Construir o próprio |
|---|---|---|---|
| A função está no menu, mas desligada ou zerada | resolve, com horas de ajuste | não precisa | seria pagar de novo pelo que já se paga |
| A função existe num plano mais caro do mesmo fornecedor | resolve, se a diferença de mensalidade couber | só se o plano for caro demais para o uso | raramente compensa |
| O dado está no sistema e falta a leitura: meta, painel, relatório cruzado | às vezes, pelo relatório do próprio sistema | resolve: ler o dado e montar a tela fora | troca desnecessária |
| Falta um processo inteiro, que usa dado do sistema pronto | não alcança | resolve: um módulo ao lado que lê do sistema que fica | só se o resto do sistema também não servir |
| O dado que a decisão precisa não tem campo no cadastro | não alcança | resolve, se esse cadastro puder viver fora do sistema pronto | resolve, quando esse dado está no centro da operação |
| O processo é o que o seu cliente compra de você | não alcança | alcança só a borda | é aqui que o próprio se paga |
| O fornecedor não deixa o dado sair | não se aplica | com alcance limitado, por exportação | entra na conta, porque o limite dele vira limite seu |
Como descobrir se o que falta já está no sistema, desligado#
A forma mais segura é entrar no sistema por dentro, logado, com quem opera do lado, e conferir cada item da lista contra o menu inteiro, os cadastros e as configurações. Numa auditoria que fizemos em agosto de 2026, três dos quatro pedidos de um cliente já existiam no sistema que ele pagava, desligados ou configurados em zero.
Isso é mais comum do que parece. Segundo o relatório de adoção de funcionalidades de 2019 da Pendo, empresa americana que mede o uso de software, 80% das funcionalidades do software médio são raramente ou nunca usadas, numa amostra de 615 contas de clientes dela.
O caso de agosto era um SaaS de gestão em uso havia cinco meses, que segundo o próprio cliente atendia muito bem. O pedido era um sistema próprio com quatro melhorias. Entramos com o acesso que o cliente cedeu e achamos três delas no sistema atual: uma estava ligada, com 1 dos 120 serviços publicado; outra existia com outro nome e estava em zero nos 120; a terceira era um módulo nunca ativado. Contamos esse caso, com o roteiro da auditoria, no artigo sobre quando o sistema legado precisa ser substituído.
A mesma sessão mostrou uma coisa que nenhum briefing mostra. Um dos pedidos era um programa de fidelidade com mensalidade para o consumidor final, e, quando ordenamos a base por quanto cada cliente tinha gastado, os primeiros da lista eram outras empresas, que compravam em volume. A pergunta passou a ser para quem o programa seria, e essa resposta é do dono do negócio.
Dá para fazer boa parte dessa conferência sozinho, antes de pedir orçamento a qualquer pessoa:
- Percorra o menu inteiro, item por item, e não só as telas do dia a dia.
- Abra as configurações de cada cadastro. Função que depende de um campo por item, como um prazo, um aviso ou uma publicação, costuma vir zerada.
- Procure módulos que pedem aceite de termo para ativar. Eles ficam parados até alguém aceitar.
- Pergunte ao fornecedor, por escrito, o que existe nos planos acima do seu.
- Olhe o cadastro por trás de cada pedido. Se a função depende de um dado que não tem campo nenhum para existir, ali está o que pede software. Foi o caso do quarto pedido de agosto: o filtro pedido dependia de um dado que o cadastro não tinha.
Quando integrar em volta do sistema que fica#
Integrar faz sentido quando o dado de que você precisa já está no sistema pronto e o que falta é a leitura, a tela ou o fluxo em volta dele. O sistema pronto continua sendo o dono do dado, e o que se constrói lê dele, sem que nada do que já funciona precise ser refeito.
A Fitness Academia, uma rede de cinco academias, já tinha todas as vendas na NextFit, o ERP de mercado que ela usa. O que faltava era a meta comercial, refeita à mão numa planilha com critério diferente em cada unidade. A plataforma que construímos lê a NextFit a cada cinco minutos e nunca aceita venda digitada à mão, então o número da meta passou a sair do mesmo lugar que a venda. A NextFit não perdeu nenhuma função, e a equipe continuou vendendo pelo sistema que já conhecia.
Na própria Epicora a lógica é a mesma. O Controlle segue como o nosso sistema financeiro, e o painel dos sócios lê dele lançamentos e saldos.
Duas coisas pesam antes de fechar o escopo: o que o fornecedor deixa sair, seja API, exportação ou nada, e com que frequência cada dado precisa estar atualizado. O que o sistema do outro lado decide por você está em integrar com o ERP que a operação já usa. E, se ao lado do sistema pronto sobrevive uma planilha que só reorganiza o dado dele, ela é o melhor mapa do que falta ler, como mostramos em planilha, ERP de mercado ou sistema sob medida.
Quando construir um módulo ao lado do sistema pronto#
Um módulo ao lado faz sentido quando falta um processo inteiro que o sistema pronto não cobre, mas que depende de dado que já vive nele. O sistema pronto continua fazendo o que faz bem, e o módulo novo nasce lendo dele.
A Ideal Veículos, uma rede de 11 lojas, controla o estoque no Altimus. O financiamento de cada venda, que envolve escolher entre dezenas de financeiras quem aprova aquele cliente naquele veículo, vivia em planilhas de Excel, e nenhum software de mercado dava conta do processo do jeito que a Ideal trabalha. A decisão foi construir só o que faltava.
A plataforma de financiamento é sob medida e tem cadastradas as regras de cada uma das 19 financeiras com que a rede trabalha. O estoque continua no Altimus, e mais de 3.000 veículos chegam sincronizados de lá. Quem monta um financiamento digita a placa ou o chassi, e o resto dos dados do veículo chega preenchido, sem ninguém copiar de um sistema para o outro. O detalhe está no case da Ideal.
O módulo ao lado depende do que o sistema pronto entrega. O Altimus não oferece API, e a integração foi feita sobre uma exportação do estoque, por isso ela ficou no estoque e não chegou à base de clientes, que também estava nos planos. E cada dado tem um dono só: o veículo é do sistema de estoque e chega por leitura, e o financiamento é da plataforma nova.
Quando o sistema próprio é a resposta, mesmo com centenas de opções prontas#
O sistema próprio se paga quando o processo é o que o seu cliente compra de você, ou quando o conhecimento que decide o serviço é da sua empresa e não cabe num produto feito para o mercado inteiro. Nesses casos, configurar e integrar não alcançam, porque o que falta é o centro da operação.
Uma consultora que quer vender o próprio método como produto nos disse, numa reunião de descoberta, que existem "300 mil plataformas de recrutamento e seleção, mas essas perguntas são no formato da minha metodologia". A pergunta óbvia, por que não usar uma das prontas, ela respondeu na mesma frase. O cliente dela compra o método, e uma plataforma pronta foi desenhada para servir qualquer consultoria. No produto que estamos modelando com ela, o centro é exatamente a parte que nenhuma das prontas tem.
Na Beckers, que faz a assistência técnica de ventiladores industriais para frigoríficos e cooperativas, o laudo vivia num documento em Word, e o preço de cada reparo estava na experiência de quem montava o orçamento. Construímos um catálogo de diagnóstico que a própria Beckers mantém, com os defeitos possíveis de cada parte do equipamento e o preço de cada nível de reparo, e um aplicativo em que o técnico preenche o laudo na bancada. Esse catálogo é o conhecimento da engenharia da casa, que nenhum sistema de mercado traria pronto. O sistema está no ar desde abril de 2025 e já emitiu 428 relatórios.
Os sinais de que a resposta é construir o próprio são três:
- O processo é o motivo pelo qual o cliente escolhe a sua empresa, e um produto pronto segue o jeito médio do setor.
- A regra que decide o serviço é conhecimento da casa e precisa ser mantida por quem entende do assunto.
- O dado de que a operação depende não tem onde existir no sistema pronto, e ele está no centro do trabalho.
Mesmo assim, o sistema próprio pode deixar com o pronto o que é igual para todo mundo, como nota fiscal, folha e contabilidade.
Por que trocar o sistema pronto quase nunca é a primeira resposta#
Trocar obriga o sistema novo a refazer tudo o que o pronto já faz bem antes de entregar a primeira melhoria. E a operação que não configurou o sistema atual tende a deixar o novo desligado do mesmo jeito. Por isso, quase sempre, a primeira resposta é ligar o que existe e construir só o que falta.
Quando o cliente diz que o sistema atual atende muito bem, essa frase vira a régua do projeto. Numa auditoria que fizemos em agosto de 2026, o menu do sistema pronto tinha mais de trinta itens, e era contra todos eles que um sistema próprio seria comparado no primeiro dia de uso. Trocar significa migrar cadastros e histórico, treinar a equipe de novo e reconstruir funções que ninguém listou porque funcionam, e a melhoria que motivou a troca só chega depois de tudo isso.
O segundo motivo é menos óbvio. Aquele sistema estava em uso havia cinco meses com 119 dos 120 serviços fora da página pública de agendamento. Um sistema novo entregue à mesma operação chegaria desligado do mesmo jeito, e por isso, quando um projeto desses segue, a configuração e a adoção precisam entrar no escopo como entrega, com responsável e prazo.
A troca passa a fazer sentido quando o dado fica preso no fornecedor e o processo depende dele, quando ninguém consegue mudar o sistema para acompanhar a operação, ou quando a equipe já trabalha por fora dele, em planilha e mensagem.
E sistema próprio não quer dizer sistema do zero. Nos projetos em que a operação já tinha um sistema pronto, inclusive a nossa, ele ficou no lugar: a NextFit, o Altimus e o Controlle seguem onde estavam, e o que construímos lê deles.
Perguntas frequentes#
Vale a pena trocar um sistema pronto que atende bem por um sistema próprio?#
Quase nunca como primeira resposta. Se o sistema atende bem na maior parte e falta uma lista curta de coisas, cada item costuma se resolver configurando o que já existe ou construindo uma peça pequena ao lado. A troca entra na conversa quando o dado fica preso no fornecedor, quando o sistema não deixa a operação mudar ou quando a equipe já trabalha por fora dele.
Como sei se a função que falta já existe no sistema que eu uso?#
Percorrendo o sistema por dentro, com quem opera do lado: o menu inteiro, as configurações de cada cadastro, os módulos que pedem aceite de termo e o que existe nos planos acima do seu. Função que depende de um campo por item, como um prazo ou uma publicação, costuma estar lá e zerada. Se ela depende de um dado que não tem campo nenhum no cadastro, aí está o que pede software.
Um sistema próprio precisa substituir o sistema pronto?#
Não. Sistema próprio não quer dizer sistema do zero. Nos nossos projetos em que o cliente já tinha um sistema pronto, ele ficou no lugar: a NextFit continua com as vendas da rede de academias, o Altimus continua com o estoque da revenda, e o que construímos lê deles e cobre só o que faltava.
E se o fornecedor do sistema pronto não deixar o dado sair?#
Ainda dá para integrar, com menos alcance. Muitos sistemas sem API oferecem alguma exportação, como um arquivo ou um endereço que devolve a base inteira, e isso basta para dado que muda devagar, como um estoque. O que não vem pela exportação vira limite do que se constrói em volta. Se o processo inteiro depende de um dado que o fornecedor não libera, a troca passa a fazer sentido.
Por que ter um sistema próprio se existem tantas plataformas prontas?#
Porque a plataforma pronta é feita para servir qualquer empresa do setor, e às vezes o que o seu cliente compra é o jeito como a sua empresa faz. Uma consultora que quer vender o próprio método como produto nos disse que existem 300 mil plataformas de recrutamento e seleção, mas que as perguntas dela seguem o formato da metodologia dela. Quando o processo é o produto, o sistema próprio se paga.
Fontes#
- Pendo, The 2019 Feature Adoption Report, sobre a parcela de funcionalidades raramente ou nunca usadas, numa amostra de 615 contas: https://www.pendo.io/resources/the-2019-feature-adoption-report/
Próximo passo#
Antes de pedir orçamento de um sistema novo, escreva a lista do que falta no sistema que você já paga e passe cada item pelas três perguntas: está desligado, falta só a leitura, ou não tem lugar no sistema? Se a resposta for integrar ou construir uma peça ao lado, é o trabalho que fazemos em integrações e APIs, como na plataforma de metas da Fitness Academia. Se o que falta é o centro da operação, é o de sistemas sob medida.