UI Design Front-end Web App Engineering

MonitoraAi

A loss-management platform for autonomous micromarkets. Built in February to automate one person's billing routine, adopted by the entire operations team by June — audit, monitoring, billing and legal escalation, end to end.

Role
Design, front-end & product
Timeline
Feb — ongoing, 2026
Stack
React · Firebase · Vercel
Status
In production, full team
ocorrencias-db.vercel.app/billing
Billing queue
Today · 7 open
3 overdue
M. SantosR$ 47,90PENDING
J. FerreiraR$ 112,40CONTACT 1
A. LimaR$ 23,50INVOICE SENT
F. CostaR$ 312,00OVERDUE
R. AlmeidaR$ 31,80PAID
T. MoreiraR$ 88,60LEGAL
68%
Recovered
214
Open
12
Legal
Generated message
Hi {{name}}, we identified a pending payment of {{amount}} at store {{store}} on {{date}}. You can settle it via the link below.
VALIDATE & SEND
MonitoraAi — Billing queue

It started with a complaint at home: "I don't even know what I have to do today, who do I have to charge? Who do I still need to answer? Who am I forgetting?" Answering it by hand took hours, every day.

— The complaint that became MonitoraAi

01 — Origin

One billing routine
that became a system

The problem

My partner handles debt recovery for Quadrado Express, a chain of autonomous micromarkets. The routine was fully manual: no predictability of the day's workload, no visibility of each customer's stage in the dunning ladder, and every message composed by hand, prone to error.

The bet

Instead of organizing the manual process, replace it. A system that knows every occurrence, tracks its stage automatically, calculates amounts, and assembles the outreach message — so the human only validates and sends. One user, one workflow, built to be extended.

02 — Evolution

Four months, four expansions

Every phase came from real feedback, not a roadmap. Select a phase to see what was built and how the interface worked at that point.

February 2026 — MVP

One user, one job: predictable billing

The first version answered the original question. A billing queue showing every open occurrence and its stage on the dunning ladder, automatic value calculation from registered products, and message assembly with variable interpolation — name, amount, store, due date — ready to validate and fire via WhatsApp.

Billing queue + status ladder Auto message assembly Value calculation WhatsApp handoff Google Sheets sync
ocorrencias-db.vercel.app/billing
Billing queue
Today · 7 open
3 pending
M. SantosR$ 47,90PENDING
J. FerreiraR$ 112,40CONTACT 1
A. LimaR$ 23,50INVOICE SENT
Generated message
Hi {{name}}, we identified a pending payment of {{amount}} at store {{store}} on {{date}}. You can settle it via the link below.
VALIDATE & SEND
March 2026 — Expansion

Upstream: where occurrences are born

Feedback pulled the system upstream. A monitoring screen for registering occurrences — theft, partial payment, repeat offenders — with structured types, silent user lookup by CPF with auto-fill, deduplication keys, and an automatic history per customer. The system now recognized a returning user and surfaced their full record.

Occurrence registration Typed records User lookup + auto-fill Per-user history Deduplication Role-based access
ocorrencias-db.vercel.app/monitoring
New occurrence
Monitoring · store 23
live
CPF  083.•••.•••-12 — match found
Name  R. Almeida (auto-filled)
Type  Partial payment
Products  2 items · R$ 31,80
Customer history
Occurrence #114Apr 12PAID
Occurrence #089Mar 02PAID
REGISTER OCCURRENCE
April — May 2026 — Maturity

Closing the loop, hardening the product

The legal stage entered the flow — when billing fails, the case escalates with its full history attached. The same period hardened the product: a KPI dashboard reading totals straight from Firestore, a design system with light/dark theming via CSS variables, modals rebuilt with React Portals, occurrence grouping for unified billing with independent installment tracking, and an admin-editable message template engine.

Legal escalation KPI dashboard Theming system React Portals Occurrence grouping Template engine
ocorrencias-db.vercel.app/dashboard
Dashboard
All stores · May
DARK / LIGHT
214
Open
68%
Recovered
12
Legal
Recovery by week
Group #12 — 3 occurrences2/4 installmentsAGREEMENT
F. Costa — escalatedR$ 312,00LEGAL
June 2026 — Adoption

From our tool to the company's system

We presented the platform to Quadrado Express. They adopted it — and the requirements became theirs. The biggest addition: an audit module that reviews every store, surfaces product discrepancies, and dispatches monitoring to watch flagged stores. What began as one contractor's workflow now runs the loss-management operation end to end.

Audit module Store discrepancy view Monitoring dispatch Team-wide rollout Full operational loop
ocorrencias-db.vercel.app/audit
Store audit
Cycle 06 · 68 stores
4 flagged
StoreExpectedCountedΔ
#23 — Centro412398−14
#41 — Pituba287286−1
#07 — Barra351339−12
Discrepancy above threshold at store #23. Monitoring dispatched to review footage and register occurrences.
DISPATCH MONITORING

03 — The operation

One loop, four teams

The platform connects four roles into a single loss-management cycle. Select a stage to see what happens inside it.

STAGE 01

Audit

Every store is reviewed per cycle. Product discrepancies surface automatically.

  • Expected vs counted per store
  • Threshold-based flagging
  • Dispatches monitoring
STAGE 02

Monitoring

Flagged stores get watched. Each incident becomes a structured occurrence.

  • Typed occurrence registration
  • User lookup & history
  • Deduplication on entry
STAGE 03

Billing

Occurrences enter the dunning ladder. Messages are assembled, values calculated.

  • Six-stage dunning ladder
  • Template-driven outreach
  • Grouping & installments
STAGE 04

Legal

If recovery fails, the case escalates with its complete history attached.

  • Full occurrence log
  • Customer record & blocks
  • Resolution tracking

The dunning ladder

Status flow · hover each step
PENDING
CONTACT 1
CONTACT 2
INVOICE NOTICE
INVOICE ISSUED
OVERDUE
PAID / LEGAL
Each occurrence moves through six stages before resolution. Every transition is logged.

04 — Architecture

Built to be extended

A lean, managed stack that survived four expansions without a rewrite. Select a module to zoom into how it works.

FRONT-ENDCLOSE ×

React + Vite

Page-per-role architecture with shared component patterns and a CSS-variable design system.

src/
  pages/ — Monitoring · Billing · Dashboard · Audit · Admin
  contexts/ — AuthContext · ThemeContext
  components/ — ModalBase · BadgeStatus · Portal
  services/ — firebase · groups · templates

Pattern: modals render via React Portals at document.body —
solving stacking and blur issues inside scroll containers.
AUTH & ACCESSCLOSE ×

Firebase Auth

Role-based access mapping four profiles to the pages each team actually needs.

admin → monitoring · billing · dashboard · audit · admin
manager → billing · dashboard · audit
monitoring → monitoring · dashboard
billing → billing · dashboard

Routing is derived from the profile at login —
each team lands only on its own surface.
DATACLOSE ×

Firestore

Real-time collections mirroring the operation: occurrences, users, collaborators, groups.

occurrences — status · log[] · dedupKey · value · products
users — cpf · contacts · blocked · blockLog[]
collaborators — role · page permissions
groups — linked occurrences · type · installments[]

KPIs query aggregate totals directly — never derived
from the paginated 50-record lazy load.
AUTOMATIONCLOSE ×

Cloud Functions + Apps Script

Email dispatch and two-way sync with the company's existing Google Sheets base.

Sync challenge: service-account writes hit a persistent 403.
Pivot: dedicated Firebase Auth sync user — Apps Script
authenticates as a first-class user and reads/writes Firestore.

Legacy spreadsheet stays alive during transition —
no forced migration for the operations team.
Sheets
Apps Script
Firestore
UI
MESSAGINGCLOSE ×

Template engine

Six dunning templates with variable interpolation, editable by admins with live preview.

{{name}} · {{amount}} · {{store}} · {{products}} · {{dueDate}} · {{invoiceLink}}

contact1_default · contact1_partial · contact2
invoice_notice · invoice_issued · invoice_overdue

Same body feeds WhatsApp and email — email adds
the template's subject field. Stored in Firestore, hot-editable.
DELIVERYCLOSE ×

Vercel + GitHub

Continuous deployment — every merge ships. The team is always on the latest version.

git push → build → preview URL → production

Feedback loop measured in hours: the team reports in
the morning, the fix is live in the afternoon. This cadence
is what turned users into product collaborators.
VS Code
GitHub
Vercel
Team

05 — Engineering notes

Decisions that mattered

Identity without bureaucracy

The "identified" criterion was simplified to a real name plus any contact — dropping the CPF requirement. A reclassification routine updated every existing record. Unidentified occurrences each get a unique user document, fixing a grouping bug where blank IDs collided.

Truthful KPIs

Dashboard numbers query Firestore aggregates directly instead of summing the paginated list. The lazy load shows 50 records; the KPIs always reflect all of them. Small decision, real trust — the manager's numbers match reality.

Grouping as a billing primitive

Multiple occurrences from the same customer collapse into one group — invoice, agreement, or debt confession — with independently tracked installments. Settling the final installment resolves every linked occurrence automatically.

Theming as a system, not a skin

Light/dark mode is a CSS-variable layer with a single context toggle. Status colors, surfaces and shadows are tokens — the same components render both themes with zero conditional styling in JSX.

06 — Impact

From one PJ workflow to the
company's operating loop

0
Teams running on the platform — audit, monitoring, billing, legal
0
Stores covered by the audit and monitoring cycle
0
Dunning stages automated with logged transitions
0
Months from first commit to full-team adoption

07 — Continuous evolution

Where it goes from here

The platform ships weekly. The current engineering track moves it from a hardened internal product toward a multi-tenant SaaS.

In progress

TypeScript migration — typing the domain model first: occurrences, ladder statuses, groups.

In progress

Test coverage — Vitest + React Testing Library on the billing-critical paths.

Planned

CI/CD gates — GitHub Actions running lint, types and tests before every deploy.

Planned

PostgreSQL + Prisma — relational layer for reporting and multi-tenant data isolation.

Exploring

Multi-tenancy — the audit-to-legal loop generalizes to any autonomous retail operation.

Next → Galeria Carbono