Mauricio Zaffari

Looper Insights is a global SaaS analytics platform for studios and streaming services. I was there across three stints: full-stack developer in 2018, senior developer from 2020, and tech lead from March 2022 until September 2026. I finished as the top all-time contributor to the core codebase, which serves Disney, Warner Bros, Sony and NBCUniversal and accounts for 55% of company revenue. I led the Webstores 2.0 replatforming and the company-wide authentication migration to AWS Cognito.

Inscripto is a multi-tenant sports event management and signup platform I built and still run as its only person — product, architecture, engineering and operations end to end — replacing paper signups and manual payments for karting and tennis leagues. It has handled 109 events, 3,603 charges and more than R$ 482,800 in online payments. The stack is Rails 8, PostgreSQL, Hotwire, Tailwind and a PWA frontend, with Stripe, MercadoPago and PIX for payments, and it uses the Gemini API to parse unstructured WhatsApp match results into live leaderboards.

I founded Develoz in 2013. For thirteen years it has built software, integrated systems and automated processes for operations in Brazil and abroad. It now works on applied AI — finding where AI is worth using in a process, building the integration pilot, and defining the governance and human review around it. Earlier clients include ArtistSignal, New York Water Taxi and Explica Fácil.

Problem

The company wanted AI features in the client-facing product, and had six engineers it trusted to figure out where AI actually pays for itself. Inside engineering, AI coding assistants were already changing how people worked, with no shared standards: every engineer invented their own workflow.

Approach

I was one of the six in the company’s AI pilot, and I took the two halves of the problem — how we build with AI, and what we ship with AI.

For the first half, I authored the team’s AGENTS.md workflow standard and shared it across the organisation, so assistant-driven development went from personal habits to a documented, reviewable way of working. I published model evaluations that informed the organisation’s tool choice.

For the second half, I was delivery lead for the AI initiative on the core product: client-facing AI pages including one authenticated through a studio’s own single sign-on, and the multi-tenant data-security architecture that lets an LLM chat feature answer from one client’s data without another client’s data ever being in reach. That isolation was designed before the feature was green-lit, not retrofitted after.

Outcome

Standards adopted organisation-wide; AI pages live in front of clients whose names everyone recognises; a chat architecture whose security model was reviewed before it shipped.

Problem

Amazon US merchandising imports took around 46 minutes. Client deliveries queued behind them, so a single slow import delayed the reports people were actually waiting for. The volume was the hard part: roughly 273,000 title spots per scan, against 12.5 to 13 million titles processed weekly.

Approach

The bottleneck was not the fetching, it was the write path — every row was paying for durability and index maintenance it did not need while still in flight. I moved the intake into UNLOGGED PostgreSQL staging tables, so in-progress rows skip write-ahead logging entirely, then promoted them into the real tables once complete. Alongside that I parallelised the fetch stage and streamed results through Redis instead of accumulating them in process memory.

The staging tables are safe here specifically because the data is reconstructible: an UNLOGGED table does not survive a crash, and that is an acceptable trade when the recovery action is to re-run the import.

Outcome

46 minutes down to about 16 — a 65% reduction, confirmed independently by a colleague measuring the same pipeline. Client deliveries stopped queueing behind the import window.

Problem

The main scan page took over four minutes to load. For one client it was worse: ten to fifteen minutes, which is long enough that people stop using the feature and ask someone else to send them a spreadsheet instead.

Approach

There was no single cause, which is the interesting part. Five separate things compounded: a COUNT DISTINCT fanning out over a join, a scope that scanned the whole table rather than the current request’s slice, a sequential scan over 16.7 million rows, a join against a table of roughly 1.5 billion rows, and a missing cache on an expensive grouped aggregate.

I fixed them one at a time and measured after each, because compounding causes mask each other — fix the second-worst first and the improvement looks negligible, which tempts you into concluding it was not the problem. Two of the five needed denormalisation rather than query tuning: a boolean carried onto the row that needed it, so the billion-row join disappeared, and a cached JSONB aggregate refreshed by a dedicated worker instead of computed per request.

For the worst-affected client the fix was narrower and shipped the same day: an existence check that had been doing linear work became an O(1) lookup.

Outcome

Four minutes to under a second. The client-specific path went from ten to fifteen minutes to effectively instant, delivered as a same-day hotfix. A related filter on the same page went from 322 seconds cold to 25.5 seconds by anchoring an unscoped subquery so it could use an index that already existed.

I later made the whole class of regression fail loudly, enabling strict_loading across the test suite so an accidental N+1 breaks CI instead of quietly reaching production.

Problem

The core product had accumulated the usual decade of decisions: a React frontend embedded inside the Rails monolith, so the two could not be deployed or tested independently, and a large share of the codebase predating the patterns the team had since settled on. Rewriting it wholesale was not an option — it serves Disney, Warner Bros, Sony and NBCUniversal, and it earns 55% of company revenue.

Approach

I led the replatforming as a sequence of shippable steps rather than a branch that lived for six months. Over 261 commits across 844 files I rewrote more than 20% of a roughly 244,000-line codebase, raising test coverage as I went because the tests were what made the next step safe.

Separately I extracted the frontend — about 138,759 lines of React — out of the monolith into its own repository, which let the frontend and backend be built, tested and deployed on their own cadences.

Outcome

Shipped incrementally, with test coverage moving from 72% to 80% across the effort and continuing to climb afterwards. The product manager described the result as a transformational release. The frontend extraction is what made subsequent frontend work independent of backend release cycles.

Problem

Releases were manual and tribal: whoever knew the steps ran them, and the steps lived in someone’s head. The product serves Disney, Warner Bros, Sony and NBCUniversal, so a bad release is not an internal inconvenience — it is a client-visible incident. Two repositories became three as the frontend was extracted, which tripled the ceremony.

Approach

I ran the release train end to end across the three repositories: a biweekly code freeze I instituted, QA gating, production deploys, hotfixes, and a rollback plan for every release. Then I turned the parts a machine can do into a machine doing them: an automated release workflow that builds, runs the quality gates, deploys and health-checks. The gate is nine linters plus the Cypress end-to-end suite wired into deploys and pull-request merges, so the checks that used to depend on a person remembering are now the pipeline refusing to continue. The test-plan and rollback-checklist templates I wrote became the ones PM and QA reproduced for every release after.

For one stretch I was also release manager for a frontend codebase I did not otherwise develop, because running the train is a skill apart from writing the code it ships.

Outcome

Sixty-plus releases and hotfixes shipped across four product naming eras without the release process itself as the bottleneck. Releases paused while I was on holiday — the strongest evidence I can offer both that the process worked and that I had not yet finished making it replace me.

Problem

Authentication was homegrown, and enterprise clients were starting to ask for things homegrown auth is bad at: federated identity, their own single sign-on, and token handling we could point at during a security review.

Approach

I led the company-wide migration to AWS Cognito over roughly two months: OIDC integration, bearer-token verification, refresh handling, and sessions kept in Redis with database persistence so a restart did not sign everyone out.

The part that takes the care is not the new system, it is the transition. Every existing user had to keep working throughout, which meant running both paths against real traffic before the legacy code could be deleted — and then actually deleting it, rather than leaving a dead branch to confuse the next reader.

Outcome

One managed identity provider for the whole platform, with client SSO becoming a configuration exercise rather than an engineering project. I later built client-facing pages authenticated through a studio’s own single sign-on on top of it.