Autor: Tiago Luvizoto Neves

  • O cliente não quer software. Ele quer um problema resolvido.

    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.

  • Mini CRM Lead Tracker — Diário de Bordo: Modelagem, Migrations e Arquitetura no Laravel

    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

  • Por que todo dev deveria entender UX (mesmo que nunca faça design)

    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.

  • O que uma empresa realmente espera de um desenvolvedor sênior?

    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.

  • 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

    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.

  • Programadores vs. Usuários? Não. Somos todos parte da mesma interface.

    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.

    Programadores vs. Usuários? Não. Somos todos parte da mesma interface.

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

  • Mini CRM Lead Tracker — Diário de Bordo: Definição de Fluxo do Usuário (User Flow)

    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)

    Diagrama de Fluxo

    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!

  • O Que as Empresas Procuram em um Desenvolvedor Front-end em 2025

    O Que as Empresas Procuram em um Desenvolvedor Front-end em 2025

    Ser um bom desenvolvedor(a) front-end hoje vai muito além de codar com a última framework do mercado. As empresas procuram profissionais completos, que entreguem mais do que interfaces bonitas — entreguem experiências reais.

    O que define o dev front-end que as empresas querem?

    • UX/UI na prática: Não é só saber HTML e CSS — é entender como o usuário pensa e sente. Design não é decoração, é usabilidade e experiência.
    • Domínio de Figma: Saber ler, editar e transformar protótipos em código real. Figma virou o idioma universal do design digital.
    • Ferramentas além do Figma:
      • Photoshop: Para edição de imagens, mockups e tratamento visual.
      • Illustrator: Para trabalhar com vetores, ícones e logos responsivos.
      • After Effects: Para animações e microinterações modernas em UI.
    • Inglês técnico: Entender documentação, Stack Overflow, bibliotecas e colaborar com times globais.
    • Stack afiada: Domínio sólido da stack principal — React, Vue.js ou qualquer outra — mas com vontade de aprender novas tecnologias.
    • Resolução de problemas: Mais importante do que frameworks é a capacidade de pensar, solucionar e evoluir.
    • Boa comunicação: Saber colaborar com designers, produto e explicar problemas técnicos de forma simples é essencial.

    Mais do que codar — é entregar

    No final, o dev front-end ideal é aquele que entrega valor. Que entende o usuário, o design, o time e o produto. Que vê além da tela.

    “Ferramentas mudam. Linguagens evoluem. Mas a capacidade de resolver problemas e criar boas experiências é o que fica.”

    Quer saber mais sobre como se preparar para ser o dev que o mercado procura? Continue acompanhando o blog — novos artigos toda semana!

  • Mini CRM Lead Tracker — Diário de Bordo: Kickoff e MVP

    Mini CRM Lead Tracker — Diário de Bordo: Kickoff e MVP

    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.

    Objetivos do Projeto

    • Captura de leads via landing page integrada.
    • Gerenciamento visual de leads em um Kanban (Arrastar e Soltar).
    • Exportação rápida dos leads para Excel ou Google Sheets.
    • Relatórios básicos para acompanhamento de vendas.

    Stack Tecnológica

    • Back-end: Laravel (PHP 8.x)
    • Front-end: Vue.js 3 + Vite
    • API REST: Documentada com Swagger (OpenAPI)
    • Banco de Dados: MySQL
    • Futuras Automação: Python para relatórios e follow-ups

    Próximos Passos

    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!

  • Como documentar APIs de um Mini CRM usando Swagger

    Como documentar APIs de um Mini CRM usando Swagger

    Documentação de API não é luxo — é necessidade. Especialmente quando estamos construindo um sistema real, como o nosso Mini CRM Lead Tracker.

    Para garantir que o sistema seja sustentável, optamos por usar o padrão Swagger para documentar a API RESTful do CRM.

    O que é Swagger?

    Swagger é um conjunto de ferramentas que usa o padrão OpenAPI Specification para definir, visualizar e interagir com APIs RESTful de maneira padronizada e automática.

    Por que estamos usando Swagger no Mini CRM?

    • 📚 Documentação automatizada e padronizada dos endpoints de leads.
    • 🔍 Facilidade para o front-end Vue.js consumir a API.
    • 🛡️ Melhora a manutenção e escalabilidade do CRM.
    • 🤝 Facilita a integração com futuras automações em Python e exportações para Sheets.

    Exemplo real de anotação (Laravel PHPDoc)

    
      /**
       * @OA\Post(
       *     path="/api/v1/leads",
       *     summary="Cria um novo lead",
       *     @OA\RequestBody(
       *         required=true,
       *         @OA\JsonContent(
       *             required={"nome", "email"},
       *             @OA\Property(property="nome", type="string"),
       *             @OA\Property(property="email", type="string")
       *         )
       *     ),
       *     @OA\Response(
       *         response=201,
       *         description="Lead criado com sucesso"
       *     )
       * )
       */
      

    Conclusão

    Swagger nos permite manter o nosso Mini CRM organizado, claro e fácil de integrar — o que é fundamental para qualquer sistema sério que queremos que dure e evolua.

    “Se não está documentado, é como se não existisse.”

    Você já documenta suas APIs assim? Ou ainda deixa tudo na mão de Deus? 😂