Case study

Zuppy

Automated invoice issuance for infoproducers: connects marketplaces and payment gateways, with pay-per-note pricing, compliance, and a lightweight workflow instead of a heavy accounting stack.

Introduction

Zuppy is a SaaS for Brazilian infoproducers and digital sellers: it automates NF (nota fiscal) issuance, syncs sales from marketplaces and payment gateways, and keeps pricing transparent with a per-invoice model.

Webhook ingestion from multiple payment providers and marketplaces
Automated fiscal payload generation and emission workflows
Dashboards and reporting for issued notes and billing
Cron-based sale processing and fiscal batch jobs
Integrations with major Brazilian checkout and marketplace stacks

Role — I am the only developer owning the system end to end—backend, integrations, and front end—while a designer produces Figma files that I translate into the live product. I implement new screens and iterations from those specs, keep the existing design system consistent, and handle maintenance and refactors on a codebase that predates me.

Technologies — Next.js, TypeScript, tRPC, Prisma, NextAuth.js, Tailwind CSS, Vercel — Hosted on Vercel; Postgres via Prisma.

Purpose and Goal

The product exists to remove friction between selling online and staying compliant with fiscal rules—without forcing teams into a full ERP.

For me, the goal is to keep production stable while modernizing the core path: money in from webhooks → correct business rules → valid NF payloads. The expected outcome is fewer production incidents, faster debugging, and tests that protect the refactors.

Early planning was discovery-heavy: map each provider’s webhook shape, trace how a sale becomes an NF, and identify where crons could fail silently. That narrative drove what to log, what to test first, and what to isolate in services.

Spotlight

The spine of Zuppy is the path from provider webhooks to fiscal payloads—normalize events, persist state, and emit notes with split and coproducer rules—which is exactly where the product lives or breaks. The tension was legacy flow meeting new providers, crons that could fail or double-run, and logs that did not always point to a single sale. I addressed it by carving that pipeline into small, typed steps with tests on parsers and builders, Prisma transactions where consistency matters, and correlation IDs so a failing cron becomes a traceable story instead of a midnight guess—always in small, reversible slices because users are on the system every day.

Lessons Learned

Production SaaS refactors need a map of data flow before touching code—especially with fiscal rules.
Investing in logs and correlation IDs pays off faster than ad-hoc debugging in cron-heavy systems.
Tests around webhook parsing and payload builders reduce fear when onboarding new providers.
Being the only dev means balancing speed with operational safety—documentation is part of the feature.