What we have builtfor governments and companies.

Asking for a public service usually costs a trip to the counter, a queue and a phone call later to find out where the request stands. Ágil Cidadão puts that whole path on screen.

For the citizen

The citizen logs in, picks the service from the catalogue and sees, before starting, what to bring, which fields to fill in and how many days the answer usually takes.

They upload the documents from the phone, book the in person appointment when the service requires it and follow the request by its protocol number. Every change of stage shows up on their screen, so nobody has to call to ask how it is going.

At the counter

The attendant starts the day with two screens: the request queue and the calendar. They open the case, read the full history of the request and answer right there.

When a citizen arrives without an account, the attendant opens the request for them. Every move is recorded with author, date, message and attachment, and the history ends up telling on its own what happened to the request.

In management

Each service is built by the team itself: the fields the form asks for, the required documents, the estimated deadline and whether it is open to the public. Creating a new service does not depend on us.

Management sets by role who sees each service, follows the activity trail and reads the rating the citizen gave at the end of the service, by service and by attendant.

Product screens with demonstration data.

What we delivered

• Service catalog with the rules, required documents and fields specific to each service
• Online requests with a protocol number, status tracking and a history of every update
• Appointment booking, with a schedule per staff member
• Staff dashboard with the request queue, the day's schedule and the detail of each case
• Management area for services, users, permission roles and the activity trail
• Sign-up with email account verification and password recovery
• Satisfaction survey at the end of each service, with indicators for management
• Document upload by the citizen, kept in cloud storage

Back end: NestJS and TypeScript, PostgreSQL with TypeORM, hexagonal architecture, JWT authentication with access roles, API documented in Swagger and delivery on Docker.

Front end: React with Vite and TypeScript, Tailwind CSS, accessible Radix UI components, forms with React Hook Form and Zod, indicators in Recharts.

The management of an urgent care unit had no way to see, in real time, where staff were or how long they spent in each room.

On the badge and in the room

Each professional wears a badge with a Bluetooth beacon. Each room has a reader that listens for those badges every few seconds and sends the reading to the server.

The raw reading is not enough: the signal goes through walls and the next room steals the record. The system filters by signal strength and only counts presence when the readings hold, so what gets stored is a real entry, stay and exit.

In the unit's management

Management then sees what it could not see before: who is in each room right now, how long each professional spent in each room and the history to compare days, shifts and rosters.

Those numbers come out through a signed API and feed the dashboards the unit already uses in the cloud, instead of forcing the team to open one more system mid-shift.

What we delivered

• Badges with a Bluetooth beacon and one reader per room, read by the system every few seconds
• Entry, stay and exit logged for each professional in each room
• Signal-strength filtering, so the room next door does not steal the reading
• Real time presence and history by professional and by room, delivered through a signed API
• Rooms, readers and badges registered by the team itself

Back end: NestJS and TypeScript, PostgreSQL, gateway readings over MQTT, presence inferred from signal strength and a signed API for the dashboards.

The off-the-shelf system used by the unit could not keep up with the operation: the integration with Brazil's National Health Card kept failing, triage priority did not reach the doctors, medical records could not be used concurrently and reports for the city ended up in spreadsheets.

At the front desk

Care starts at registration: the front desk looks the patient up by name, national health card or tax ID, checks the national database and registers on the spot anyone not yet on file.

From there come the patient label and the day's queue, showing who arrived, how long each person has waited and which stage their care is in.

In triage

Nursing opens the record of whoever is waiting to be triaged and enters blood pressure, heart and breathing rates, temperature, oxygen saturation, blood sugar, pain, Glasgow scale, main complaint, allergies and current medication.

On closing the record, the nurse picks the risk colour. From then on the colour follows the patient through the queue and the consultation, next to legal priorities such as older adults, pregnant women and infants.

In the consulting room

The doctor opens the patient and sees, on the same screen, everything triage recorded, including the complaint the patient arrived with and the time the readings were taken.

He writes the clinical note, enters the diagnosis codes and signs it. A signed note can no longer be edited: a correction becomes a new note tied to the previous one. Prescriptions come out of the same consultation, and dispensing talks to the unit's stock.

In the waiting room and in management

The call shows up on the waiting room display with the patient's name and the room to go to, alongside earlier calls, for anyone who missed it the first time.

Management pulls the period's reports on screen: case profile by risk, outcome, professional or time of day, daily bulletin, average time and notifiable conditions. What used to end up in a spreadsheet comes out ready.

Product screens with demonstration data.

What we are delivering

• Patient reception and registration integrated with CAD-SUS and the National Health Card
• Triage and a queue ordered by clinical priority, with a call display
• Medical care and electronic health records with concurrent use
• Prescriptions, pharmacy and inventory
• Reports, indicators and mandatory disease notifications
• Access profiles, audit trail and LGPD compliance

Back end: Node with Fastify and TypeScript, PostgreSQL with Drizzle, Argon2id password hashing, JWT sessions, permissions checked on every request and an append-only audit trail.

Front end: React with Vite and TypeScript, TanStack Router, Query and Table, Tailwind CSS and shared Zod contracts across both ends.