Loading…
FDE take-home · Submission
Meridian Receivables Portal & Console
Meridian Insurance Brokers' corporate clients see what they owe across all their companies, and resolve each installment with Meridian in one place instead of long email threads. Meridian's team keeps working from its weekly spreadsheet and gets one email a day with what needs attention.
Walkthrough
Client portal · Team console · Decisions
The case
Nobody had a current picture
Every week Meridian's receivables team rebuilds one spreadsheet by hand from insurer portals and email reports, slices it per client and emails it out. Clients answer in long threads that mix several policies and several kinds of request. The success test, in the words of Meridian's head of receivables: the client leaves thinking "I don't need to email Meridian to find out where things stand."
~1,470installment rows rebuilt by hand in every weekly snapshot
2 daysof the team's week spent slicing and emailing per-client sheets
21overdue installments, about R$288k, vanished between 02/11 and 09/11 without being paid
R$41,870.55due the day after the story date on policy 4471, while the whole thread was about another installment
For the client
- One view across every company in the group: overdue, due in the next 30 days, and every request in progress.
- Requests tied to one installment: receipts, extensions, questions and new payment slips, each with its own conversation.
- A phone summary for approvers: what is at risk this week and what is stuck with the insurer.
- Exports for the payment run, with client-safe columns only.
For Meridian's team
- Upload the same spreadsheet, any day. Every upload updates; nothing is wiped or duplicated.
- Doubtful rows are held with a reason, and installments that vanish while overdue become tasks to verify.
- One request queue with internal notes kept apart from client messages, and a preview before anything reaches the client.
- One digest email at 08:00 with everything that needs attention today.
Rules it never breaks
- Internal data never reaches a client, enforced by separate tables, lint rules and a canary test.
- Every client query is scoped on the server to the user's own group.
- Nothing looks approved before it is. A receipt is under review until the insurer confirms.
- No payments. Brokers can't receive premiums, so there is no pay button anywhere.
- Imports never delete, and what the team recorded with the insurer outranks a late spreadsheet.
Built with
TypeScriptReact + ViteTanStack Router/QueryArc Pro UI
NestJSPostgreSQL 16 + Drizzlepg-bossFirebase Auth
S3 / MinIOReact Emailzod contractsVitest
TestcontainersPlaywrightGitHub Actions
Process
How it was built
From understanding the problem to sign-off, in six steps.
-
01
Understanding the problem
The brief, the Atlântica email thread and the two weekly spreadsheets of 02/11 and 09/11, read row by row. The data showed what the thread missed: five spellings of the same group, duplicate keys, amounts typed as text, and 21 overdue installments that simply disappeared.
-
02
PRD and architecture
A PRD with goals and measures, scope, twelve decisions agreed with Meridian, functional and non-functional requirements and LGPD. Then the architecture: seven decision records, the data model and the main flows, all diagrams in Mermaid.
-
03
Atomic, parallel tasks
Contracts first: zod DTOs, database schema, routes, ports and typed mocks, so nobody waits on anybody. Then 16 workstreams with disjoint file ownership, run in waves, with ten in parallel in the first wave.
-
04
AI-assisted development
One Claude Code orchestrator dispatched backend, frontend and QA subagents, one per workstream. Each agent edits only its own paths and ends with a report; change requests are applied between waves, and only the orchestrator commits.
-
05
Tests and CI
186 unit tests, 131 integration tests against real PostgreSQL with Testcontainers, a canary test that fails if internal data ever reaches a client, and 9 Playwright end-to-end flows on desktop and phone width. GitHub Actions runs build, lint and tests on Ubuntu, Windows and macOS, plus a Docker smoke test that follows the README.
-
06
Manual validation and sign-off
Every flow walked by hand against the seeded stack, the demo script rehearsed end to end, and a fresh clone run on Linux and macOS following the README word for word before hand-off.