> product // orthotrack // the making of
JRC OrthoTrack
how it was made.
JRC OrthoTrack started as 18 build phases committed on a single December day: a working surgical case-management system shipped before the end of the week. What followed was six months of steady refinement alongside the clinical team, turning a capable prototype into a system the nursing and theatre staff actually wanted to use every day.
The short version
The build opened in a single burst: 18 numbered phases landed on 2 December 2025, covering schema, API, UI, Kanban, calendar, seeding, and deployment. By the same evening it was live on a custom domain. The following months were different, not a sprint but a sustained collaboration between the development team and clinical staff, working through detailed procedure catalogues, a 7-stage surgical pathway, multi-channel patient communications, and a theatre list that surgeons could actually plan from. The codebase grew through tight feedback loops: clinical requirements arrived as named specs, fixes often referenced specific task IDs, and the AI team member working the repository had its own branch naming convention visible in the PR history from May 2026 onward.
// the build log · mined from the commit history, nothing dramatised
Foundation to deployment
The project opened with 18 checkpoint commits landing on 2 December 2025, covering everything from entity schemas and CRUD routes through to Kanban, calendar, dashboard, demo data, and post-deployment bug fixes. By the same day it had a branded landing page and was live at a custom domain. It was a scaffold built to be inhabited, not a finished product.
Proposals, approval, and the first real feature
January was documentation: eDM system specs, template management concepts, a proposal revision, and a project brief updated for February's scope. When development resumed on 12 February, the Core Workflow tier landed, stage-change notifications, a unified messages architecture, and OAuth callback handling. A sign-in race condition was fixed the same week.
Multi-tenant branding and patient registration
March brought the clinic branding sprint: customisable logos, colours, and clinic names injected into emails, page titles, public-facing forms, and the sign-in screen, all stored in organisation settings and applied at runtime to prevent flashes of unstyled content. Alongside it, the patient onboarding form was built from scratch: a public-facing scrollable page with conditional fields for carers, nominated persons, health conditions, insurance, workcover, and Medicare, all behind URL-safe invite tokens.
Procedure catalogues, body parts, and terminology evolution
The procedure system grew into a body-part-first architecture with progressive sub-options for approach, prosthesis, and technique, catalogues for knee, hip, shoulder, ankle/foot, and elbow rewritten to clinical-team specifications. During this period "cases" became "surgeries" across the application, and the Inbound & Triage workflow module was implemented as the first of seven stages. A comprehensive QA audit hardened server-side routes against XSS, IDOR, and abuse.
The full surgical pathway
Stage by stage, the 7-step pathway was built out: Inbound & Triage, Consultation & Booking, Onboarding & Preparation, Logistics & Pre-op Readiness, Pre-admission Finalisation, Surgery & Inpatient Recovery, and Case Closure. Each stage carried its own workflow items, sub-tasks, and process notes, iterated against clinical-team specifications. The Kanban board gained colour-coded columns, a hybrid condense-on-scroll header, and a sticky workflow panel; the calendar added week, day, month, and theatre-list views with surgeon initials and surgery duration tracking.
The communications engine and PROMs
The final months wired up the communications layer: scheduled email and SMS templates keyed to surgery dates, merge-tag substitution, bulk send from the Comms Engine table, and a rich-text email editor with XSS-safe rendering. Patient Reported Outcomes (PROMs) arrived as a knee and hip wizard with scoring logic, automated invite dispatch, and a satisfaction survey with score-driven follow-ups. Theatre lists gained recurring window management, calendar slot-gating, drag-and-drop blocker events, and per-case unlock. The AI team member's contribution is right there in the PR history from late May: a distinct series of agent-authored branches shipping targeted fixes and features alongside the human developer's work.
git log: “checkpoint: Phase 18 Complete - Post-Deployment Bug Fixes”
The eighteenth and final checkpoint on the day the system launched: the build moved straight from deployment into production fixes without pausing.
// the roads not taken
Tried, measured, set aside: the judgement lives here as much as in what shipped.
Multi-step patient onboarding stepper
The patient onboarding form was initially implemented as a multi-step stepper, then revised to a single scrollable page in the same sprint. The stepper was not the clinical team's preference for a public-facing registration form.
Hardcoded terminology and branding
Early builds had surgeon names, clinic references, and case terminology hardcoded throughout the UI. A dedicated branding sprint in March centralised everything into organisation settings and a text-constants system, making the product multi-tenant. The word "case" became "surgery" across the navigation in the same period.
Server-side calendar overlap blocking
Hard overlap prevention was built and tested, then removed, replaced with a confirm-and-proceed dialog that warns rather than blocks. Clinical scheduling reality proved more nuanced than a hard rule could handle.
Transport Preference section
The Transport Preference section was removed per a clinical-team instruction, then fully reverted a week later when clarification came through. The revert commit is in the log verbatim: "Revert 'feat(logistics-preop): remove Transport Preference section'".
Want something built like this?
This is how we work: in the open, measured, honest about the dead ends.