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.
O Smart Chat Form é um projeto open source criado para transformar formulários comuns em experiências interativas, semelhantes a uma conversa de chat. Desenvolvido com JavaScript puro e Bootstrap 5, ele oferece uma jornada de preenchimento fluida, envolvente e moderna — sem precisar de dependências externas.
Em vez de exibir uma longa lista de campos, o Smart Chat Form conduz o usuário passo a passo, como se fosse uma conversa. Cada pergunta aparece em sequência, com animações suaves e respostas validadas em tempo real. O resultado é um fluxo natural, intuitivo e muito mais agradável para o usuário.
Esse tipo de abordagem conversacional já é tendência em UX/UI, pois reduz o abandono de formulários e aumenta significativamente as taxas de conversão.
Cada pergunta é configurada em um array JavaScript que define o tipo de campo, a validação e a condição de exibição. Por exemplo:
const questions = [
{
id: 1,
text: "Qual o seu nome?",
type: "text",
field: "nome",
validation: "required",
},
{
id: 2,
text: "Qual o seu CPF?",
type: "cpf",
field: "cpf",
validation: "cpf"
}
];
O script se encarrega de mostrar as mensagens, validar respostas, aplicar máscaras e salvar os dados no localStorage, garantindo que nada se perca se o navegador for fechado.
O Smart Chat Form já vem integrado à API de Localidades do IBGE, permitindo autocomplete em mais de 5.500 cidades brasileiras. A busca é otimizada com cache local e suporte a digitação sem acentos.
O formulário salva automaticamente as respostas no localStorage. O usuário pode exportar suas respostas em formato TXT ou JSON, ou simplesmente retomar o preenchimento após recarregar a página.
Todo o design pode ser personalizado editando o style.css. É possível ajustar cores, fontes, tema gradiente e até o comportamento das animações para adaptar à identidade visual da sua marca.
Em todos esses contextos, o Smart Chat Form oferece uma experiência mais humana, agradável e eficiente.
O projeto está disponível publicamente no GitHub sob licença MIT.
Você pode usar, modificar ou contribuir com novas features livremente.
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.
Tem gente que acha que organizar o código é perda de tempo. Que separar responsabilidades em controller, service e job é “frescura” ou “over engineering”.
Até o sistema quebrar. O estagiário entrar. O cliente pedir algo urgente. E ninguém conseguir mexer.
Clean code não é enfeite. É seguro de vida.
Tem dev que acha que “centralizar tudo” é uma prova de competência. Quando na verdade, está sabotando o próprio time.
O código vira um refém da cabeça de quem escreveu. E se essa pessoa sai? Ninguém mais entende. A empresa trava.
Separar responsabilidades, escrever nomes claros, documentar o mínimo… tudo isso é um ato de respeito com quem vem depois. Até com o “você do futuro”.
Simples. Elegante. Sustentável.
Se você é sênior e guarda tudo na cabeça, está atrasando a equipe. Liderar é preparar o terreno para que outros consigam andar sem você.
Quer crescer na carreira? Comece escrevendo como se alguém que você ama fosse manter seu código amanhã.
👇 E você? Já sofreu com sistemas que só o “criador” entendia?
Compartilha aí nos comentários. Vamos abrir esse debate.
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 🚀
Se você acha que sua missão como dev é “escrever código”, sinto te dizer: não é.
O cliente não quer código. Não quer API. Não quer tela bonita. Nem banco de dados, nem docker, nem swagger, nem figma.
O cliente quer uma coisa muito mais simples (e muito mais difícil):
Ter um problema resolvido.
Ficar focado na tecnologia, na stack, no framework… e esquecer que software é só uma ferramenta.
Quando você começa a entender isso, sua carreira muda. Você deixa de ser apenas um executor técnico e passa a ser alguém que:
✔️ Entende o problema do negócio
✔️ Propõe soluções melhores
✔️ Participa da estratégia, não só da execução
✔️ Cria sistemas que fazem sentido para quem usa, e não só para quem programa
Se um botão mal colocado faz seu usuário desistir de uma compra, não importa se seu backend tem a arquitetura mais linda do mundo. Você perdeu.
Se sua API quebra um fluxo porque não pensou no usuário final, o problema não é a API. É a falta de visão de produto.
Essa é a diferença entre quem fica apagando incêndio e quem constrói sistemas que geram resultado.
O cliente não quer software.
O cliente quer vender mais. Quer reduzir custo. Quer ganhar tempo.
E se seu código não resolve isso… então ele não serve pra nada.
É sobre isso. Bora codar com propósito.
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!
Se você ainda acha que UX é só um problema do designer, sinto te informar: você está jogando contra o próprio time. Entender UX não é sobre saber usar Figma ou desenhar telas bonitas. É sobre entender como as pessoas usam aquilo que você codifica.
Se o usuário não sabe onde clicar, se perde, não entende uma mensagem de erro ou abandona um formulário… isso não é um problema só de design. É um problema seu também.
Um botão mal posicionado, um input sem máscara, uma API que responde uma mensagem técnica que o usuário nunca vai entender… tudo isso é UX ruim, vindo do desenvolvimento.
💡 “Se ninguém entende como usar, não adianta estar funcionando.”
Você não precisa ser designer. Mas se você escreve código, faz API, cria backend ou front… você precisa entender experiência de usuário. Isso é o que separa quem entrega sistema… de quem entrega solução.
O código perfeito não é o que funciona.
É o que funciona… e faz sentido pra quem usa.
Antes de qualquer coisa: esse texto não é sobre endeusar quem tem 10 anos de carreira ou coleciona frameworks no currículo.
É sobre o que, na prática, o mercado espera de alguém que se apresenta como desenvolvedor sênior — principalmente se você quer conquistar a confiança de empresas mais exigentes.
Não se trata de saber tudo, mas de saber o suficiente com profundidade. Dominar a stack principal, escrever código limpo, legível e escalável. Entender arquitetura. Saber quando usar um padrão de projeto — e quando não usar.
O dev sênior não vive em bolha. Ele entende que o que está sendo construído precisa funcionar para alguém. Participa das conversas com UX/UI, testa os fluxos com empatia, entende a jornada do usuário.
Ser direto sem ser ríspido. Saber ouvir, negociar prazos, discordar com maturidade. Muitas vezes, é mais sobre como se fala do que o que se fala. E isso impacta diretamente o clima do time.
Não é só saber fazer — é saber ensinar. Empresas valorizam quem compartilha conhecimento e fortalece o time. Ser sênior é ser referência técnica, mas também humana.
Um bom sênior pensa no código que vai herdar, não só no que está escrevendo. Ele considera performance, manutenção, documentação e testes — mesmo no MVP. Entrega com responsabilidade e não deixa bombas-relógio escondidas no projeto.
Ser sênior também é saber dizer “não” para o que atrapalha. Às vezes o maior desafio não está no código, mas no barulho em volta dele. Interferências, decisões apressadas e mudanças mal comunicadas geram mais bugs do que linhas ruins.
🪧 “Se não for ajudar, atrapalhe!” — disse alguém na daily. Acredite: o sênior lembra.
É papel do dev experiente manter o foco da equipe, filtrar o ruído e ajudar o time a trabalhar com consistência.
No fim do dia, o que as empresas esperam de um dev sênior é:
Se você se vê nesse perfil ou está no caminho para isso, saiba: o mercado está olhando. E precisa de mais profissionais assim.
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.