Valter Nunez

What it is

Nexus is a multi-tenant SaaS platform for condominium and real-estate administration — a FastAPI backend with a Next.js admin dashboard and a resident PWA — in active development and onboarding its first tenants. A hierarchical adjacency-list node model maps any physical layout (vertical towers through sprawling neighborhoods), and a per-condo RBAC + add-on system gates features per tenant.

Why it’s interesting

It’s the full stack of a serious product, built and documented by one person:

• Finance engine: ledgers, charges, payments, recurring billing, late fees, credit balances, delinquency reporting, and a transparency report, with Celery doing the heavy lifting.
• Payments: Stripe Connect (Express, direct charges), SPEI/CLABE, saved cards, auto-pay with explicit consent and audit, disputes, and payout reconciliation.
• Platform depth: Redis read-through caching with targeted invalidation, a storage abstraction (local disk ↔ S3 with presigned URLs), audit-grade action trails, scoped API keys, WhatsApp integration, a PWA, and scheduled notifications across in-app, email, web-push, and mobile.
• LLM integration: an “Improve with AI” assist wired to a real LLM (Google Gemini), with the controls a production feature needs: usage metering, daily request/token limits, alert thresholds, a fallback model, graceful degradation, and schema-enforced structured output.
• Engineering discipline: async tests with isolated DB rollbacks, and a docs-as-code hub with per-module references and architecture decision logs.

How it was built

One person, small-team scope, through leverage. I built Nexus with an orchestrated multi-agent development workflow: a set of specialist Claude Code agents (implement, review, and nine read-only auditors for security, data integrity, performance, and the rest), running in parallel across isolated git worktrees and handing work off via API contracts and diffs. I’m the human-in-the-loop architect; the agents are the leverage. Same instinct as the rest of my work: design the system, instrument it, and let the tooling handle the repetitive part.

What it shows

End-to-end ownership of a hard domain, solo: system design, a payments stack that moves real money (double-entry ledgers, Stripe Connect), multi-tenant security, and the tests and docs to back it.

The problem

Sales (online and in-store) were tightly coupled to the ERP. When the ERP stalled, revenue stalled with it. Sales needed to keep flowing while the ERP recovered, without double-selling inventory or dropping orders.

The approach

I co-designed OZ (Off-ZeCore) with the team: an event-driven platform that mirrors the data sales actually need and absorbs writes while the ERP is unavailable.

• Clear contracts. APIs, schemas, and event queues defined so each service can fail on its own. Orders and stock movements became events instead of synchronous ERP calls.
• Buffer, then reconcile. Redis and RabbitMQ hold and route work during an outage; the system reconciles cleanly when the ERP comes back.
• Observable by default. Grafana dashboards on queue depth, lag, and error rates make a degraded state something you can read rather than something you discover.

The result

83% of revenue-critical sales flows were decoupled from synchronous ERP calls. Failure-mode analysis projects a 91% reduction in sales-blocking downtime. Sales carry on through ERP incidents that used to stop them.

In production, OZ now backs in-store sales across ~195 stores in Mexico (full rollout), with a Brazil rollout underway. During the 2026 Hot Sale it carried ~MX$102M (≈ $5M USD) in sales over nine days, a major retail peak that ran ~16% ahead of the prior year. (Proprietary system; architecture described, no source shared.)

The problem

Each carrier (FedEx, DHL, and others) had its own API, pricing, and quirks. Integrations were duplicated, and shipments weren’t consistently routed to the cheapest option.

The approach

I co-designed and built the carrier middleware: every carrier behind one contract, with cost a first-class routing decision.

• One interface over all carrier data and operations, so nothing else in the platform ever talks to a raw carrier API.
• Cost optimization at dispatch: each shipment is rated across carriers and routed to the cheapest one that meets the constraints.

The result

Total shipping spend fell ~78% (≈ $500K USD/year in direct savings), and the per-carrier integration sprawl went with it. (Proprietary system; architecture described, no source shared.)