Evig · designed and built from scratch (69% of commits)
WhatsApp messaging gateway in Go
No customer message on WhatsApp could be lost, duplicated or delivered out of order.
900 msg/min · 0% failures · p95 1.05 s
problem
Messages from the CRM and the AI agents had to go out over WhatsApp without duplicates, without losses and in conversation order, even with retries, deploys and several workers in parallel.
decision
Ports & adapters, a PostgreSQL outbox with FOR UPDATE SKIP LOCKED, 3-layer idempotency (webhook receipt, turn dispatch and outbox dispatch) strict ordering per conversation (lane with fencing token) and per recipient in the outbox. 100% coverage gate on every PR; gosec and govulncheck in a nightly job.
result
900 msg/min for 10 min, 0% failures and a p95 of 1.05 s from webhook to reply, in the k6 load test with fixed-delay mocks (200 ms for the AI, 550 ms for Meta): the gateway’s own p95 overhead was 303 ms. 9,901/9,901 delivered over the full run (11 min, including warm-up). It measures the gateway, not WhatsApp end to end.
trade-offs and limits
- Outbox in PostgreSQL itself, no broker yet, behind an interface that allows swapping one in: fewer moving parts, with the database as the bottleneck.
- Load-test ceiling: RDS CPU (70% gate at 20 msg/s; 15 msg/s is the highest confirmed rate, the 15–20 range wasn’t refined), far above the real production peak (41 messages in 5 min).
- One suspect was the status lookup by
provider_message_id, which had no index (Seq Scan in EXPLAIN); a teammate added the index later (migration 015), but no new load run has measured it yet.
- No reaper yet: if a worker dies mid-send, the message stays in
sending and isn’t resent automatically, because there’s no way to know whether Meta already got it. Once its 5-min lease expires, the message merely stops holding back that customer’s next ones. I’d rather resend by hand, after checking with Meta (no written runbook step yet), than risk a duplicate; try it by taking down a worker in the simulation at the top.
- Meta’s rate limit is still handled reactively.
- Go
- PostgreSQL
- Outbox
- k6
- Prometheus
open code: the same pattern rewritten from scratch, reaper included ↗ (opens in a new tab)
Evig · top contributor (48% of commits)
Multi-tenant CRM in Laravel
PHPStan 1,770 → 0 · 2,100+ tests · 197 PRs
In a production CRM shared with other devs, with everything going through pull requests (197 of them mine), I took PHPStan/Larastan from 1,770 errors to zero, wrote 94% of the test files (304 of 322), fixed a cross-tenant IDOR vulnerability and upgraded the project to PHP 8.4 / Laravel 13.
see problem, decision and trade-off
Problem: a multi-tenant CRM in production, with other devs working on it at the same time and no static analysis. When I added Larastan (level 5), 1,770 errors showed up; and a route let one company’s admin edit another company’s employees.
Decision: adopt a baseline so the team wouldn’t be blocked, then clear it gradually, in small PRs with tests; every employee lookup is now scoped to the caller’s company, with a 404 for outside IDs and a regression test per route.
Trade-off: a baseline means living with known errors for a while, in exchange for not stopping delivery.
- PHP 8.4
- Laravel 13
- Larastan
- Pest
- Inertia + Vue 3
open code: tenant isolation and the IDOR regression tests rewritten from scratch, with idempotent reminders ↗ (opens in a new tab)
Evig · infrastructure
Production migration from GCP to AWS
secrets in SSM via OIDC · zero static keys in CI
I ran the move of the production database and instances to RDS and EC2, from planning to execution, with secrets in SSM via OIDC across all projects and observability with Prometheus and Grafana. The incidents that came later are in the log below.
- AWS
- OIDC
- SSM
- Prometheus
- Grafana
Evig · AI agent supervisor
Faster AI router without losing accuracy
120/120 in the eval · p50 −25 to 40% (estimated)
I lowered the reasoning level of the router (the supervisor that picks the agent) from “high” to “low”, for 25% to 40% lower p50 latency (estimate from the commit and the code, no dedicated benchmark). “Low” missed ambiguous configuration requests; I fixed that with contrastive examples in the prompt until it was back to 120/120 (6 cases × 20 runs, to measure stability) and 35/35 on a trap-phrase suite. It’s a small suite: it guards against regressions on these cases but doesn’t prove general accuracy.
Evig · API platform
Modular monolith in FastAPI
100% branch coverage gate in CI
One repository and one quality pipeline for two deployables isolated by import-linter contracts: independent packages and layers that only depend inward. OpenAPI contract locked in CI and connection pool cut from 20 to 8 per replica on the shared database.
- Python
- FastAPI
- PostgreSQL
- OpenAPI
Evig · Open Finance · credit · contributor
AI agents for finance and credit
every number checked against the data, never made up by the model
On a team building agents on top of Brazil’s Open Finance (open banking), my part was: connecting, refreshing and removing banks with confirmation; the smart-budget agent, with deterministic setup and confirmation of every edit; financial grounding in the prompt; LangGraph threads scoped per session; and, in the supervisor, the credit soft-lock and each agent’s boundaries. The router above is that supervisor, picking which agent handles each message.
- Python
- FastAPI
- LangGraph
- Open Finance
Evig · platform copilot · 98% of commits
Multi-tenant RAG copilot
tenant isolation tested · 740 tests
A FastAPI service with conversation memory and RAG over uploaded files: admin documents apply to the whole company, each user’s documents stay private, and a tenant_id in the request body is only used to reject cross-tenant access, with a test for it. Architecture contracts in import-linter and mypy in CI.
- Python
- FastAPI
- RAG
- PostgreSQL
Accusense · freelance project · 63% of commits
News extraction API
−99% collection cost · ~US$ 21k/year (R$ 107k, estimate)
I built a generic 5-layer extraction engine from scratch in Laravel 12 and MongoDB (no per-site selectors), with feed discovery, deduplication, a queue pipeline and retries with backoff. It replaced the manual collection done by 3 operators (about R$ 3k, ~US$ 600, a month each), who moved to other roles, and costs ~US$ 15/month to run on AWS, and it has collected ~25k articles from 300+ sites. 120+ tests on the engine.
- Laravel 12
- MongoDB
- Queues
- PHPUnit
Digital LZ · WhatsApp debt collection
Debt-collection bots and self-service settlement portal
8 operators freed · ~US$ 48k/year (R$ 240k, estimate)
About 100 Node/TS + Prisma bots on SQL Server, sending up to 20k messages a day, took over the message sending that 8 operators (~R$ 2.5k, ~US$ 500, a month each) used to do by hand; they moved to other roles. Retries with backoff, business-hours windows and rate control; a dashboard that starts and stops the containers over SSH on the 2 servers; a self-service debt-settlement portal in Laravel with login by CPF (taxpayer ID) and two-step verification over WhatsApp, which closes ~100 settlements a month with no operator.
- Node.js
- TypeScript
- Laravel
- Docker