Já teve um daqueles projetos assustadores em que você é pedido para construir um CRM do zero, e você pensa, "Bem, isso é impossível"? Tive esse momento dois anos atrás com um cliente que precisava do CRM pronto em apenas 14 semanas. Não é seu cronograma típico. Mas aqui está o ponto: usando nosso playbook de 5 fases, não foi apenas possível, mas surpreendentemente tranquilo. Stack Overflow e Postman eram meus companheiros diários. E sim, aprendi mais de uma lição pelo caminho.
Fase 1: Descoberta e Definição de Escopo (Semanas 1-2)
A maioria dos projetos de CRM falha antes de uma única linha de código ser escrita. Falo sério. A falha acontece em uma sala de conferência, geralmente ao redor de um quadro branco, quando todos concordam com requisitos vagos e ninguém faz as perguntas incômodas.
Com esse projeto em particular (uma empresa de logística de médio porte em Birmingham, cerca de 80 funcionários), passei as primeiras duas semanas fazendo quase nada além de ouvir. Workshops, chamadas Zoom gravadas e um documento Notion compartilhado onde as partes interessadas podiam descarregar todos os fluxos de trabalho que queriam que o CRM tratasse. O documento cresceu para 47 páginas. Muito disso era contraditório. Isso é na verdade bom; contradições em um documento de descoberta são gratuitas; contradições descobertas na semana 11 custam um sprint e um relacionamento com cliente.
O Que Você Está Realmente Mapeando
O objetivo na descoberta não é capturar cada funcionalidade. É mapear os relacionamentos de dados e os papéis de usuário que moldarão cada decisão arquitetônica downstream. Uso Whimsical para diagramas de fluxo nessa fase. Rápido, compartilhável, e clientes podem comentar sem precisar de uma conta.data relationships and the user roles that will shape every architectural decision downstream. I use Whimsical for flow diagrams at this stage. Quick, shareable, and clients can comment without needing an account.
Até o final da semana 2, você precisa ter quatro entregas travadas:
- Uma lista de funcionalidades priorizada, dividida entre MVP e buckets pós-lançamento
- Um esboço de relacionamento de entidades (não um schema completo ainda, apenas os substantivos: contatos, deals, pipelines, tarefas)
- Definições de papéis de usuário com níveis de permissão escritos em inglês simples
- Um timeline aprovado com marcos nomeados, não fases vagas
Esse último é inegociável. "Phase 2 complete" não significa nada. "Contact import e role-based access live em staging até o dia 28" significa algo.
---
Phase 2: Architecture and Tech Stack Decisions (Week 3)
Uma semana. É tudo que dou a essa fase, porque já vi times sumirem em debates de arquitetura por um mês e não entregar nada.
Para este projeto, o stack era: Node.js com Express no backend, PostgreSQL para o banco de dados, React no front end, e tudo deployado em Kubernetes gerenciado no DigitalOcean. Usamos Prisma como ORM porque o schema ia evoluir rápido e o workflow de migrations do Prisma é genuinamente bom para isso.Node.js with Express on the backend, PostgreSQL for the database, React on the front end, and the whole thing deployed on DigitalOcean managed Kubernetes. We used Prisma as the ORM because the schema was going to evolve quickly and Prisma's migration workflow is genuinely good for that.
Honestamente, o stack importa menos do que as pessoas pensam. O que importa mais é:
- Todo desenvolvedor neste projeto vai conhecer este stack sem uma curva de aprendizado acentuada?
- A arquitetura suporta o modelo de permissões que você mapeou na Fase 1?
- Você consegue adicionar um novo tipo de entidade (digamos, "supplier") na semana 10 sem reescrever a camada de autenticação?
Esse terceiro ponto é onde já fui queimado antes. Em 2021, Seahawk tinha um projeto SaaS onde a gente encaixou multi-tenancy na semana 9. Levou quatro dias para adequar o que deveria ter sido uma decisão do dia um. Nunca mais.
Para autenticação, uso Auth0 como padrão a menos que haja um motivo convincente para não usar. Ele cuida dos edge cases (password resets, MFA, social login) que devoram desenvolvedores junior.Auth0 unless there's a compelling reason not to. It handles the edge cases (password resets, MFA, social login) that eat junior developers alive.
---
Fase 3: Core Build Sprint (Semanas 4-9)
Seis semanas. Este é o coração do motor. E se seu escopo foi sólido, esta fase é na verdade a parte mais direta de todo o projeto.
Dividi isso em dois mini-sprints de três semanas com uma revisão interna rigorosa no ponto intermediário.
Sprint A: Camada de Dados e API (Semanas 4-6)
Nada toca o front end até o contrato da API ser acordado. Sem exceções. Documento cada endpoint no Postman antes de escrever um controller, o que parece tedioso mas economiza cerca de duas semanas de conversas "espera, o que esse endpoint retorna?" depois.Postman before writing a controller, which sounds tedious but saves about two weeks of "wait, what does this endpoint return?" conversations later.
O schema do banco de dados recebe sua primeira passagem real aqui. Para CRMs, as tabelas que sempre são subestimadas são a tabela de log de atividades e a tabela de campos personalizados. Todo cliente quer campos personalizados. Construir adequadamente uma tabela custom_field_definitions flexível desde o primeiro dia é cerca de quatro horas de trabalho. Improvisar isso na semana 11 é um pesadelo.custom_field_definitions table properly from day one is about four hours of work. Improvising it in week 11 is a nightmare.
Sprint B: Front End e Workflows (Semanas 7-9)
React com TanStack Query para gerenciamento de estado do servidor. Tentei fazer com useEffect simples e estado local em um projeto menor em 2022. Nunca mais faço isso comigo mesmo, TanStack Query gerencia caching, refetching em background e atualizações otimistas de um jeito que faz interfaces CRM parecerem rápidas sem esforço excessivo.TanStack Query for server state management. I tried rolling with plain useEffect and local state on a smaller project in 2022. Never doing that to myself again, TanStack Query handles caching, background refetching, and optimistic updates in a way that makes CRM interfaces feel snappy without heroics.
Para a camada de componentes da UI, usamos shadcn/ui neste projeto. Não é uma biblioteca de componentes no sentido tradicional; você é o dono do código, o que significa que você pode realmente customizá-la sem lutar contra a biblioteca. Para um CRM com uma visualização de pipeline, uma tabela de contatos e um quadro de tarefas, essa flexibilidade importa.shadcn/ui on this project. It's not a component library in the traditional sense; you own the code, which means you can actually customise it without fighting the library. For a CRM with a pipeline view, a contacts table, and a task board, that flexibility matters.
Uma coisa que consistentemente passa despercebida neste sprint: estados vazios. Um CRM sem dados parece quebrado se você não tiver projetado telas com estado zero. Construa-as cedo. Clientes fazem demos para stakeholders com bancos de dados vazios e primeiras impressões ficam marcadas.empty states. A CRM with no data looks broken if you haven't designed for zero-state screens. Build them early. Clients demo to stakeholders with empty databases and first impressions stick.
---
Fase 4: Integrações e Migração de Dados (Semanas 10-11)
É aqui que a maioria das agências cota por baixo e planeja mal. Eu vi acontecer toda vez.
O cliente de logística de Birmingham precisava de integrações com sua configuração Xero existente e uma instância Salesforce antiga da qual estava migrando. Duas semanas parecia apertado. Foi, mas conseguimos porque tínhamos criado os pontos de integração na Fase 3.Xero accounting setup and an older Salesforce instance they were migrating away from. Two weeks sounds tight. It was, but we made it because we'd stubbed the integration points back in Phase 3.
Especificamente para a migração do Salesforce, usamos a Bulk API 2.0 deles para extrair os dados, depois rodamos através de um script Node que mapeava a estrutura de campos deles para a nossa. O script levou um dia para escrever e três dias para iterar porque dados do Salesforce quase nunca são tão limpos quanto os clientes acreditam que são. Reserve orçamento para limpeza de dados. Sempre.Bulk API 2.0 to extract the data, then ran it through a Node script that mapped their field structure to ours. The script took a day to write and three days to iterate on because Salesforce data is almost never as clean as clients believe it is. Budget for data cleaning. Always.
Algumas coisas que verifico antes de chamar uma integração de "pronta":
- Tratamento de falhas: o que acontece quando a API de terceiros cai?
- Idempotência de webhooks: você consegue processar o mesmo evento duas vezes com segurança sem duplicar registros?
- Rate limits: você está dentro deles sob carga realista?
Os documentos de desenvolvedor do Xero são na verdade decentes, pelo que vale. O fluxo OAuth 2.0 é bem documentado e o ambiente sandbox deles funciona de forma confiável.Xero developer docs are actually decent, for what it's worth. The OAuth 2.0 flow is well documented and their sandbox environment works reliably.
---
Fase 5: QA, Hardening e Handover (Semanas 12-14)
Três semanas para QA parecem generosas até você estar dentro delas.
A semana 12 é teste estruturado. Dou ao cliente um board do ClickUp com cada caso de teste escrito como uma tarefa, eles testam, marcam, anexam um Loom se algo quebra. Isso coloca usuários reais clicando em fluxos reais, o que sempre descobre coisas que um teste executado por desenvolvedor deixa passar. Alguém vai tentar colar 4.000 caracteres em um campo de "notas". Alguém vai importar um CSV com aspas inteligentes nele. Você quer encontrar isso agora.ClickUp board with every test case written as a task, they test, they mark it, they attach a Loom if something breaks. This gets real users clicking real flows, which always uncovers things that a developer-run test misses. Someone will try to paste 4,000 characters into a "notes" field. Someone will import a CSV with smart quotes in it. You want to find this now.
A semana 13 é o sprint de correções. Sem recursos novos. Apenas correções de bugs e trabalho de performance. Executo Lighthouse contra cada página-chave. Também executo testes de carga k6 contra a API, não porque o cliente pediu, mas porque encontrar uma query lenta sob 50 usuários simultâneos na semana 13 é melhor do que encontrá-la depois do go-live.Lighthouse against every key page. I also run k6 load tests against the API, not because the client asked for it, but because finding a slow query under 50 concurrent users in week 13 beats finding it after go-live.
A semana 14 é handover e preparação para go-live.
A documentação de handover que produzo cobre:
- Visão geral da infraestrutura (o que está rodando onde, como fazer scale)
- Procedimento de backup e restore do banco de dados, testado e verificado
- Como adicionar um novo papel de usuário sem tocar no código
- Limitações conhecidas e os itens de backlog que adiamos
Esse último é importante. Seja honesto sobre o que não entrou. Clientes respeitam isso, e prepara a próxima fase de trabalho de forma limpa em vez de deixar dívida não dita pendurada sobre o relacionamento.
Uma Última Coisa sobre o Go-Live
Escalone isso. Fizemos um soft-launch para 10 usuários no dia 92, monitoramos os logs por 48 horas usando Datadog, depois abri para o time completo de 80 pessoas. Aquela janela de 48 horas pegou dois edge cases nas transições de estágio do pipeline que não tinham aparecido nos testes. Nada catastrófico, mas o tipo de coisa que geraria 15 tickets de suporte no dia um se tivéssemos ido com tudo aberto.Datadog, then opened it to the full 80-person team. That 48-hour window caught two edge cases in the pipeline stage transitions that hadn't shown up in testing. Nothing catastrophic, but the kind of thing that would have generated 15 support tickets on day one if we'd gone full-steam.
Go-live não é o fim. É apenas quando os dados reais de comportamento do usuário começam a chegar.
---
FAQ
Quanto custa um CRM customizado como este, tipicamente?
Honestamente, varia enormemente, mas um projeto de 14 semanas escopo neste nível com um pequeno time (dois desenvolvedores back-end, um desenvolvedor front-end, um project lead) geralmente custa entre £60.000 e £120.000 dependendo da complexidade das integrações e migração de dados. Se você está vendo orçamentos abaixo de £30.000 para uma construção totalmente customizada, questione bastante o que está sendo realmente construído versus configurado a partir de um template existente.
Você consegue construir um CRM customizado no WordPress?
Você consegue, mas eu não faria para nada acima de uns 500 registros ou 20 usuários simultâneos. A camada de dados do WordPress não foi feita para cargas de trabalho de CRM relacional. Na Seahawk construímos camadas de gerenciamento de contatos em cima do WordPress para clientes menores, mas para algo sério, um back-end apropriado com um banco de dados relacional é a escolha certa.
Qual é o maior erro que times cometem em builds de CRM?
Subespecificar o modelo de permissões. Todos focam em funcionalidades e esquecem que um CRM com 80 usuários precisa de uma resposta nuançada para "quem pode ver qual negociação?" antes de escrever uma única rota de API. Adaptar controle de acesso baseado em papéis na semana 10 é doloroso de um jeito difícil de descrever até você passar por isso uma vez.
Você sempre usa exatamente esse stack de tecnologias?
Não. O stack que descrevi funcionou para a equipe e as restrições deste projeto. Já entreguei CRMs em Laravel e Vue, em Django e React, e uma vez em um setup full-stack Next.js que eu era cético, mas na verdade funcionou muito bem. Os princípios de arquitetura permanecem os mesmos. As ferramentas são flexíveis.
No fim, o projeto customizado de CRM foi mais que um desafio, foi uma revelação. Aquela janela apertada de 14 semanas? Nos forçou a inovar, adaptar e entregar. Acontece que restrições podem ser um catalisador para a criatividade. Quem diria que prazos poderiam nos ensinar tanto sobre nosso ofício? São projetos como estes que me lembram por que cofundei a Seahawk Media em primeiro lugar.