The problem
Clinics and healthcare professionals in Brazil still run on a stack that has not moved in a decade: scheduling over the phone, records on paper, and, when a procedure splits revenue between the clinic and the professional, reconciliation by hand. Sense is the SaaS we are building at Forge Labs to cover that flow end to end, serving both the clinic’s operation and the professional who works in it.
It is Forge Labs’ flagship, and I lead the engineering: architecture, stack choices, code review, sprint cadence, and the team’s technical onboarding.
Architecture
A single Next.js 16 application (App Router) with React 19 over PostgreSQL through Prisma 7. Authentication runs on Better Auth, with the role hierarchy SUPER_ADMIN > ADMIN > CLINIC_MANAGER > PROFESSIONAL > PATIENT. Files, such as attachments and profile media, live in S3-compatible storage, using MinIO in development.
The code follows a layered rule that is taken seriously:
UI Components → Hooks → Services → Repositories → Database (Prisma)Components and hooks never import the Prisma client. Services never skip the repositories. API routes and server actions are thin: they validate input with Zod schemas, delegate to a service, and respond through typed helpers (apiSuccess, apiList, apiError). The result is that all data-access logic sits in one place, and per-clinic scoping lives in the repository layer rather than scattered across the screens.
The clinic is the central unit of the model. Professionals and patients relate to clinics, and a single patient can belong to more than one. The UI components are an internal library, Coss UI, built on Base UI and Tailwind 4, treated as untouchable to keep visual consistency without rewriting primitives.
One decision runs through the entire system: every monetary value is an integer, in cents. finalValueInCents = transferValueInCents + commissionValueInCents. No float anywhere near money.
The scheduling
The heart of the product is the agenda, and it is the most complete part. It has day, week, and month views, and each appointment goes through a state machine: PENDING → PAYMENT_CONFIRMED → COMPLETED, with branches into CANCELLED, NO_SHOW, RESCHEDULED, and EXPIRED.
Availability is configured per weekday, with blocks for vacations and holidays, and the system refuses scheduling conflicts at booking time. An appointment keeps an immutable snapshot of its services at the moment it was created, so changing a service’s price later does not rewrite history. There are also visit types (in person, online, and home visit), return appointments chained to the original, and PDF guide generation.
The lesson I carry from this: in healthcare scheduling, the hard part is not drawing the calendar, it is modeling the exceptions (blocks, reschedules, returns, no-shows) without letting them contradict each other. The immutable service snapshot is what kept the financial report and the clinical history from drifting apart over time.
Money: split and payout
Each appointment generates a payment with the full amount split between what the professional receives and the platform’s commission, always in cents. The installment rules are explicit: only credit card can be split, up to four times, and a single payment has no installments. Refunds are tracked with amount, reason, and date.
At the end of the month, the payout consolidates each professional’s confirmed payments into a single transfer, with their own receiving details (PIX or bank account) and a status flow of its own. This split and payout calculation runs entirely inside the system. Integrating an external gateway, to actually settle the transfer, is the next step, and the gateway fields are already modeled to receive that stage without a rewrite.
Being honest about maturity: the money accounting is real and works; what is not yet wired in is the external provider that actually moves the money.
A public API for an AI agent
A recent addition is a versioned public API at /api/v1, authenticated by API key and described in OpenAPI, meant for an AI agent to consume: search professionals, create and reschedule appointments, list patients. Documenting the contract in OpenAPI from the start is what made it viable to expose this safely, instead of an improvised endpoint.
Where it stands
In production, in daily use. Today 4 clinics and 37 professionals run their routine inside the system: scheduling, patients, the payout finances, and public professional profiles with search by specialty and date. The foundational decisions, like the clinic-oriented model, the layered separation, and money in cents, were made to keep the cost of reaching the tenth and the hundredth clinic linear. The step still missing to close the revenue loop is integrating the payment gateway, but the operation already runs on this foundation every day.