Quando criar software personalizado: checklist de viabilidade
Identifique se o problema pede software próprio, integração ou ajuste de processo com um checklist de aderência, impacto e capacidade de manutenção.
Criar software personalizado é assumir responsabilidade por um produto: descoberta, desenvolvimento, implantação, operação e evolução. A decisão deve começar pelo valor do processo, não pela vontade de substituir planilhas ou usar uma stack moderna.
Este checklist complementa a comparação entre software pronto e sob medida. Aqui, o objetivo é saber se existe um problema suficientemente definido para avançar.
Sinais favoráveis
O fluxo é importante e específico
A forma de vender, entregar ou operar tem regras que um produto genérico não representa sem controles paralelos. Essa especificidade precisa gerar resultado ou reduzir risco; ser diferente por hábito não basta.
A fragmentação tem impacto observável
Copiar dados entre sistemas, reconstruir histórico e conferir versões consome horas, provoca erros ou atrasa uma decisão. Registre frequência e consequência antes de transformar incômodo em requisito.
As integrações são parte central do trabalho
Se o processo depende de CRM, ERP, pagamentos, documentos ou comunicação, o sistema precisa tratar indisponibilidade, duplicidade e reconciliação. Uma integração bem desenhada pode resolver o problema sem uma plataforma nova.
Existem usuários responsáveis pela descoberta
Um fornecedor não deve inventar as regras do negócio. Pessoas que executam e decidem precisam validar cenários, exceções e critérios de aceite durante o projeto.
A empresa aceita manter e evoluir
Dependências mudam, integrações mudam e a operação aprende. Reserve capacidade para correções, segurança, infraestrutura e evolução depois do lançamento.
Sinais para não desenvolver ainda
- o processo muda toda semana e não há responsável por defini-lo;
- ninguém consegue explicar onde começa, termina e quais exceções importam;
- um produto existente atende bem depois de configuração e treinamento;
- o único argumento é eliminar uma mensalidade;
- não há disponibilidade de usuários para validar entregas;
- o projeto depende de uma integração cuja viabilidade ainda não foi confirmada.
Nesses casos, protótipo, mapeamento de processo ou prova de integração reduz risco com custo menor.
O recorte mínimo não é uma lista curta de telas
Um bom primeiro recorte atravessa um fluxo do início ao fim e produz aprendizado verificável. Por exemplo:
receber uma solicitação, validar os dados, atribuir um responsável, acompanhar estados e registrar a conclusão.
Esse recorte pode exigir autenticação, permissões e auditoria, mesmo sem dezenas de módulos. “MVP” não remove controles necessários ao risco do processo.
Checklist para a conversa inicial
- Problema: o que acontece hoje e qual consequência precisa mudar?
- Usuários: quem executa, aprova, administra e consulta?
- Volume: quantos registros e eventos entram por período?
- Regras: quais validações e exceções são conhecidas?
- Dados: onde estão, quem é responsável e o que precisa migrar?
- Integrações: quais serviços têm API, webhook ou outra forma de acesso?
- Criticidade: quanto tempo o processo pode ficar indisponível?
- Aceite: como saberemos que o primeiro recorte funciona?
O gerador de escopo ajuda a registrar essas respostas. Para problemas de retrabalho, a página sobre eficiência operacional oferece perguntas adicionais.
Conclusão
Software personalizado é viável quando há um processo relevante, uma lacuna real nas alternativas e capacidade de participar da construção e da manutenção. Se essas condições ainda não existem, o melhor trabalho de engenharia pode ser reduzir a incerteza antes de escrever código.