Pular para o conteúdo
Yuri QueirozDesenvolvedor full-stack
Navegação principal / 00–05
Conte-me o problema
PTENES

Portfólio publicado

Sites reais, no ar.

Produtos e sites que você pode abrir agora. Abaixo, os cases técnicos explicam decisões, construção e limites de evidência.

Problemas que entram pela porta

Não precisa chegar com a solução pronta.

Basta conseguir mostrar onde o fluxo quebra, onde o dado se perde ou onde o sistema deixou de acompanhar a operação.

  1. 01

    Planilhas, retrabalho e tarefas manuais

    Quando copiar, conferir e cobrar atualização virou parte do processo, dá para ligar fonte, regra e decisão em um fluxo rastreável.

    Organizar dados e rotina ↗
  2. 02

    Sistemas desconectados ou código abandonado

    Diagnóstico técnico, proteção dos fluxos críticos e evolução por etapas — sem apostar a operação em uma reescrita cega.

    Recuperar o sistema ↗
  3. 03

    Produto, API ou dashboard que precisa nascer

    Da necessidade ao escopo, da arquitetura ao código e dos testes à entrega: uma linha direta para transformar contexto em software.

    Tirar a solução do papel ↗
Cases técnicos e limites de evidência

Prova antes da promessa.

Cada case separa o que foi construído, como foi verificado e o que a evidência não permite afirmar.

Backend .NET 8 para uma plataforma de seguros e serviços financeiros, com requisitos de confidencialidade, segregação por organização e rastreabilidade.

Camadas segregadas de um backend conectadas por trilhas de autorização e auditoria01 / Backend .NET · contexto regulado

Controle e rastreabilidade em um backend .NET 8.

Problema

Um domínio sensível exige que autorização, ownership e mudança de estado sejam verificáveis sem expor cliente, ambiente ou dados confidenciais.

O que foi construído

  • Implementação e revisão de regras de tenancy e ownership
  • Evolução do fluxo de estados e pré-validações

Tecnologias

  • .NET 8
  • ASP.NET Core
  • EF Core
  • MySQL
  • CI
  • Testes

Limite: Case anonimizado. Não comprova produção, homologação, integração externa, compliance nem senioridade formal.

Ver case completo
Fluxos de horários, cobertura e vendas convergindo em uma estrutura de decisão operacional02 / Produto full-stack · dados operacionais

Quando fluxo, vendas e escala entram na mesma decisão.

Problema

Decisões de cobertura perdem qualidade quando demanda, jornada e resultado vivem em relatórios separados.

O que foi construído

  • Modelagem do fluxo de dados e das regras de cobertura
  • Construção do produto full-stack e das visualizações

Tecnologias

  • React
  • TypeScript
  • Supabase
  • Dados
  • Visualização

Limite: A arte é editorial, não screenshot. Nenhum ganho de conversão, adoção ou impacto financeiro é afirmado.

Ver case completo
Pipeline rastreável conectando pesquisa, diagnóstico, execução e acompanhamento03 / Sistema web · automação de fluxo

Da pesquisa ao acompanhamento em um fluxo rastreável.

Problema

Pesquisa, diagnóstico e execução perdem contexto quando cada etapa fica isolada em uma ferramenta ou conversa.

O que foi construído

  • Desenho do fluxo e dos contratos entre etapas
  • Implementação da aplicação e da camada de acompanhamento

Tecnologias

  • Next.js
  • TypeScript
  • APIs
  • Automação
  • SEO técnico

Limite: A arte é editorial. O case não publica score, resultado garantido, cliente ou automação além do que foi verificado.

Ver case completo
Matriz de cenários e sinais avaliados por uma sentinela de confiabilidade04 / Laboratório · confiabilidade de agentes

Falhas encontradas antes do uso real.

Problema

Uma resposta plausível não prova consistência. Agentes precisam ser avaliados contra cenários, critérios e regressões repetíveis.

O que foi construído

  • Desenho dos cenários e da taxonomia de falhas
  • Automação de execução shadow e avaliação

Tecnologias

  • Python
  • LLMs
  • Rubricas
  • Testes
  • Relatórios

Limite: Laboratório e protótipo. Não é case de cliente, agente em produção, garantia de confiabilidade ou impacto comercial.

Ver case completo
Ver índice completo de projetos ↗
Serviços por problema

O tipo de software vem depois da dor.

Escolha pela situação que precisa mudar. Stack, arquitetura e sequência entram quando o contexto está claro.

  1. 01Sistemas web sob medida
  2. 02Evolução e recuperação
  3. 03Backend .NET e APIs
  4. 04Automação e integrações
  5. 05Dashboards e dados
  6. 06SaaS e MVP
  7. 07Sites de conversão
  8. 08Modernização de legado
  9. 09Software financeiro regulado
  10. 10Automação de processos
  11. 11IA para WhatsApp
  12. 12Pipelines e relatórios
Desenvolvedor full-stack em Fortaleza
Como o trabalho acontece

Entender. Delimitar. Construir. Validar.

Ação sem contexto vira retrabalho. Análise sem incremento vira documento parado. A execução alterna decisão e prova.

  1. 01

    Entender

    Reproduzir o problema, ouvir quem usa e definir qual mudança precisa acontecer.

  2. 02

    Delimitar

    Separar escopo, riscos, dependências e critério de sucesso antes de ampliar a solução.

  3. 03

    Construir

    Entregar em incrementos pequenos, integráveis e fáceis de inspecionar.

  4. 04

    Validar

    Testar comportamento, falhas e operação; documentar evidências e próximos passos.

O que fica depois da entrega

Software funcionando — e condição de continuar.

O entregável não termina no arquivo compilado. Decisão, teste e contexto reduzem o custo da próxima mudança.

  1. 01Problema delimitado e critério de sucesso
  2. 02Escopo, decisões técnicas e riscos conhecidos
  3. 03Incremento funcionando e testado
  4. 04Evidência verificável do que foi entregue
  5. 05Documentação necessária para operar e evoluir
  6. 06Próximos passos sem promessa absoluta
Confiança verificável

O que pode ser inspecionado fica visível.

Quando uma prova precisa ficar privada, o limite aparece. Quando pode ser pública, o caminho fica acessível.

Ver GitHub
  1. E01

    Código público

    Repositórios e artefatos públicos quando a confidencialidade permite.

  2. E02

    Testes e CI

    Comportamento importante protegido por testes e gates proporcionais ao risco.

  3. E03

    Prova sanitizada

    Screenshots, diagramas e relatórios só entram depois de revisão de dados e direitos.

  4. E04

    Limite explícito

    NDA, laboratório, ambiente e evidência privada aparecem com o limite visível.

Decisões antes da contratação

Conteúdo para reduzir incerteza.

Ver todos os artigos ↗
Artigo / 01

Quanto custa um sistema web sob medida?

Entenda o que realmente forma o orçamento de um sistema web: escopo, integrações, risco, qualidade, operação e evolução — sem tabela universal.

Ler análise ↗
Artigo / 02

Full-stack ou software house: qual estrutura o projeto exige?

Compare contratação direta e software house por risco, tamanho, velocidade, especialidades e continuidade — sem tratar um modelo como resposta universal.

Ler análise ↗
Artigo / 03

A planilha ainda ajuda — ou já virou parte do problema?

Reconheça os sinais de que Excel ou Google Sheets deixaram de apoiar o processo e veja como migrar por etapas, sem demonizar a planilha.

Ler análise ↗
Perguntas diretas

Antes de começar.

Se a sua dúvida não estiver aqui, use o briefing. O primeiro passo pode ser apenas descobrir qual é a pergunta certa.

Que tipo de projeto você assume?

Sistemas web sob medida, evolução de software existente, backends .NET e APIs, automações, integrações e fluxos de dados. O diagnóstico também pode concluir que o melhor caminho não é construir agora.

Você assume código de outro desenvolvedor?

Sim. A entrada começa por execução controlada, leitura de código, inventário de dependências e proteção dos fluxos críticos. Incerteza e dívida técnica entram explicitamente no plano.

Como o orçamento é formado?

Pelo escopo, incerteza, integrações, criticidade, requisitos de qualidade e formato de acompanhamento. Primeiro delimito o problema e uma entrega verificável; depois proponho custo e sequência.

O trabalho pode ser remoto?

Sim. Descoberta, acompanhamento, demonstrações e entrega podem acontecer remotamente. Qualquer necessidade presencial é combinada antes de fechar o escopo.

Como você trata confidencialidade?

Acesso mínimo, canais definidos, dados fora de analytics e provas públicas sanitizadas. Cases sob NDA exibem somente mecanismos autorizados e limites explícitos.

Quais tecnologias você usa?

TypeScript, React e Next.js no frontend; .NET e Python no backend e automação; SQL, APIs e ferramentas de dados conforme o problema. A stack é consequência das restrições, não um pacote obrigatório.

O que acontece depois do briefing?

Eu leio o contexto, separo dúvidas essenciais e devolvo o próximo passo possível: diagnóstico, recorte de escopo, avaliação técnica ou indicação de que ainda falta informação.

Próximo passo

Traga o problema.

Você não precisa escolher stack nem montar especificação. Descreva o que acontece hoje, quem é afetado e o que precisa mudar.

Briefing de software

Abra uma conversa no WhatsApp e descreva o cenário atual. Contexto, impacto e prioridade bastam para iniciar o diagnóstico.

  • O que acontece hoje
  • Quem ou qual operação é afetada
  • O que precisa mudar primeiro
Descrever meu problema