Tiago Luvizoto Neves

Autor: Tiago Luvizoto Neves

Mini CRM Lead Tracker – Dia 7: CRUD de Empresas e Multi-Tenancy Estrito
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.

📦 O que foi implementado
- CRUD completo de empresas (CompanyController)
- Camada de serviço (CompanyService) com filtragem por company_id
- Validação com StoreCompanyRequest e UpdateCompanyRequest
- Formatação de resposta via CompanyResource
- CompanyPolicy garantindo que apenas administradores possam editar
- Middleware company.valid protegendo todas as rotas
- Swagger documentado com exemplos de request e response
- 30 testes automatizados (unitários e feature) com 100% de cobertura do módulo
🏗️ Arquitetura e Segurança

O 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_id
```
Esse modelo elimina riscos de vazamento entre locatários e garante total rastreabilidade para auditorias e compliance (LGPD e GDPR).

🚫 Alternativas rejeitadas

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.

📘 Documentação e Testes

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

📅 Resultado Final

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.

🧠 Lições do Dia 7
- Multi-tenancy não é detalhe: é base de segurança.
- Policies são parte da arquitetura, não apenas “autorização”.
- Services isolam regras de negócio e aumentam testabilidade.
- Testes e Swagger são documentação viva.
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.
outubro 9, 2025
Smart Chat Form – Formulários Conversacionais com JavaScript e Bootstrap 5
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.

🎯 O que é o Smart Chat Form?

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.

⚙️ Principais Funcionalidades
- 💬 Interface tipo chat — experiência semelhante ao WhatsApp ou Messenger
- ⚡ Validação em tempo real — CPF, CNPJ, e-mail e telefone
- 🧩 Lógica condicional — perguntas dinâmicas com base nas respostas anteriores
- 🌐 Integração com API do IBGE — autocomplete inteligente de cidades brasileiras
- 📱 Design responsivo — experiência perfeita em qualquer dispositivo
- 🧠 Zero dependências — apenas HTML, CSS e JavaScript puro
🧠 Como funciona

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.

🔍 APIs e Integrações

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.

💾 Recursos de Armazenamento

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.

🎨 Personalização

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.

🚀 Casos de uso
- 📝 Captação de leads
- 🏢 Formulários de RH e recrutamento
- 🏥 Cadastros de pacientes
- 💳 Onboarding de clientes
- 🎓 Matrículas e pesquisas educacionais
Em todos esses contextos, o Smart Chat Form oferece uma experiência mais humana, agradável e eficiente.

🧩 Tecnologias Utilizadas
- HTML5 – estrutura semântica e acessível
- CSS3 – gradientes, transições e responsividade
- JavaScript ES6+ – async/await, validação, fetch API
- Bootstrap 5 – sistema de grid e componentes modernos
📈 Resultados e Performance
- ⏱️ First Contentful Paint: < 0.5s
- ⚙️ Lighthouse Score: 98/100
- 📦 Tamanho do bundle: ~15KB
🧑‍💻 Open Source

O projeto está disponível publicamente no GitHub sob licença MIT.
Você pode usar, modificar ou contribuir com novas features livremente.

👉 Ver no GitHub
outubro 8, 2025
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