Sistema sob medida ou software pronto: como decidir sem errar

Decidir entre sistema sob medida ou software pronto começa por uma pergunta simples: esse processo é igual ao de qualquer empresa do seu setor ou é parte do que torna sua empresa diferente? Para o que é padrão, compre ou configure. Para o que diferencia, ou para a integração que nenhum produto resolve, avalie desenvolver. E antes de qualquer uma dessas opções, considere seriamente a quinta: não fazer nada agora.

Um aviso de transparência: a True Fiction faz diagnóstico e também desenvolve sistemas. Esse conflito existe, e a melhor forma de lidar com ele é deixar o critério de decisão explícito, para que você consiga aplicá-lo com ou sem a nossa ajuda. É o que este guia tenta fazer.

Sistema sob medida ou software pronto: qual é a regra prática?

A regra prática é comprar ou configurar software pronto para funções comuns a qualquer empresa e reservar o desenvolvimento sob medida para processos que geram vantagem ou integrações sem boa solução no mercado. Financeiro, emissão de notas, folha de pagamento e CRM básico raramente justificam desenvolvimento próprio.

O motivo é econômico. Um produto pronto divide o custo de evolução, segurança e conformidade fiscal com milhares de clientes; um sistema sob medida concentra esse custo em uma única empresa, a sua. Só compensa quando o encaixe no processo vale mais do que essa diferença.

Os dados do Cetic.br apontam na mesma direção. Na pesquisa TIC Empresas 2025, entre as empresas brasileiras com mais de dez pessoas ocupadas que usaram inteligência artificial, 80% adotaram soluções prontas, com pouco desenvolvimento interno. Segundo o mesmo levantamento do Cetic.br, 54% contrataram fornecedores externos para modificar ou desenvolver sistemas de IA.

Os números se referem a IA, não a software em geral, mas ilustram o comportamento predominante: comprar é o caminho majoritário, e adaptar com apoio externo é comum.

Quais são as cinco opções reais além de comprar ou desenvolver?

Quem pergunta “comprar ou desenvolver software?” costuma estar diante de cinco opções, não de duas. Tratar a decisão como binária leva a escolhas caras: desenvolver o que bastava configurar, ou comprar um produto e depois forçá-lo a fazer o que ele não faz.

1. Comprar. Assinar um software pronto e usar como ele vem, adaptando o processo da empresa ao produto. É o caminho mais rápido quando o processo é padrão.
2. Configurar. Usar um produto pronto, mas ajustar campos, etapas, permissões, automações nativas e relatórios. Muitas empresas compram um bom sistema e usam uma fração dele por falta de configuração.
3. Integrar. Manter os produtos que você já usa e conectá-los, para que um pedido no e-commerce chegue ao ERP ou um lead do site entre no CRM sem redigitação. Veja como isso funciona nos guias sobre integração entre e-commerce e ERP e como automatizar processos.
4. Desenvolver. Construir um sistema interno para empresa, ou um portal do cliente, com telas, regras e perfis desenhados para o seu fluxo.
5. Não fazer. Manter a planilha, simplificar o processo ou eliminar uma etapa. Às vezes o problema não é a ferramenta, e sim um processo que ninguém revisou.

Como os cinco caminhos se comparam em prazo, custo e dependência?

Cada caminho troca velocidade por encaixe e independência por responsabilidade. A tabela abaixo resume essas trocas de forma qualitativa, sem valores, porque prazo e investimento dependem do escopo de cada caso.

Comparativo: comprar, configurar, integrar, desenvolver ou não fazer

Comparativo: comprar, configurar, integrar, desenvolver ou não fazer

Critério	Comprar	Configurar	Integrar	Desenvolver	Não fazer
Prazo até o uso	Curto	Curto a médio	Médio	Médio a longo	Imediato
Aderência ao processo	Baixa a média	Média a alta	Depende dos sistemas conectados	Alta, se bem delimitado	A atual
Custo inicial	Baixo	Baixo a médio	Médio	Mais alto	Nenhum
Custo recorrente	Assinatura por usuário ou módulo	Assinatura e ajustes	Assinaturas e monitoramento das conexões	Hospedagem, manutenção e evolução	Custo oculto do retrabalho
Dependência	Do fornecedor do produto	Do produto e de quem configurou	Das APIs de cada produto	De quem detém código e documentação	De pessoas-chave e planilhas
Manutenção	Feita pelo fornecedor	Compartilhada	Exige acompanhamento das integrações	Sua responsabilidade, própria ou contratada	Manual

Dois pontos merecem atenção. Primeiro, “não fazer” tem custo, só que ele aparece como horas de conferência, erros e dependência de quem sabe mexer na planilha. Segundo, o custo total do desenvolvimento não termina na entrega: um sistema sob medida precisa de atualizações de segurança, correções e pequenas evoluções enquanto estiver em uso.

Como saber se a planilha ou o sistema atual chegou ao limite?

A planilha chegou ao limite quando o tempo gasto para mantê-la confiável passa a ser maior do que o tempo que ela economiza. Isso costuma acontecer de forma gradual, por isso vale fazer uma checagem honesta.

Checklist: sinais de que a planilha chegou ao limite

Use este checklist. Se três ou mais itens forem verdade, a migração de planilha para sistema merece análise:

• Mais de uma pessoa edita a mesma planilha e já houve perda ou sobrescrita de dados.
• Existem versões paralelas do mesmo arquivo circulando por e-mail ou WhatsApp.
• Aprovações acontecem em mensagens soltas, sem registro de quem aprovou e quando.
• Só uma ou duas pessoas entendem as fórmulas e as abas escondidas.
• A mesma informação é digitada em dois ou mais lugares, como planilha, ERP e CRM.
• Clientes perguntam o status de pedidos ou solicitações porque não conseguem consultar sozinhos.
• Dados pessoais de clientes ou funcionários estão em arquivos sem controle de acesso.
• O sistema atual exige contornos manuais diários para o processo funcionar.
• Relatórios mensais levam dias para fechar porque os dados precisam ser conferidos à mão.

Por que dados pessoais em planilhas são um risco?

Dados pessoais em planilhas sem controle de acesso expõem a empresa a descumprir a LGPD. A LGPD determina, no artigo 46, que “os agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados”.

O guia da ANPD para agentes de pequeno porte descreve o controle de acesso como a combinação de autenticação, autorização e auditoria. O guia também recomenda não permitir o compartilhamento de contas ou senhas entre funcionários. Uma planilha compartilhada por link dificilmente atende a isso. E a base de proteção ainda é frágil: segundo a TIC Empresas 2025, só 53% das empresas brasileiras tinham uma política de segurança digital.

Qual é o ponto de partida dos pequenos negócios brasileiros?

O ponto de partida brasileiro ajuda a calibrar expectativas. O estudo Maturidade Digital dos Pequenos Negócios, do Sebrae com a ABDI, publicado em 2024, mediu índice médio de 35 pontos (escala de 0 a 80), com dois terços dos pequenos negócios em nível médio ou baixo.

No capítulo “construir uma organização orientada a dados”, o estudo de 2024 do Sebrae registrou 1,6 em uma escala de 0 a 4 pontos.

Sair das planilhas faz parte desse amadurecimento, e o tema se conecta ao que discutimos em transformação digital na pequena empresa.

Quando o software pronto resolve?

O software pronto resolve quando o processo é regulado, padronizado ou comum ao setor, e quando sua equipe aceita ajustar a forma de trabalhar ao produto. Nesses casos, desenvolver seria pagar para reinventar algo que já existe, testado por muitos usuários.

Situações típicas em que comprar ou configurar costuma ser a melhor escolha:

• Fiscal, contábil e folha. As regras mudam por lei, e o fornecedor de um produto pronto acompanha essas mudanças por você.
• CRM e funil comercial. A maioria das empresas precisa de etapas, tarefas e histórico de contato, que bons CRMs já oferecem. O guia sobre como implementar um CRM mostra o passo a passo.
• Atendimento e agenda. Ferramentas de atendimento multicanal e agendamento cobrem a maior parte dos cenários.
• Loja virtual. Plataformas de e-commerce resolvem catálogo, pagamento e frete sem desenvolvimento próprio.
• ERP de gestão. Para estoque, compras, financeiro e faturamento, um ERP do seu porte e setor tende a ser mais seguro que um sistema próprio.

Antes de concluir que o produto “não atende”, confira se o problema é de configuração. É comum a empresa abandonar um sistema que faria o trabalho com campos personalizados, permissões ajustadas e treinamento da equipe.

Quando um sistema interno simples faz sentido?

Um sistema interno simples faz sentido quando um processo específico, frequente e importante para o negócio não cabe em nenhum produto pronto sem contornos manuais constantes. “Simples” é a palavra-chave: um processo, poucas telas, perfis de acesso claros e uma integração bem documentada.

Não confunda esse caso com o lançamento de um produto digital para o mercado. Se a ideia é vender um software para clientes externos, o caminho é validar demanda primeiro, como explica o guia sobre o que é MVP. Aqui o foco é operação interna.

Quais processos específicos justificam desenvolver?

Desenvolver vale a pena quando o jeito como sua empresa executa o processo é parte do motivo pelo qual o cliente compra de você.

Um orçamento técnico montado com regras próprias, uma rotina de inspeção com checklist específico do seu serviço ou um fluxo de aprovação com várias alçadas são exemplos.

Nesses casos, forçar o processo para dentro de um produto genérico pode apagar justamente o que diferencia a empresa. O desenvolvimento de sistema personalizado preserva a regra de negócio e a torna repetível, sem depender da memória de uma pessoa.

Integrações que nenhum produto pronto faz bem

Às vezes o sistema sob medida é uma camada fina que conecta produtos prontos, e não um substituto deles. Um portal do cliente que mostra dados do ERP, recebe documentos e dispara uma tarefa no CRM é um exemplo comum.

Nesse desenho, você mantém o ERP e o CRM, que fazem bem o que é padrão, e desenvolve apenas a parte que falta. É uma forma de reduzir escopo, prazo e manutenção, e costuma ser mais sensata do que construir um sistema completo do zero.

Como delimitar um sistema interno?

Um sistema interno bem delimitado cabe em uma página: qual processo ele cobre, quais telas existem, quem acessa o quê, com quais sistemas ele conversa e como saber que está pronto. Se não cabe, o escopo provavelmente está grande demais para uma primeira versão.

Use esta estrutura para escrever o escopo:

1. Processo. Um só, descrito do início ao fim. Exemplo: da solicitação do cliente à aprovação do orçamento.
2. Telas. Liste cada tela funcional, como cadastro, lista, detalhe, aprovação e relatório. Limitar o número de telas ajuda a controlar prazo e investimento.
3. Perfis de acesso. Quem cria, quem aprova, quem só consulta. Dois ou três perfis costumam bastar no começo.
4. Integrações. Quais sistemas trocam dados, em que direção e com que frequência. Cada integração adiciona dependência da API (interface de integração entre sistemas) de outro fornecedor.
5. Dados e migração. O que vem das planilhas atuais, quem limpa esses dados e o que fica para trás.
6. Segurança. Autenticação individual, registro de quem fez o quê, cópias de segurança e tratamento de dados pessoais conforme a LGPD.
7. Critérios de aceite. Condições verificáveis, como “um orçamento criado pelo comercial chega ao aprovador correto e o cliente recebe a notificação”.
8. Exclusões. O que não faz parte desta versão. Escrever as exclusões evita a maior parte das discussões de escopo.

Por que a experiência de uso pesa no escopo?

A experiência de uso pesa mais do que parece, porque define se a equipe vai adotar o sistema. O Nielsen Norman Group observa, em Workplace Application Usability, que aplicações de trabalho com frequência dão suporte ruim às tarefas e têm requisitos de usabilidade diferentes dos de aplicativos de consumo.

Um sistema que a equipe evita usar acaba de volta na planilha. Por isso o desenho das telas deve partir de quem usa o sistema todos os dias, tema do guia sobre o que é UX e UI design.

O que garantir em titularidade e documentação para poder trocar de fornecedor?

Antes de contratar um software sob medida, garanta em contrato que o código, os dados e as contas de infraestrutura ficam em nome da sua empresa. Sem isso, o sistema que deveria dar autonomia cria uma dependência ainda maior que a do software pronto.

Itens para exigir por escrito:

• Repositório do código em conta da sua empresa, com acesso de administrador seu.
• Hospedagem e domínio contratados em nome da empresa, com credenciais sob seu controle.
• Documentação técnica: como instalar, configurar, publicar uma nova versão e restaurar um backup.
• Documentação de uso: guia para cada perfil de acesso e treinamento da equipe.
• Exportação de dados em formato aberto, para que você consiga levar as informações para outro sistema.
• Tecnologias de mercado, com boa disponibilidade de profissionais, e não uma plataforma obscura que só o fornecedor conhece.

O teste é direto: se o fornecedor atual deixasse de atender amanhã, outro profissional conseguiria assumir o sistema em poucas semanas? Se a resposta for não, a contratação tem um risco que precisa ser tratado antes de começar. As mesmas perguntas valem para qualquer parceiro de tecnologia, como mostramos em como escolher uma agência de criação de sites.

Exemplo ilustrativo: solicitações e aprovação de orçamentos (hipotético)

O exemplo a seguir é hipotético e mostra como o critério de decisão funciona na prática, sem dados de cliente real.

Imagine uma empresa de manutenção predial com equipe comercial, técnicos de campo e um gestor que aprova orçamentos. Hoje, as solicitações chegam por e-mail e WhatsApp, e o comercial monta o orçamento em uma planilha e envia ao gestor por mensagem. Depois da aprovação, alguém digita tudo de novo no ERP para faturar.

Aplicando os cinco caminhos:

• Comprar: a empresa avalia ferramentas de orçamento prontas, mas as regras de cálculo dependem do tipo de equipamento e da visita técnica. Os produtos analisados exigiriam contornos manuais.
• Configurar: o ERP atual tem um módulo de orçamentos, porém sem fluxo de aprovação por alçada nem área para o cliente acompanhar o status.
• Integrar: conectar o WhatsApp a um formulário resolveria a entrada, mas não a aprovação nem a montagem do orçamento.
• Não fazer: possível, mas o retrabalho entre planilha e ERP continua, assim como a falta de registro de aprovações.
• Desenvolver: um sistema interno pequeno, com cerca de seis telas (solicitação, lista, montagem do orçamento, aprovação, consulta pelo cliente e relatório), dois perfis de acesso (equipe interna e cliente). Uma integração documentada com o ERP enviaria o orçamento aprovado ao faturamento.

Nesse cenário hipotético, a decisão razoável seria desenvolver um sistema delimitado, mantendo o ERP para tudo o que já faz bem.

Os critérios de aceite seriam verificáveis. Uma solicitação registrada chega ao comercial, o orçamento segue para o aprovador correto, o cliente consulta o status pelo portal e o orçamento aprovado aparece no ERP sem redigitação. Se, em vez disso, um produto pronto cobrisse quase todo o fluxo com configuração, a recomendação seria outra.

Como a True Fiction pode ajudar?

A True Fiction ajuda sua empresa a escolher entre comprar, configurar, integrar, desenvolver ou não fazer e a colocar a solução em uso, com escopo claro e critérios de aceite. Quando o diagnóstico indica que um produto pronto resolve, essa é a recomendação.

• Serviço de diagnóstico de negócio: para mapear o processo, as planilhas e os sistemas atuais e comparar as opções antes de qualquer desenvolvimento.
• Desenvolvimento de sistemas internos e portais: para desenvolver um sistema interno ou portal do cliente delimitado, com perfis de acesso e integração documentada. Código e contas ficam em nome da sua empresa, com transferência de conhecimento.
• Serviço de design de interfaces (UX/UI): para desenhar telas que a equipe e os clientes realmente usem, seja em um sistema novo, seja na configuração de um produto pronto.

Se a necessidade já está clara, o diagnóstico não é obrigatório: podemos partir direto para o escopo. O investimento é definido após uma conversa sobre objetivo, escopo e prazo, e é apresentado em reunião. Se a sua dúvida envolve também o uso de inteligência artificial nesses processos, vale ler como usar IA na empresa.

Para avaliar o seu caso, o próximo passo é agendar uma conversa. Na reunião, detalhamos prazos, escopo e investimento.