O sistema que a sua regra exige.
Não o que o catálogo tem.
Plataformas web, produtos multi-tenant, portais, dashboards e sistemas internos. Arquitetura documentada, banco e APIs versionados, testes automatizados e propriedade intelectual definida por escrito antes do primeiro commit.
Sistema de prateleira cobre 70% da operação e obriga a empresa a torcer os outros 30% para caber. O custo não aparece na licença — aparece nas planilhas paralelas, nas exceções que só uma pessoa sabe tratar e no relatório que ninguém confia porque foi montado à mão.
Faz sentido quando
- A regra de negócio é o diferencial competitivo, e sistema genérico a nivela por baixo
- Existem planilhas paralelas sustentando o que o sistema oficial não faz
- Multi-tenant com isolamento real entre clientes é requisito, não desejo
- O produto vai ser vendido, então precisa de arquitetura que escale sem reescrita
Não faz sentido quando
- O processo ainda não está estável e muda toda semana
- Existe produto de mercado que atende 95% — nesse caso integramos, não construímos
- O orçamento não cobre sustentação depois do go-live
Cada projeto pode incluir, conforme o contrato:
- Modelagem de domínio e decisão de stack documentada
- Banco versionado com migrations idempotentes
- Contrato de API versionado e documentado
- Ambientes de desenvolvimento, homologação e produção
- CI/CD com testes automatizados no caminho
- Registro de decisão arquitetural (ADR)
- Observabilidade e plano de continuidade
- Código no repositório do cliente, com acesso definido por escrito
Diagnóstico
Mapeamos o processo real, não o documentado. Sai daqui a lista de exceções que ninguém tinha escrito.
Arquitetura
Decisão de stack justificada, modelo de domínio e contrato de API antes de qualquer tela.
Critérios de aceite
O que significa pronto, escrito e assinado antes de o código começar.
Construção
Entregas incrementais em homologação, com teste automatizado desde o primeiro dia.
Go-live e sustentação
Migração, treinamento e o contrato de evolução já definido.
| Produto de prateleira | Low-code | ALL MAX | |
|---|---|---|---|
| Adere à regra real | Parcial | Parcial | Total |
| Propriedade do código | Nenhuma | Presa à plataforma | Do cliente |
| Custo de saída | Migração inteira | Reescrita | Repositório é seu |
| Escala sem reescrita | Até o teto do produto | Trava cedo | Arquitetada para isso |
| Prazo inicial | Curto | Muito curto | Médio |
Segurança e privacidade entram no desenho, não como correção depois:
- Autorização antes da lógica de negócio, em toda rota
- Validação de toda entrada externa na fronteira
- Isolamento por tenant no banco, com RLS quando o banco suporta
- Segredos em cofre, nunca em código
- Backup com restauração testada, não só configurada
Projeção modelada · não é medição
Operação de médio porte com 5 a 10 mil clientes ativos, substituindo três planilhas críticas e um sistema legado sem suporte.
Números projetados a partir do perfil descrito acima, para dar ordem de grandeza. Não são resultado medido em cliente. O diagnóstico substitui esta projeção pelos seus números.
De quem é o código?
Do cliente. A propriedade intelectual, o licenciamento e o acesso ao repositório são definidos por escrito antes do primeiro commit — não no fim do projeto, quando a negociação fica desigual.
E se o projeto atrasar?
O contrato define critérios de aceite e cronograma por entrega, não só data final. Atraso é detectado na primeira entrega que escorrega, não no mês do go-live.
Vocês usam IA para gerar o código?
Sim, como acelerador — não como substituto de revisão. Todo código passa por revisão humana e por teste automatizado antes de ir para homologação.
Comece pelo diagnóstico, não pela proposta.
Mapeamos o processo real e as exceções antes de estimar qualquer coisa. Se a resposta for que um produto de mercado resolve, dizemos isso.
Agendar diagnóstico