I turn ideas into actual realiable solutions.

Olipay Commercial · private source

B2B + B2C commerce platform for beverage distribution

One catalogue serving walk-in consumers and business accounts buying on credit — plus the warehouse, the storefront and the counter behind them.

Five deployable surfaces run on a single NestJS API: a React Native app, a React PWA for iPhone users, an admin backoffice, an in-store point of sale, and the landing page. All five import the same contract package, so a changed response type breaks the build in whichever app is now wrong.

What I built

The Woovi (Pix) payment integration, including webhook signature verification against the published key format and support for multiple receiving accounts. The point of sale, added as a new surface to the monorepo. The whole warehouse model — storage centres, deposit selection at checkout, product packagings, and cost incidents that separate tax from replacement cost. A promotional flyer generator that composes an encarte in-app and exports it to image and PDF. The metrics and trend endpoints behind the dashboard, B2B credit validation, and the loyalty points programme.

How it holds together

Services depend on repository interfaces bound by DI tokens rather than on Prisma, so unit tests mock the interface and integration tests run against a real database. Four route guards, two-factor auth, a global exception filter, structured logging with request tracing, and custom CPF/CNPJ validators. Tested at four levels, up to Maestro end-to-end runs on a device.

• NestJS 11
• Prisma 7
• PostgreSQL
• React Native · Expo 52
• React 19 · Vite
• Turborepo
• Pino
• Maestro

TeamMove — orders & products Employer · private source

The ordering domain of a field-sales platform, built from the tables up

For eight months in 2023 I was the only developer on the Java API — 440 of the 446 commits in that window are mine.

A sales rep standing in a shop needs to place an order against a catalogue that prices differently per customer. I built that domain: orders, order kinds, products, product families and categories, per-customer price tables, and the extra fields a client adds to a product without anyone shipping a release. Seven Java packages, 154 files — 103 of the 104 commits that touched them are mine.

The whole vertical, in one week

It went in from the bottom. The tables and their access layer first, then the REST endpoints — list, detail, create, update, item removal, status transitions — and the React screens opened the next day, on 28 March 2023. The same person designed the schema, wrote the queries against it and built the screens that read them, which is the only reason a domain this wide could land that fast: there was no contract to negotiate, because there was nobody to negotiate it with.

Orders change after they are approved

That is the constraint the whole thing turns on. An order that is edited after approval has to be able to say what changed, who changed it and what the value was before — so in July 2023 I built a generic change ledger underneath it: five tables recording the operation, the table and row it hit, and the previous and new value of every individual field, attributed to a user and a timestamp. It is table-agnostic on purpose — it carries the table name as data, so anything else in the system can be audited by pointing at it rather than by writing another log. Reconstructing an order's history from free-text log lines is a guess; this is a query.

Then I moved it off Java myself

Two years later the platform migrated to a TypeScript back end and my own module was on the list. I ported it — the list endpoint in May 2025, the detail endpoint the week after — and then kept tuning it there, dropping the ORM for a raw query when the list got slow. Most of what I have written has been maintained by someone else. This is the piece I designed, replaced, and then had to live with on the other side.

And the other three and a half years

Orders and products is one module. Around it sits everything else I did on the same platform: the agenda and its month view, the checklist builder and the runtime that fills one in, the ticket workflow with its briefing and approval stages, campaign rankings, goal calculation split across day and month totals, scheduled jobs, the print pipeline that turns a filled checklist into a signable PDF, and a partner-facing external API. Four years across four repositories — the React client, the Java API, the TypeScript back end that replaced it, and the partner-facing external API. I was the primary maintainer of the client and of the ordering domain; the Java API was already six years old when I arrived. The full scope is below →

• Java · WildFly
• JDBC
• PostgreSQL
• React
• Redux
• Express
• Prisma
• TypeScript

forty-monolito

Training platform for personal trainers

Two apps over one API: the trainer runs their business, and their client logs every set at the gym — where there is no signal.

Trainers get an agenda, a client CRM and income tracking. Their clients get a mobile-first app that works offline first, because that is not a nice-to-have in a gym basement: sets are logged locally and sync when the connection comes back.

Tenant isolation is enforced at two levels of PostgreSQL row-level security — per trainer and per client — so a forgotten WHERE clause cannot leak another trainer's roster. The app stores health-questionnaire responses, which makes that boundary an LGPD obligation rather than a preference. Integration tests run against real Postgres through Testcontainers and assert the isolation directly; Playwright covers the flows end to end.

• Next.js 16
• NestJS 11
• PostgreSQL 17 · RLS
• Prisma 7
• Better-Auth
• Tailwind v4
• Playwright
• Testcontainers

Source on GitHub → How the isolation works →

Resumo dos Candidatos

Election transparency on official open data

It shows an incumbent’s voting record only when it can prove the candidate and the office-holder are the same person. Otherwise it says so.

A public platform for the 2026 Brazilian general election. For each candidate it aggregates their published proposals and — for incumbents seeking re-election — their real voting record, attendance and expenses, entirely from official TSE and Câmara dos Deputados open data.

The interesting part is CandidateMandateLink: a materialised, auditable edge asserting “this 2026 candidacy is the same person who holds this mandate”, carrying its match method, a confidence score and its provenance. Below the accepted threshold the page reads incumbência não confirmada rather than attaching a record that might belong to somebody else. Attributing one politician's votes to another is the one bug this project cannot ship, so the uncertainty is modelled in the schema instead of being resolved by a guess.

The candidate register for 2026 only exists after registration closes, so the whole system was built and validated against 2022 and 2024 data — same schemas — and re-points at 2026 through a single config value. Collectors are idempotent and cron-friendly, writing to a raw-ingestion ledger that keeps every derived fact traceable to the file it came from.

The table is the argument. Nothing about the match is implied:

CREATE TABLE candidate_mandate_link (
  id                      uuid PRIMARY KEY,
  sq_candidato            varchar(32)      NOT NULL REFERENCES candidacy,
  mandate_id              uuid             NOT NULL REFERENCES mandate,
  person_id               uuid                      REFERENCES person,
  match_method            matchmethod      NOT NULL, -- cpf_exact | titulo_exact
                                                     -- | probabilistic | manual
  confidence_score        double precision NOT NULL,
  confidence_tier         confidencetier   NOT NULL, -- auto_strong | auto_weak
                                                     -- | review
  is_incumbent_reelection boolean          NOT NULL,
  pipeline_version        varchar(32),
  resolver                varchar(64),
  resolved_at             timestamptz      NOT NULL DEFAULT now(),
  UNIQUE (sq_candidato, mandate_id)
);

confidence_tier is what the page reads, not confidence_score: a review row is displayed as incumbência não confirmada rather than silently attached. match_method and pipeline_version mean a wrong link can be found again later and re-decided, and the unique constraint on (sq_candidato, mandate_id) is what stops two runs of the resolver disagreeing in the same table.

• Python 3.11
• FastAPI
• SQLAlchemy 2
• Alembic
• Postgres · pg_trgm
• polars
• rapidfuzz
• Typer

Source on GitHub →

Detetive Sonora

Released game — itch.io and GameJolt

Seven lanes are the seven degrees of the scale. A chord sounds; you fly to the lane that matches it. You never need perfect pitch — only the interval.

An ear-training game disguised as a detective story, built as my computer science capstone. Nine songs and 121 chords are authored as plain data, three per difficulty tier and drawn at random each run. Each tier changes both the key and the instrument — C on piano, then G on guitar, then D on electric — so memorising absolute pitches gets you nothing and only relative hearing carries over. The reaction window closes from five seconds to three, and below 70% the level repeats.

Three acts, each opening on a fully voice-acted phone call from the defence minister, about a detective chasing a stolen aircraft. In act three you find out the detective is blind — which is the argument the whole design was making anyway.

• Godot 4.4
• GDScript
• Windows
• pt-BR

Play on itch.io → GameJolt → Source →

TeamMove Employer · private source

Field-sales and merchandising SaaS

For two years the Java API being replaced and the TypeScript one replacing it were both in production. I committed to both in the same month, twenty-four months out of twenty-five.

Software for teams whose work happens outside the office — sales reps and merchandisers visiting stores. Visit scheduling and an agenda, dynamic checklists filled in on site, a ticket workflow with briefing and approval stages, sales goals tracked by day and by month, campaign rankings, action plans, and customer clustering that decides who sees what.

Working across the migration

I joined on the Java REST API and stayed through the move to a TypeScript one. Neither was ever switched off in a single cut: features landed on whichever side owned them, which meant holding both schemas in your head and keeping a report query and its replacement answering the same question. That is the unglamorous part of a migration and it is most of the work — the last two years of my history there run down both tracks in parallel.

• React · Vite
• TypeScript
• Express
• Prisma
• PostgreSQL
• NestJS
• Java · WildFly
• AWS S3

The ordering domain, in detail →

Celk Employer · private source

Public-health systems for city health departments

A required field on a disease investigation form is not a UI preference. It is what the reporting rules say has to be collected, and the form is wrong until it agrees.

Municipal health software — sanitary surveillance, pharmacy and stock control, vaccination — run day to day by city health departments. A Java EE monolith with server-rendered Wicket screens, first committed in 2012 and now well past fifty thousand commits, split across a dozen Maven modules — with newer work going into Quarkus services written alongside it. I work on both sides of that line, which is the same seam as the TeamMove migration above: two stacks in production at once, and a feature landing on whichever one owns it.

What I work on

Disease investigation forms: extended forms, the fields a case cannot be closed without, and period calculation by epidemiological week rather than by calendar month. The licensing side of sanitary surveillance — permit fees, transport licences, veterinary activity records, and the checks that have to pass before a report will generate at all. On the pharmacy side: decimal quantities for prescribed and dispensed medication, merging duplicate medication records, batch selection that carries its own expiry date, stock balance and analysis reports, and the product coding that federal reporting expects.

What the domain costs you

Every change arrives as a ticket against software a city is already running, and goes out through code review before it reaches anyone. Schema changes ship as Flyway migrations held to a naming and DDL standard, because a script that deviates does not fail your build — it fails an upgrade. Most of my fixes here are small and exact for the same reason: a wrong label on a vaccine batch or a missing check on a licence is not a cosmetic bug in this domain.

• Java EE
• Quarkus
• Apache Wicket
• EJB
• Hibernate
• PostgreSQL
• Flyway
• JasperReports
• JBoss

shop-schedule Private

Booking software for businesses that sell time slots

Two clients can tap the last 15:00 slot in the same second. The database is what stops them — not a check in the application.

An agenda, client register, service catalogue, reminders and cash-basis revenue, for any business whose product is a booked slot. Many establishments share one instance, isolated by row-level security.

Availability is computed on every read, never stored. There is no slot table: free time is derived as opening hours ∩ resource hours − time off − live appointments, then sliced by the service's duration. A stored copy means a cancelled holiday leaves a stale slot on the public page and somebody books an appointment the shop cannot honour. The generator lives in a shared package imported by both the API and the front end, so the public booking page and the counter cannot disagree about what is free.

• NestJS
• Prisma
• PostgreSQL 17
• btree_gist
• React · Vite
• pnpm workspaces

How double-booking is made impossible → Quero isso no meu negócio →

ecommerce-base Private

Brazil-first commerce base, cloned per client

An endpoint cannot return a field its contract does not declare. Not by convention — it is stripped on the way out.

A NestJS API, a Next.js storefront and a React admin in one monorepo, handling Pix, card, boleto, CPF/CNPJ and freight by postcode. It is a template: cloned per client, then configured rather than modified — branding, legal identity, checkout rules, payment provider and carrier are all data.

One Zod schema per contract lives in a shared package. nestjs-zod turns each into a DTO, so a single definition drives request validation, response serialisation and the published OpenAPI document, while both front ends infer their types from the same source. The serialiser strips anything the contract does not declare, which means a password hash caught by a careless Prisma select never reaches the wire. Security by construction rather than by code review.

• NestJS 11
• Next.js 16
• React 19
• Zod · nestjs-zod
• Prisma 7
• Redis
• MinIO

Quero isso no meu negócio →

smart-workshop Private

Management software for vehicle workshops

The customer approved R$ 393,70. Mid-job the mechanic finds the brake pads gone. Nobody can hand the bike back at R$ 592,70 until the customer says yes a second time.

Customers and their vehicles, service orders, a parts ledger, the counter’s cash drawer and the month’s receivables — for the kind of Brazilian oficina that still runs on a paper pad. One schema covers mecânica geral, funilaria, pintura and auto elétrica, which only works because insurance workflows are excluded outright: strip those, and a bodywork job is a long-running mechanical one.

A statute, compiled into a guard

Brazilian consumer law is explicit that a customer cannot be charged for work they did not authorise. That is not a checkbox here. An approval is a row — who approved, through which channel, at what total, carrying a JSON snapshot of every line as it stood — and an order cannot reach delivered while its current total exceeds the last figure approved. The comparison is strictly greater, because charging less than approved was never the problem. The check is one pure function in the shared package, so the browser warns using the exact predicate the API enforces, and APPROVED is unreachable except through the call that writes the record — a status you can set directly is precisely the boolean this design refuses to be.

Isolation by absence

The other multi-tenant systems on this page put a policy in the database and a tenant id on every row. This one has neither, deliberately: each workshop gets its own database and its own instance, so the blast radius is a fact about deployment rather than a query somebody has to get right every time. The application never resolves a tenant and the word does not appear in the schema. The cost is real and was written down before it was accepted — N databases to migrate instead of one. Same mechanism as Note 01, argued the other way.

• NestJS 11
• Prisma 7
• PostgreSQL 17
• React 19 · Vite 8
• Zod 4
• TanStack Query
• Tailwind v4
• pdfmake

Why this one has no RLS at all → Why stock is a ledger, not a counter → Quero isso na minha oficina →