UI Design Web App Dev

Monitora.ai

Incident monitoring platform for autonomous markets — from a 100% manual process to a system serving 10 operators across more than 80 units.

Client
Autonomous Market
Year
2025 — 2026
Role
UI Design · Front-end · Dev
Stack
React · Firebase · Vercel
Monitora
Dashboard
Incidents
Users
Billing
Reports
Stores
Open incidents
● Live
84
Active stores
12
Open
8min
Avg. time
94%
Resolution
User
Store / Date
Type
Status
Carlos M.
Store 07 · today
Theft
Open
Ana P.
Store 23 · today
Partial payment
Open
João R.
Store 41 · yesterday
Theft
Resolved
Mariana S.
Store 58 · yesterday
Recurrence
Blocked
Pedro L.
Store 12 · 2d ago
Partial payment
Resolved
73%
Reduction in incident management time
From 30 min → 8 min per case
80+
Stores monitored simultaneously
By a team of 10 operators
0→1
From zero to a working product in production
Full design + development

01 — Context

A very human
bottleneck

Autonomous markets operate with open access — the customer walks in, picks products, and pays. But when something goes wrong — an incomplete payment, a theft, a repeat offense — someone needs to log it, investigate, and act.

All of that responsibility fell on a single person. They received the alerts, checked the spreadsheets, looked up the user's data, drafted the message, waited for a response, and updated the record. All manually, all in sequence, all dependent on their availability.

With more than 80 active stores, this model was at its limit. Any absence became a crisis. Any increase in volume ground the entire process to a halt.

Before
Manual process
Decentralized spreadsheets per store
One person as single point of control
~30 minutes per incident
Messages drafted manually case by case
No centralized recurrence history
Block decisions made without clear data
After
With Monitora.ai
Centralized real-time dashboard
Team of 10 distributed operators
~8 minutes per incident
Billing generated automatically
Complete history per user
One-click block + clear criteria

02 — Process

Design and code
as one thing

Being a 0-to-1 project — no prior product, no design system, no internal reference — the process was built in layers: first understand the real workflow, then design, then build.

01
Real workflow mapping
Before opening Figma, understand how the process actually worked in practice. What were the steps, where were the bottlenecks, which information was critical for decision-making, and what could be automated.
ResearchFlow
02
Information architecture
Defining the platform's structure: which data needs to be visible, what is the hierarchy of actions (view → investigate → contact → block), and how to organize an interface for people working under pressure.
IAUXFigma
03
UI Design — dark system
Interface built in dark mode with green as the action color — referencing the monitoring environment and the product's identity. Dense typography, prominent data, clear actions. Every screen designed to reduce clicks and decision time.
UIDesign SystemDark Mode
04
Development — React + Firebase
Full platform implementation: authentication, real-time database, business logic (incident grouping, per-user history, block system), and automatic generation of billing messages.
ReactFirebaseFirestore
05
Deploy + iteration in production
Launch on Vercel with CI/CD via GitHub. The platform went through adjustment cycles with the real team — each iteration guided by the operators' daily use.
VercelGitHubIteration

03 — Stack

Technologies
and decisions

Every technical choice was guided by one premise: delivery speed without sacrificing scalability. A lean, well-known stack with managed infrastructure.

React
Interface — reusable components and reactive state
Firebase Auth
Secure authentication with role-based access control
Firestore
Real-time database — always up-to-date dashboard
Figma
Design system, prototypes, and handoff
Vercel
Continuous deployment with CI/CD via GitHub
Google Drive
Integration with the client's existing database

04 — Product

What the
platform does

📋
Incident logging
Structured registration by type — theft, partial payment, recurrence — with standardized fields and automatic per-user history.
👤
User profile
Complete record per customer: incident history, block status, contact details, and a timeline of previous interactions.
✉️
Automated billing
Billing messages generated automatically with the incident data — the operator reviews and sends in one click, without writing anything from scratch.
🔒
Block and unblock
Store access block system with clear criteria and full traceability — who blocked, when, and for what reason.
📊
Real-time dashboard
Consolidated view of all stores and open incidents — the entire team sees the same operational state without relying on manual handoffs.
🏪
Multi-store management
Structure built for scale — each incident is linked to a unit, enabling per-store filters and an aggregated network view.
monitora.ai/ocorrencias

Screenshot — Incidents screen

05 — Impact

The before and
after in numbers

✕ Before: 30 minutes per incident
✓ After: 8 minutes per incident
73% reduction in management time
✕ Before: 1 overloaded person
✓ After: team of 10 operators
Real distribution of workload
✕ Before: decentralized spreadsheets
✓ After: single real-time dashboard
Decisions based on data, not memory
✕ Before: billing written by hand
✓ After: generated automatically
Consistency and speed in customer contact

Deliverables

Complete design system in Figma (dark mode)
Responsive web platform in React
Authentication and role-based access control
Real-time database (Firestore)
Automatic billing message generation system
Production deployment with CI/CD via GitHub + Vercel

06 — Learnings

What this project
taught me

The real problem is rarely the stated problem. The client thought they needed a better spreadsheet. What they actually needed was to eliminate the dependency on a single person — which is an architecture question, not a format question.

Designing under pressure is a design skill. Interfaces for operators in high-stress situations demand radical visual hierarchy — what matters right now needs to appear right now, without friction.

Design and development together accelerate everything. Handling both ends of the project eliminated handoff noise and allowed real-time adjustments — the interface evolved because I knew the true cost of every change.

A product in production is different from a product in Figma. The most valuable iterations came from real usage. What seemed obvious in the prototype was sometimes invisible in practice — and vice versa.

Next project → Fitto