Tiago Luvizoto Neves

Autor: Tiago Luvizoto Neves

Mini CRM Lead Tracker — Diário de Bordo: Laravel Sanctum, Multitenancy e Controle por Perfil: Segurança e Escalabilidade no Mini CRM Lead Tracker
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.

📌 O que foi implementado
- Autenticação via Laravel Sanctum com retorno de accessToken
- Middleware EnsureCompanyIsValid para garantir escopo por empresa
- Middleware role:{slug} para validação de perfil (admin, operador, master)
- Seeder de roles, companies e users para testes realistas
- Swagger funcional com autenticação via Bearer Token
- Documentação atualizada no README.md com payloads reais
- Inclusão do campo is_active via migration incremental
- Preparação do arquivo CHANGELOG.md para rastreabilidade técnica
🔐 Sanctum: Token, Segurança e Simplicidade

Escolhi 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.

🏢 Multitenancy via Middleware

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);
}
```
👥 Controle por Perfil com Roles

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 completos para testes

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.

🧾 Migration incremental para is_active

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.

📘 Documentação Swagger com Autenticação

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.

📂 README.md e CHANGELOG.md

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.

✅ Resultado final

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.

🧠 Lições do Dia 6
- Não existe arquitetura limpa sem controle de acesso bem definido
- Multitenancy exige validação explícita e middleware dedicado
- Roles não são strings soltas: são entidades com estrutura
- Swagger e seeders são ferramentas de documentação viva
📅 Diário de Bordo – Dia 6 concluído!

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.
julho 12, 2025
Clean Code não é perfumaria. É o seguro de vida do seu time.
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.

👨‍💻 Código feio vicia a empresa em você

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.

🧠 Arquitetura não é frescura. É responsabilidade.

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”.
- Controller cuida do fluxo
- Service cuida da regra
- Job cuida do que pode esperar
Simples. Elegante. Sustentável.

🚨 Dev sênior que não compartilha, sabota.

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.
julho 11, 2025
API REST com MVC de verdade no Mini CRM Lead Tracker
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.

✅ Entregas do dia
- Controllers enxutos, só delegando a lógica
- Services para encapsular regras de negócio
- Models focados em persistência e relacionamento
- FormRequest para validações desacopladas
- Resource para padronizar as respostas da API
- Jobs + Events para ações desacopladas e assíncronas
- Rotas versionadas com middleware e prefix (ex: /api/v1/leads)
🧠 Aplicando MVC com consciência

Muita gente acha que usa MVC. Mas na prática, mistura tudo no controller ou entope o model de regra.

Aqui, aplicamos:
- Model → responsabilidade: banco e relações
- View → no caso, é o Resource (output JSON padronizado)
- Controller → apenas orquestra, sem conter lógica
📦 GitHub com tudo implementado

👉 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 🚀
julho 9, 2025
O cliente não quer software. Ele quer um problema resolvido.

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.

💡 O erro que muito dev comete

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

🔍 Não é sobre código. É sobre impacto.

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.

🚀 Dev que pensa só em código é operário. Dev que pensa em solução vira sênior, vira referência, vira indispensável.

Essa é a diferença entre quem fica apagando incêndio e quem constrói sistemas que geram resultado.

🏆 Resumo pra vida:

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.

junho 23, 2025
Mini CRM Lead Tracker — Diário de Bordo: Modelagem, Migrations e Arquitetura no Laravel
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.

🧠 Pensamento de Arquitetura

Antes de qualquer linha de código, cada tabela foi pensada para representar entidades reais do negócio:
- Companies — Cada cliente que contrata nosso CRM.
- Users — Usuários que pertencem às empresas.
- Roles — Permissões e perfis (admin, operador, etc.).
- Leads — Os potenciais clientes que serão gerenciados no CRM.
- Kanban Stages — Os estágios do funil de vendas (ex.: Contato, Proposta, Fechamento).
- Activity Logs — Histórico de movimentações e ações nos leads.
Se o banco não faz sentido, nenhum código faz.

🔗 Modelagem no Laravel

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.

📑 Swagger: documentando desde o início

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.

🚀 Resultado dessa etapa:

✅ 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!

👉 Veja o código no GitHub
junho 21, 2025
Por que todo dev deveria entender UX (mesmo que nunca faça design)
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.

UX é sobre não gerar dúvida

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.

O código que você escreve tem UX

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.

Por que devs ignoram UX?
- Porque acham que “isso é coisa de design”
- Porque focam só na regra de negócio e esquecem a experiência
- Porque nunca ensinaram isso na faculdade, nem no bootcamp
O que muda quando você entende UX?
- Você começa a prever onde o usuário vai errar
- Evita que problemas de usabilidade virem tickets, bugs ou suporte
- Entrega sistemas mais claros, simples e bem pensados
- Seu código deixa de ser “funciona” e passa a ser “funciona pra quem usa”
💡 “Se ninguém entende como usar, não adianta estar funcionando.”

Conclusão

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.
junho 16, 2025
O que uma empresa realmente espera de um desenvolvedor sênior?
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.

1. Domínio técnico consistente

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.

2. Visão de produto e experiência do usuário

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.

3. Comunicação clara e respeitosa

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.

4. Mentoria e troca

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.

5. Visão de longo prazo

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.

6. Lidar com dis trações (e proteger o foco do time)

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.

Conclusão

No fim do dia, o que as empresas esperam de um dev sênior é:
- Alguém que resolve problemas com visão ampla
- Que contribui para o crescimento do time
- E que entrega valor real — com consistência
Se você se vê nesse perfil ou está no caminho para isso, saiba: o mercado está olhando. E precisa de mais profissionais assim.
junho 11, 2025
Mini CRM Lead Tracker — Diário de Bordo: Modelagem de Dados e Diagrama ER
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.

Por que começar com um Diagrama ER?

O Diagrama Entidade-Relacionamento (ER) é a espinha dorsal do projeto. Ele ajuda a visualizar:
- Como as tabelas se conectam entre si
- As chaves primárias e estrangeiras
- A estrutura relacional do banco
- Multiplicidade (1:N, 1:1, etc.)
Estrutura atual do Mini CRM

O sistema ainda está em fase MVP, mas já conta com uma modelagem que respeita boas práticas e antecipa crescimento:
- companies: dados das empresas contratantes do sistema (modelo multitenancy)
- users: usuários da empresa com função (master ou operador)
- roles: define os tipos de permissão no sistema
- leads: contatos gerenciados no funil
- kanban_stages: estágios personalizados do funil
- activity_logs: histórico de movimentações de leads
Preview do Diagrama ER

Próximos Passos

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.
junho 10, 2025
Programadores vs. Usuários? Não. Somos todos parte da mesma interface.
Antes de mais nada, este não é um texto para dizer que programadores são mais inteligentes ou que usuários são leigos. Pelo contrário: é para lembrar que ambos os lados têm seus desafios — e que, no fim, todo sistema é feito por pessoas e para pessoas.

Do lado do desenvolvedor…

Quem nunca passou por isso: você entrega o sistema funcionando, validado, com mensagens claras… e no dia seguinte recebe um chamado:

“O sistema está com bug.”

Quando, na verdade, era só uma mensagem que o usuário não leu — ou não entendeu.

Isso não é burrice. É falta de UX.

Do lado do usuário…

Tentar usar um sistema que parece ter sido feito por um alienígena também não é fácil.

Quantos já tentaram preencher um formulário, erraram uma vírgula no CPF e tiveram que recomeçar tudo do zero? Frustrante, né?

UX/UI: a ponte entre os mundos

É aqui que entra o verdadeiro herói: UX/UI. Design de interface não é sobre beleza — é sobre comunicação e usabilidade.
- Prevê erros antes que eles aconteçam.
- Mostra mensagens claras.
- Oferece caminhos lógicos.
- Respeita o tempo e a inteligência do usuário.
Conclusão

Se um sistema exige que o usuário pense como um programador, ele não é intuitivo. Se o desenvolvedor não se coloca no lugar do usuário, o sistema não é empático.

“Programar é construir pontes — não muros.”

Vamos trocar experiências? Seja como dev ou como usuário, comenta aqui e compartilha sua visão. 👇
junho 9, 2025
Mini CRM Lead Tracker — Diário de Bordo: Definição de Fluxo do Usuário (User Flow)
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.

Por que começamos pelo User Flow?

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 Principal (Atualizado para MVP Profissional):
1. Login: Usuário faz login seguro com email e senha.
2. Dashboard (Analytics):
  - Big Numbers (Total de Leads, Leads Ativos, Leads Fechados).
  - Funil Visual (Quantos leads por estágio).
  - Últimos Leads Cadastrados.
3. Página Leads (Operacional):
  - Kanban View (movimentação de leads por estágio).
  - Lista View com Filtros Inteligentes (Status, Origem, Período).
  - Histórico de Movimentações do Lead (registro de mudanças de estágio).
  - Visualizar Detalhes do Lead (dados completos do lead).
  - Adicionar Novo Lead.
  - Exportar Leads (Excel/Sheets).
4. Logout: Finalizar sessão de forma segura.
Diagrama de User Flow (Atualizado)

O que esse fluxo proporciona?
- Visão gerencial clara para gestores.
- Operação simples e ágil para o time comercial.
- Escalabilidade para integrações futuras.
- Facilidade de uso com UX pensada desde o início.
“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!
junho 9, 2025