The product
Nathan runs community rehabilitation services. Each person in the programme, called a candidate, is matched with a mentor who meets them every week. Some also get academic support or help finishing school. Behind every meeting there is work to do:
a referral and an intake form
a budget approval from the funder
a rehab plan and a set of required documents
a mentor with free hours in the right area
a work diary the coordinator approves
the mentor's pay and the bill to the funder at the end of the month
The Nathan system handles that whole cycle for admins, regional managers, coordinators and mentors. It is a large Next.js and tRPC application, built by a team: 127 database models, about 180 API routers and a payroll and billing engine. The screenshots here use demo data, with the interface translated into English.
My part
I was one of the developers on the team from April to December 2025, on both the backend and the frontend. I built:
The candidates table, with its filters and pagination, and the candidate page tabs for treatment, rehab plans, summaries, documents, coordinators and mentors, with their APIs
The mentor module: the mentor list with advanced filters and Excel export, mentor statistics, and training and activity records
Document handling for candidates, mentors, training, rehab plans and summaries
The candidate daily log and the mentor work diary, with a salary preview
A drag-and-drop editor for digital form templates, saved to cloud storage, and the form filler that uses them
A bulk upload that reads candidate details from documents with an AI model
The first finance screen, the users screen, general reports, and the 2025 redesign of the sidebar, header and login
Fixes to coordinator and mentor assignment, including capping a mentor's hours at the candidate's approved hours
The candidates table: budget approval, missing documents, placement and service at a glance.
A candidate in one place
The candidate page gathers everything a coordinator needs: personal details, treatment notes, the rehab plan, summaries, the assigned mentor and the documents. A mentor cannot be placed until the required documents are in, and the page says exactly which one is missing.
Placement: approved hours a week, hours already placed and what is free.
Documents and approvals for each service, with what is valid and what is missing.
The mentor's week
Each mentor has a file with their candidates, documents, training and a combined weekly schedule. Planned hours are checked against daily, weekly and monthly limits, so overbooking shows up before the diary reaches payroll.
A mentor's combined schedule, with the daily, weekly and monthly limits on top.
The candidates assigned to a mentor, each with their work diary.
From diary to payroll
Approved diaries feed the finance module, which calculates mentor pay, bills the funders and exports the files payroll and the funders need. The finance engine was built by another developer on the team; my work diary and salary preview are where its data starts.
The finance dashboard: payroll, billing, cycles and reports.
What I took from it
This was a busy codebase with several people shipping every week. I learned to keep my changes small, to write the API and the screen together so neither drifted, and to check every assignment rule against the money it would cost at the end of the month.