No Dia 7 do projeto Mini CRM Lead Tracker, avancei na estrutura corporativa do sistema: implementei o CRUD completo de Empresas (Companies), consolidando o modelo multi-tenant estrito que serve de base para todo o backend.
Essa etapa marca a transição definitiva do projeto para um CRM de padrão enterprise, com segurança em camadas, isolamento de dados e políticas de acesso refinadas. Cada decisão foi tomada com base nas práticas de sistemas como Salesforce, HubSpot e Zoho.
CompanyController)CompanyService) com filtragem por company_idStoreCompanyRequest e UpdateCompanyRequestCompanyResourceCompanyPolicy garantindo que apenas administradores possam editarcompany.valid protegendo todas as rotasO projeto segue uma abordagem Defense in Depth (defesa em profundidade):
1️⃣ Middleware - garante que o usuário está ativo e possui empresa
2️⃣ Policy - autoriza apenas quem pertence à mesma empresa
3️⃣ Service - executa queries sempre filtradas por company_idEsse modelo elimina riscos de vazamento entre locatários e garante total rastreabilidade para auditorias e compliance (LGPD e GDPR).
O campo company_id é NOT NULL — decisão intencional. Permitir null violaria o princípio de multi-tenancy e aumentaria a superfície de ataque de segurança. Cada usuário precisa estar vinculado a uma empresa.
O Swagger foi atualizado com autenticação Bearer Token, exemplos de payload e responses padronizados. Testes cobrem fluxos de criação, atualização, listagem, autorização e cenários de erro.
“Nenhum sistema é seguro se o isolamento de dados for opcional. Multi-tenancy é sobre responsabilidade, não apenas sobre estrutura.”
O Mini CRM Lead Tracker agora possui uma fundação corporativa sólida — cada dado pertence a uma empresa e segue o ciclo de segurança completo.
Essa estrutura é a base para o controle de usuários e leads, garantindo rastreabilidade e escalabilidade com segurança.
Diário de Bordo – Dia 7 concluído!
Próximo passo: CRUD de Usuários dentro da Empresa, mantendo o isolamento multi-tenant e adicionando controle de papéis (roles) corporativos.
No Dia 6 do projeto Mini CRM Lead Tracker, enfrentei um dos marcos mais críticos de qualquer backend moderno: a autenticação segura. Mas não parei por aí. Estruturei também a base de multitenancy e implementei uma camada de controle de acesso por perfil baseada em papéis (roles), tudo com Laravel 10, usando Sanctum e documentação via Swagger.
Laravel Sanctum com retorno de accessTokenEnsureCompanyIsValid para garantir escopo por empresarole:{slug} para validação de perfil (admin, operador, master)roles, companies e users para testes realistasREADME.md com payloads reaisis_active via migration incrementalCHANGELOG.md para rastreabilidade técnicaEscolhi Sanctum porque ele entrega exatamente o que uma API moderna precisa: geração de tokens, suporte a autenticação stateless e integração perfeita com o Laravel. Em vez de reinventar a roda, deixo o core da autenticação simples, seguro e escalável.
Cada usuário está vinculado a uma empresa (company_id). O middleware EnsureCompanyIsValid garante que o usuário esteja ativo e operando apenas no escopo da sua organização.
if (! $user->is_active || ! $user->company_id) {
return response()->json(['mensagem' => 'Usuário não autorizado.'], 403);
}Implementei uma estrutura de perfis com a tabela roles (admin, operador, master) e middleware genérico role:{slug} que protege rotas com clareza e desacoplamento. Exemplo:
Route::middleware(['auth:sanctum', 'role:admin'])->group(function () {
Route::get('/admin/painel', ...);
});É limpo, reutilizável e pronto para escalar com policies específicas quando necessário.
Seeders inserem perfis, empresas e usuários ativos de teste automaticamente. Isso acelera o teste local e garante consistência no onboarding de novos devs.
Como o campo is_active não existia no início da modelagem, criei uma migration incremental (ao invés de editar a original), garantindo versionamento limpo e histórico rastreável. Essa decisão é vital para manter a confiabilidade do projeto no longo prazo.
Documentei o endpoint /api/v1/login com payloads reais e habilitei autenticação com Bearer Token diretamente na interface Swagger. Isso reduz tempo de teste e facilita QA e onboarding.
Atualizei o README.md com instruções claras para rodar o projeto, seeder de dados reais, autenticação e Swagger. E iniciei o CHANGELOG.md para registrar todas as alterações de forma técnica e auditável.
O Mini CRM Lead Tracker agora tem um sistema de autenticação robusto, com segregação por empresa, controle por perfil e documentação completa. A fundação está sólida para que a escalabilidade venha com segurança e rastreabilidade.
Próximo passo: CRUD de Empresas com vinculação ao usuário e políticas de acesso mais refinadas. O backend está tomando forma — limpo, rastreável e escalável.
Hoje, no #Dia5 do Diário de Bordo, o projeto começou a ganhar uma API robusta — mas com responsabilidade. Nada de controller gigante ou regra de negócio no model. Aqui a gente aplica MVC de verdade.
FormRequest para validações desacopladasResource para padronizar as respostas da APIJobs + Events para ações desacopladas e assíncronasmiddleware e prefix (ex: /api/v1/leads)Muita gente acha que usa MVC. Mas na prática, mistura tudo no controller ou entope o model de regra.
Aqui, aplicamos:
Resource (output JSON padronizado)👉 Repositório completo no GitHub
Usar Laravel é fácil. Arquitetar bem usando Laravel é outra história.
Nos vemos no próximo capítulo do Diário de Bordo 🚀
Chegamos a uma das etapas mais cruciais da construção do nosso Mini CRM Lead Tracker: transformar o Diagrama ER em código real.
Esse não é um simples “create table”. É a fundação que define se o projeto vai ser escalável, saudável e preparado pro futuro — ou se vai virar uma bomba-relógio nas mãos de quem for manter.
Antes de qualquer linha de código, cada tabela foi pensada para representar entidades reais do negócio:
Se o banco não faz sentido, nenhum código faz.
Criamos cada entidade com migrations profissionais:
php artisan make:model Company -m
php artisan make:model Role -m
php artisan make:model User --migration
php artisan make:model Lead -m
php artisan make:model KanbanStage -m
php artisan make:model ActivityLog -m
Cada migration vem com:
✔️ Relacionamentos bem definidos (FK e cascade).
✔️ Comentários explicando o motivo de cada tabela.
✔️ Organização que permite escalar e crescer sem virar gambiarra.
Esse é o tipo de detalhe que separa projetos amadores de projetos que podem virar produtos reais.
Se você acha que documentação é tarefa do fim… tá errado. Documentamos nossa API desde agora.
O arquivo /docs/swagger.yaml já descreve os primeiros endpoints de leads — e vai crescer junto com o sistema.
➡️ O Swagger não é só documentação. É um contrato entre backend, frontend e futuro.
✅ Banco de dados modelado e com integridade.
✅ Arquitetura de dados pronta pra escalar.
✅ Documentação Swagger iniciada.
✅ GitHub organizado, com README.md profissional e LICENSE personalizada.
Esse não é mais um projeto aleatório no GitHub. É um CRM real, construído como sistemas reais são feitos.
“Cada migration aqui não é só um banco de dados. É a tradução da regra de negócio, do entendimento do produto e do respeito por quem vai usar e por quem vai manter esse código no futuro.”
O Diário de Bordo segue. No próximo capítulo, partimos para os Controllers e primeiros endpoints REST. Bora construir junto!
No desenvolvimento de qualquer sistema sério, a modelagem de dados é um dos pilares. No Mini CRM Lead Tracker, essa etapa é fundamental para garantir escalabilidade, segurança e clareza nas relações entre usuários, empresas e leads.
O Diagrama Entidade-Relacionamento (ER) é a espinha dorsal do projeto. Ele ajuda a visualizar:
O sistema ainda está em fase MVP, mas já conta com uma modelagem que respeita boas práticas e antecipa crescimento:
A partir da modelagem, vamos iniciar a construção real das migrations e modelos no Laravel, garantindo que tudo seja bem tipado, documentado e validado.
“Modelar bem não é burocracia — é visão de longo prazo.”
Se quiser acompanhar todos os capítulos do Diário de Bordo, continue com a gente aqui no blog. Estamos construindo esse CRM de forma aberta, transparente e com boas práticas.
Antes de começar o desenvolvimento, é essencial entender como o usuário vai navegar e interagir com o sistema. O User Flow garante que cada passo da jornada seja pensado para ser intuitivo e funcional.
Mapear o User Flow nos ajuda a entender o que realmente importa para o usuário. Para o Mini CRM Lead Tracker, o foco está em simplicidade, eficiência e visão gerencial de qualidade.
“Fluxo bem desenhado hoje, menos retrabalho amanhã.”
No próximo capítulo do Diário de Bordo, vamos modelar as entidades de dados com base nesse fluxo e preparar o diagrama ER inicial. Acompanhe!
Iniciamos hoje o desenvolvimento do Mini CRM Lead Tracker, um sistema pensado para profissionais e pequenas equipes que precisam de um CRM leve, prático e objetivo.
Agora vamos avançar para a definição da arquitetura inicial e modelagem de dados, que vão sustentar a evolução do projeto.
“Cada linha de código será pensada para ser limpa, escalável e bem documentada — porque o futuro agradece.”
Quer acompanhar essa jornada? Fique de olho — novos capítulos do Diário de Bordo serão publicados toda semana!