Skip to content

Bruno Mafra

Product Builder · Software · AI

Portrait of Bruno Mafra

I build digital products to solve real problems.

I combine experience in operations, management and software development to create useful solutions, applying AI and learning from real use.

Explore projectsAbout me
  • 4 productsbuilt from real problems
  • Real useacross some of the products
  • Operationsmanagement experience
  • ADSsystems development studies

Products I built

SplitMate groups screen showing total balance, receivables, payables and group list.

SplitMate

Expense sharing and collaboration

Explore case — SplitMate

Starting point

I start with the problem.

I do not start by picking a technology and looking for somewhere to use it. I start with the problem, its context and the people involved. Then I define hypotheses, model rules, build the solution and observe how it behaves in the hands of real users.

  1. Problem
  2. Context
  3. Decision
  4. Product
  5. Engineering
  6. Validation

Projects

Four problems. Four products.

From restaurant operations to everyday decisions: the context, the choices and what happened when each solution reached people.

Expense sharing and collaboration

Used by friends and acquaintances

SplitMateSplitting equally does not always mean splitting fairly.

It started at a barbecue with friends. Not everyone consumed the same items: I did not drink beer, for example.

SplitMateInteractive demo

Try the idea

Should someone who didn't drink pay for the beer?

Change the participants and watch the bill adjust. Fictional example, no account and no saved data.

The problem

An equal split would make some people pay for things they had not consumed. Doing it manually meant identifying participants, payments and proportions for each expense.

The product decision

The hypothesis was to define who paid, who participated and each person’s weight for every expense. The system then calculates balances, records payments and simplifies group debts.

  1. Expense
  2. Who paid
  3. Participants + weights
  4. Balances
  5. Settlements

Validation and use

Used by friends and acquaintances in Maceió, inland Alagoas and the United States.

How it evolved

It started as an individual tool. Use showed that everyone needed to follow the same account: shared groups, invitations, participants without accounts, avatars and collaboration followed.

Inside the product
Shared groups and balances make tracking settlements part of the experience.
Engineering decisions

Balancing to the exact cent

Calculations in cents and deterministic remainder allocation address the main challenge: weighted splits must add up to the exact expense amount.

Sharing and access

PostgreSQL, RLS and authentication support shared groups and access to data.

Web and Android

Next.js, React and TypeScript power the web app, with Capacitor for Android.

This project’s technologies

  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Supabase
  • Capacitor
Open app — SplitMate (opens in a new tab)View code — SplitMate (opens in a new tab)

The app requires sign-in. Explore this case and its screenshots without an account.

↑ Back to the four projects

Shared finances

In daily use

TogetherTracking your money is not the same as knowing how much you can spend.

It began with a financial difficulty my wife and I faced. Before building the product, we tried spreadsheets, manual records and other solutions.

The problem

Recording expenses did not tell us how much money was actually available. Installments, bills, card statements and future commitments needed to appear in the same picture.

The product decision

The Household is the shared financial unit. Income, expenses, cards, bills, installments and goals feed commitment and projection calculations. The answer for a decision is: “Free to spend”.

  1. Household
  2. Financial data
  3. Commitments + projection
  4. Free to spend

Validation and use

My wife and I use it daily. My brother and his wife, my sister and her husband, my mother and younger sister, and a couple of friends in the United States also use it.

How it evolved

Real use brought new needs and helped the product evolve, including extra income. Its value lies in turning recorded commitments into a decision about what still fits the budget.

Inside the product
“Free to spend” combines income and commitments to support the monthly decision.

Real-life decisions

  • Our friends in the US saw that new commitments would require additional income and began organizing extra days of Grubhub/Uber work.
  • My sister uses Together to organize savings for a trip to the US.
  • The couple in the US also uses the system to track income and costs for a small house-cleaning operation.
Engineering decisions

Financial rules

Financial cycles, card statement rules and snapshots structure commitment and projection calculations.

Consistency and concurrency

PostgreSQL, RPCs and transactions, with pg_advisory_xact_lock and FOR UPDATE, support concurrent operations. RLS controls data access.

Continuous verification

Vitest, GitHub Actions and CodeQL are part of the project’s quality foundation.

This project’s technologies

  • React 18
  • TypeScript
  • Vite
  • Tailwind CSS
  • Supabase
  • PostgreSQL
  • Vitest
  • GitHub Actions
  • CodeQL
Open app — Together (opens in a new tab)View code — Together (opens in a new tab)

The app requires sign-in. Explore this case and its screenshots without an account.

↑ Back to the four projects

Restaurant operations

Tested by the owner

MiseHow do you turn a restaurant operation into software?

It grew out of my professional experience in restaurant operations and a conversation with the owner of a small establishment.

The problem

Service, orders, production, inventory, delivery and payment need to work together. Recording a sale is only part of it: an order must move through the entire operation without losing context.

The product decision

I modeled the operation around a central order entity. An order can start at the counter, at a table or through delivery and remain the same order throughout the workflow.

  1. Service
  2. Order
  3. Production
  4. Inventory
  5. Delivery
  6. Payment

Validation and use

The owner who inspired the idea tested the product on desktop and mobile. Mise is not in production: adoption was postponed because of a change in the establishment’s team.

How it evolved

The initial conversation developed into a POS, tables, a kitchen display system (KDS), delivery, inventory, recipe costing, permissions and cash management, connected through the order.

Inside the product
The operations dashboard brings orders, cash and inventory together. Screenshots of the demonstrated version.
From problem to product — explore the decisions

Inside a product decision · Mise

Choose a stage to follow the reasoning.

Problem

Mise / In practice

The sale is only the start of an order.

A small establishment needs to connect service, production, inventory, delivery and payment. Recording the sale alone does not solve the journey between these stages.

  • Service
  • Production
  • Inventory
  • Payment
01 / 06
Engineering decisions

One order, different entry points

Order modeling and production states represent counter, table and delivery workflows. Station tickets organize kitchen work.

Inventory and consistency

Recipe specifications, stock movements and FEFO (first expired, first out) represent ingredient use. Transactions and synchronization are part of connecting the workflows.

Access by responsibility

Permissions and role architecture define how each function accesses the operation.

This project’s technologies

  • Next.js
  • TypeScript
  • Supabase
  • PostgreSQL
  • Zod
  • Playwright
Open app — Mise (opens in a new tab)View code — Mise (opens in a new tab)

The app requires sign-in. Explore this case and its screenshots without an account.

↑ Back to the four projects

AI in everyday life

Recurring use

TemAIThe problem was not finding a recipe. It was figuring out what to make with what was already at home.

It grew out of a family need and situations I had also observed while working in kitchens.

The problem

Having ingredients does not mean knowing what to cook. “I have this, what can I make?” and “I want to make this, how do I do it?” are different intentions that need different paths.

The product decision

I separated ingredients → possibilities from intention → recipe library. In the generation flow, AI suggests up to three options; the full recipe is generated only after a choice.

  1. Ingredients
  2. OpenAI
  3. Suggestions + filters
  4. Up to 3 options
  5. Choice
  6. Full recipe

Validation and use

Used regularly within my family and by people and professionals close to me.

How it evolved

The product organizes two paths: explore possibilities with available ingredients or consult the owned catalog with a recipe in mind. Caching avoids unnecessary regeneration.

Inside the product
The interface offers paths for exploring ingredients and browsing recipes.
Engineering decisions

Two-stage generation

Suggestions first, the full recipe after selection. The OpenAI API enters the workflow with prompts and user context.

Response control

Filters and post-processing adjust suggestions. Caching reuses results to avoid unnecessary regeneration.

What AI does

Generation uses model knowledge, prompts, filters and post-processing. It does not search the internet or use custom recipe training or fine-tuning. The library offers an owned catalog.

This project’s technologies

  • Next.js
  • TypeScript
  • Supabase
  • OpenAI API
  • Capacitor
Open app — TemAI (opens in a new tab)View code — TemAI (opens in a new tab)

The app requires sign-in. Explore this case and its screenshots without an account.

↑ Back to the four projects

How I build

Human decisions. Engineering and AI to build.

Every project starts with a concrete situation. Before choosing tools, I try to understand who has the problem, how it happens and which rules need to be represented.

  1. Problem

    Identify the difficulty: in Together, recording expenses was not enough to make decisions.

  2. Context

    Understand people and routines: in Mise, an order passes through different operational stages.

  3. Hypothesis

    Propose a rule: in SplitMate, participants and weights allow splits based on consumption.

  4. Product

    Define the experience: in TemAI, exploring ingredients and finding a recipe are different paths.

  5. Engineering

    Model data, states, permissions and calculations to support those decisions.

  6. Validation

    Observe use, acknowledge limits and evolve: extra income entered Together through real needs.

The problem, product decisions and validation come from human experience. AI accelerates the exploration and implementation of those decisions in software.

Background

My previous experience is part of what I build.

My transition into technology did not begin by abandoning my previous experience. It began when I realized that the problems I already solved in operations could also be turned into software.

Map / background-- / 07

Select a point in the timeline to open its context.

Experience

Executive chef. Management that informs product decisions.

Leading operations meant understanding people, processes, costs and consequences. That operational knowledge is part of the origin of the products I build.

  • Up to 60 peoplein teams I led
  • 4 yearsof experience in the US

Leadership and training

Team coordination, training and decision-making under pressure.

Openings and standards

Launching operations, organizing routines and defining processes.

Costs and operations

Cost management, high-volume service and everyday problem solving.

Stack

Tools in service of decisions.

Each product uses its own combination; project-specific technologies appear in its engineering details.

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

Contact

Let’s talk about problems worth solving.

Open to junior roles, internships and teams that value product, engineering and real operational experience.

Connect on LinkedIn (opens in a new tab)Explore my GitHub (opens in a new tab)