Product Engineer |AI & Full-Stack |Product-Oriented, Scalable Systems
Product Engineer with 5+ years of experience building high-volume AI platforms, mission-critical financial infrastructure, and leading engineering squads from zero to scale.
Clinicorp·2023 — 2024·Tech lead & architect · 4-person squad
In-house billing & recurring payments engine
Replaced a third-party subscription-billing vendor with an in-house engine that owns the full recurrence lifecycle — and never double-charges a customer.
Impact
Zero double-charge incidents since launch
Reconciliation automated: a daily ledger diff replaced a manual spreadsheet
Billing cycles, proration and dunning now ship in days, not vendor requests
How it works — the problem & the architectureHide the detail
The problem
All recurring revenue ran through a third-party billing provider whose fee scaled linearly with revenue — so growth made the problem worse, not better.
The bigger cost was control. The recurrence lifecycle lived inside the vendor, so proration, pauses and dunning changes all meant waiting on someone else's roadmap. Reconciliation was manual, and finance kept a spreadsheet as the real source of truth.
The architecture
Idempotency as a hard guarantee, not a convention
Every money-moving write is keyed by a client-supplied idempotency key, stored with a fingerprint of the request and a snapshot of the response. The key is a unique index, so concurrent retries race into one INSERT and the loser replays the stored response. A key reused with a different payload is rejected outright. A network timeout is therefore always safe to retry.
Acquirer webhooks: at-least-once and out of order
Acquirer webhooks arrive duplicated, out of order and sometimes hours late. Ingestion does the minimum: verify signature, append to an immutable event log, dedupe on the provider's event id, acknowledge. Processing runs async off a queue, and charge state is an explicit guarded state machine — so a late 'authorized' cannot walk a charge back from 'settled'.
A double-entry ledger as the source of truth
Balances are never mutable columns. Every movement — charge, capture, refund, chargeback, fee — is an append-only pair of ledger entries, and balance is a projection over them. That made reconciliation trivial to write and impossible to fudge: each acquirer's daily settlement file is diffed against the ledger, and any non-zero delta pages a human.
Recurrence and dunning owned in-house
A scheduler materialises invoices ahead of each cycle instead of charging on a cron tick, separating 'what is owed' from 'when we tried to collect'. That makes proration, plan changes and pauses ordinary data operations. Failed collections enter a dunning ladder with retry windows tuned to each acquirer's soft-decline behaviour.
Node.js
TypeScript
PostgreSQL
Redis
Message queue
Acquirer APIs
Clinicorp·2023 — 2024·Tech lead
High-volume messaging platform
Led the team that built the messaging layer several products depend on — at a throughput where the provider's rate limits, not our servers, are the binding constraint.
Impact
One platform replaced per-team messaging implementations
Rate-limit violations and account penalties stopped being an operational event
Per-message delivery status made message-dependent workflows debuggable
Grew and led the team that owns it, on-call and runbooks included
How it works — the problem & the architectureHide the detail
The problem
Every product team needed high-volume transactional and campaign messaging, and each was reinventing the same hard parts: rate limiting, retries, template approval, delivery tracking.
Providers enforce strict per-number throughput limits and penalise senders who exceed them — and there is no way to un-send. Delivery was also a black box: nobody could answer whether a customer actually received a message a workflow depended on.
The architecture
Transactional outbox instead of in-request sends
Nothing sends inside the request that created it. Business transactions write the intent to an outbox table in the same commit as their own state change, and a relay drains it. A crash between 'we decided to notify' and 'we notified' is recoverable, so the send is retried rather than lost.
Token-bucket rate limiting, per sending identity
Throughput is governed by distributed token buckets in Redis, scoped per sending number and per tenant, so one tenant's campaign cannot consume another's capacity or trip a shared account limit. Workers pull only as fast as tokens allow, keeping backpressure in the queue rather than at the provider.
Delivery receipts folded back into state
Provider status callbacks go through the same discipline as any untrusted webhook — verified, deduped, appended, processed async — and project onto a per-message status timeline. Products can branch on 'delivered' versus 'sent', and failures are classified retryable versus terminal so the retry policy is not guessing.
Templates as versioned, reviewable artifacts
Templates carry their provider approval state as part of their lifecycle, so an unapproved or newly edited template cannot be sent by accident. Versioning them means a template edit never silently rewrites the content of messages already queued.
Messaging product on the WhatsApp Business Platform
Built directly on WhatsApp's official Business Platform rather than on top of a reseller — which meant designing to the platform's real constraints: template approval, quality rating, per-number throughput, opt-in rules.
Officially approved by Meta
Passed Meta's official review — technical integration, policy compliance and business verification. Most products in this space route around that bar by renting access from an intermediary.
WhatsApp Business Platform
Node.js
TypeScript
WebSockets
PostgreSQL
Viella
Building2025
AI-powered personal stylist for closet management & outfit planning
Wardrobe organization and outfit planning traditionally rely on memory, spreadsheets, or tedious manual photo sorting. Viella digitizes inventory from raw images and provides context-aware outfit recommendations via conversational AI, replacing manual styling workflows.
Structured output over open-ended generation
Multimodal models extract structured metadata (color, seasonality, occasion) from clothing photos to build a queryable closet index. To handle model hallucinations gracefully, the LLM outputs strict JSON UI schemas rather than raw text — allowing users to swap misaligned items with a single tap without re-running full generation prompts.
React Native
Expo
TypeScript
Native UI
iOS & Android
Multimodal LLMs
Structured Outputs
Experience
Clinicorp Solutions
Jan 2021 — Present · 5 yrs 9 mos
Full-time · Jaraguá do Sul, Santa Catarina, Brazil · On-site
Product Engineer
Jan 2026 — Present · 9 mos
Spearheading a new mobile product vertical to expand TAM, leveraging AI-assisted engineering workflows to build end-user features.
Engineering Coordinator
Sep 2024 — Dec 2025 · 1 yr 4 mos
Managed Enterprise Applications squads, aligning technical strategy with the CTPO and deploying AI support agents that saved $100k+ in operational costs.
Tech Lead
Mar 2023 — Aug 2024 · 1 yr 6 mos
Led a 4-person squad architecting an in-house billing engine ($200k+ saved in fees) and a Meta-integrated platform handling 30k+ monthly chats.
Developer
Jan 2021 — Mar 2023 · 2 yrs 3 mos
Developed core payment infrastructure, acquirer integrations, and critical internal tooling, resulting in a fast-track promotion to Tech Lead.
WEG
Feb 2019 — Jan 2021 · 2 yrs
Full-time · Jaraguá do Sul, Santa Catarina, Brazil
Electronics Maintenance Apprentice · CentroWEG
Trained in industrial electronics diagnostics, hardware maintenance, and circuit troubleshooting at WEG's technical training center.
