Pular para o conteúdo

Bruno Mafra

Product Builder · Software · IA

Retrato de Bruno Mafra

Construo produtos digitais para resolver problemas reais.

Combino experiência em operações, gestão e desenvolvimento de software para criar soluções úteis, com IA aplicada e aprendizado a partir do uso real.

  • 4 produtosconstruídos a partir de problemas
  • Uso realem parte dos produtos
  • Operaçõesexperiência em gestão
  • ADSformação em andamento

Produtos que construí

Tela de grupos do SplitMate com saldo total, valores a receber e pagar e lista de grupos.

SplitMate

Rateio e colaboração

Explorar case — SplitMate

Ponto de partida

Eu começo pelo problema.

Não começo escolhendo uma tecnologia e procurando onde utilizá-la. Começo pelo problema, seu contexto e as pessoas envolvidas. A partir disso, defino hipóteses, modelo regras, construo a solução e observo como ela se comporta nas mãos de usuários reais.

  1. Problema
  2. Contexto
  3. Decisão
  4. Produto
  5. Engenharia
  6. Validação

Projetos

Quatro problemas. Quatro produtos.

Da operação gastronômica às decisões do cotidiano: o contexto, as escolhas e o que aconteceu quando cada solução chegou às pessoas.

Rateio e colaboração

Em uso por amigos e conhecidos

SplitMateDividir igualmente nem sempre significa dividir justamente.

Nasceu durante um churrasco com amigos. Nem todos consumiam os mesmos itens: eu, por exemplo, não bebia cerveja.

SplitMateDemonstração interativa

Experimente a ideia

Quem não bebeu precisa pagar a cerveja?

Mude os participantes e veja a conta se reorganizar. Exemplo fictício, sem cadastro e sem salvar dados.

O problema

Dividir tudo igualmente faria algumas pessoas pagarem pelo que não consumiram. Resolver isso à mão exigia identificar participantes, pagamentos e proporções para cada despesa.

A decisão de produto

A hipótese foi permitir definir quem pagou, quem participou e o peso de cada pessoa em cada despesa. A partir disso, o sistema calcula saldos, registra pagamentos e simplifica as dívidas do grupo.

  1. Despesa
  2. Quem pagou
  3. Participantes + pesos
  4. Saldos
  5. Acertos

Validação e uso

Usado por amigos e conhecidos em Maceió, no interior de Alagoas e nos Estados Unidos.

Como evoluiu

Começou como ferramenta individual. O uso mostrou que todos precisavam acompanhar a mesma conta: vieram grupos compartilhados, convites, participantes sem conta, avatares e uma experiência colaborativa.

Por dentro do produto
Grupos e saldos compartilhados tornam o acompanhamento dos acertos parte da experiência.
Decisões de engenharia

Fechar exatamente no centavo

Cálculos em centavos e distribuição determinística dos restos tratam o principal desafio: divisões ponderadas precisam fechar exatamente no valor da despesa.

Compartilhamento e acesso

PostgreSQL, RLS e autenticação sustentam a experiência de grupos compartilhados e o acesso aos dados.

Web e Android

Next.js, React e TypeScript na aplicação web, com Capacitor para Android.

Tecnologias deste projeto

  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Supabase
  • Capacitor
↑ Voltar aos quatro projetos

Finanças compartilhadas

Em uso diário

TogetherQuando controlar o dinheiro não é o mesmo que saber quanto você pode gastar.

Começou com uma dificuldade financeira minha e da minha esposa. Antes do produto, tentamos planilhas, registros manuais e outras soluções.

O problema

Registrar os gastos não respondia quanto do dinheiro ainda estava realmente livre. Parcelas, contas, faturas e compromissos futuros precisavam aparecer na mesma leitura.

A decisão de produto

O Household é a unidade financeira compartilhada. Rendas, gastos, cartões, contas, parcelas e metas alimentam os cálculos de comprometimento e projeção. A resposta para decidir é: “Livre para gastar”.

  1. Household
  2. Dados financeiros
  3. Comprometimento + projeção
  4. Livre para gastar

Validação e uso

Eu e minha esposa usamos diariamente. Também usam meu irmão e sua esposa, minha irmã e seu esposo, minha mãe e minha irmã mais nova, além de um casal de amigos nos Estados Unidos.

Como evoluiu

O uso real trouxe novas necessidades e ajudou a evoluir o produto, incluindo renda extra. O valor está em transformar os compromissos registrados em uma decisão sobre o que ainda cabe no orçamento.

Por dentro do produto
“Livre para gastar” reúne renda e comprometimento para apoiar a decisão do mês.

Decisões na vida real

  • Nos EUA, o casal de amigos percebeu que novos compromissos exigiriam renda complementar e passou a organizar dias extras de Grubhub/Uber.
  • Minha irmã usa o Together para organizar a economia de uma viagem aos EUA.
  • O casal nos EUA também utiliza o sistema para acompanhar entradas e custos de uma pequena operação de limpeza de casas.
Decisões de engenharia

Regras financeiras

Ciclos financeiros, regras de fatura e snapshots dão estrutura aos cálculos de comprometimento e projeção.

Consistência e concorrência

PostgreSQL, RPCs e transações, com pg_advisory_xact_lock e FOR UPDATE, compõem o tratamento de operações concorrentes. RLS controla o acesso aos dados.

Verificação contínua

Vitest, GitHub Actions e CodeQL fazem parte da base de qualidade do projeto.

Tecnologias deste projeto

  • React 18
  • TypeScript
  • Vite
  • Tailwind CSS
  • Supabase
  • PostgreSQL
  • Vitest
  • GitHub Actions
  • CodeQL
↑ Voltar aos quatro projetos

Operação gastronômica

Testado pelo proprietário

MiseComo transformar uma operação gastronômica em software?

Nasceu da minha experiência em operações gastronômicas e de uma conversa com o proprietário de um pequeno estabelecimento.

O problema

Atendimento, pedido, produção, estoque, entrega e pagamento precisam funcionar juntos. Registrar a venda é só uma parte: o pedido precisa atravessar toda a operação sem perder contexto.

A decisão de produto

Modelei a operação em torno de uma entidade central de pedido. Ele pode nascer no balcão, na mesa ou no delivery e continua sendo o mesmo pedido durante todo o fluxo.

  1. Atendimento
  2. Pedido
  3. Produção
  4. Estoque
  5. Entrega
  6. Pagamento

Validação e uso

O proprietário que originou a ideia testou o produto em desktop e mobile. O Mise não está em produção: a adoção foi adiada por uma mudança na equipe do estabelecimento.

Como evoluiu

Da conversa inicial, a solução se desdobrou em PDV, mesas, KDS (painel de produção da cozinha), delivery, estoque, fichas técnicas, permissões e caixa, conectados pelo pedido.

Por dentro do produto
Painel operacional: pedidos, caixa e estoque na mesma leitura. Capturas da versão demonstrada.
Do problema ao produto — explore as decisões

Uma decisão por dentro · Mise

Escolha uma etapa para acompanhar o raciocínio.

Problema

Mise / Na prática

Vender é só o começo do pedido.

Um pequeno estabelecimento precisa conectar atendimento, produção, estoque, entrega e pagamento. Registrar a venda não resolve sozinho o caminho entre essas etapas.

  • Atendimento
  • Produção
  • Estoque
  • Pagamento
Decisões de engenharia

Um pedido, diferentes entradas

Modelagem de pedidos e estados de produção para representar balcão, mesas e delivery. Tickets por estação organizam o trabalho da cozinha.

Estoque e consistência

Fichas técnicas, movimentações e FEFO (primeiro a vencer, primeiro a sair) representam o uso dos insumos. Transações e sincronização fazem parte da conexão entre os fluxos.

Acesso por responsabilidade

Permissões e arquitetura de roles definem o acesso de cada função à operação.

Tecnologias deste projeto

  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • Zod
  • Playwright
↑ Voltar aos quatro projetos

IA aplicada ao cotidiano

Uso recorrente

TemAIO problema não era encontrar uma receita. Era descobrir o que fazer com o que já existia em casa.

Nasceu de uma necessidade familiar e de situações que também observei trabalhando em cozinha.

O problema

Ter ingredientes não significa saber o que preparar. “Tenho isso, o que consigo fazer?” e “Quero fazer isso, como faço?” são intenções diferentes e precisam de caminhos diferentes.

A decisão de produto

Separei ingredientes → possibilidades de intenção → biblioteca de receitas. Na geração, a IA sugere até três opções; só depois da escolha é gerada a receita completa.

  1. Ingredientes
  2. OpenAI
  3. Sugestões + filtros
  4. Até 3 opções
  5. Escolha
  6. Receita completa

Validação e uso

Usado de forma recorrente dentro da família e por pessoas e profissionais próximos.

Como evoluiu

O produto organiza dois caminhos de uso: explorar possibilidades com os ingredientes disponíveis ou consultar o catálogo próprio a partir de uma intenção. O cache evita regenerações desnecessárias.

Por dentro do produto
A interface oferece caminhos para explorar ingredientes e consultar receitas.
Decisões de engenharia

Geração em duas etapas

Sugestões primeiro, receita completa depois da seleção. A OpenAI API entra no fluxo com prompts e contexto do usuário.

Controle da resposta

Filtros e pós-processamento ajustam as sugestões. O cache reutiliza resultados para evitar regenerações desnecessárias.

O que a IA faz

A geração usa conhecimento do modelo, prompts, filtros e pós-processamento. Não faz busca na internet e não utiliza treinamento próprio ou fine-tuning de receitas. A biblioteca oferece um catálogo próprio.

Tecnologias deste projeto

  • Next.js
  • TypeScript
  • Supabase
  • OpenAI API
  • Capacitor
↑ Voltar aos quatro projetos

Como eu construo

Decisões humanas. Engenharia e IA para construir.

Cada projeto começa com uma situação concreta. Antes das ferramentas, procuro entender quem tem o problema, como ele acontece e quais regras precisam ser representadas.

  1. Problema

    Identificar a dificuldade: no Together, registrar gastos não bastava para decidir.

  2. Contexto

    Entender pessoas e rotinas: no Mise, o pedido atravessa diferentes etapas da operação.

  3. Hipótese

    Propor uma regra: no SplitMate, participantes e pesos permitem dividir conforme o consumo.

  4. Produto

    Definir a experiência: no TemAI, explorar ingredientes e buscar uma receita são caminhos distintos.

  5. Engenharia

    Modelar dados, estados, permissões e cálculos para sustentar essas decisões.

  6. Validação

    Observar o uso, reconhecer limites e evoluir: a renda extra entrou no Together a partir de necessidades reais.

O problema, as decisões de produto e a validação vêm da experiência humana. A IA acelera a exploração e a implementação dessas decisões em software.

Trajetória

A experiência anterior faz parte do que construo.

Minha transição para tecnologia não começou abandonando minha experiência anterior. Começou quando percebi que os problemas que eu já resolvia na operação também poderiam ser transformados em software.

Mapa / trajetória-- / 07

Selecione um ponto da trajetória para abrir o contexto.

Experiência

Chef executivo. Gestão que virou repertório de produto.

Liderar operações exigiu entender pessoas, processos, custos e consequências. Esse domínio operacional é parte da origem dos produtos que construo.

  • Até 60 pessoasem equipes que liderei
  • 4 anosde experiência nos EUA

Liderança e treinamento

Coordenação de equipes, treinamento e tomada de decisão sob pressão.

Implantação e padronização

Abertura de operações, organização de rotinas e definição de processos.

Custos e operação

Gestão de custos, alto fluxo e resolução de problemas no dia a dia.

Stack

Ferramentas a serviço das decisões.

Cada produto utiliza uma combinação própria; as tecnologias de cada case estão nos detalhes de engenharia.

  • React
  • TypeScript
  • Next.js
  • Vite
  • Python
  • Supabase
  • PostgreSQL
  • OpenAI API
  • Capacitor
  • Codex
  • VS Code
  • Git
  • GitHub
  • Vercel
  • GitHub Actions
  • Vitest
  • Playwright
  • ESLint
  • CodeQL

Contato

Vamos conversar sobre problemas que merecem uma solução.

Aberto a vagas júnior, estágio e times que valorizam produto, engenharia e experiência real em operações.