What it is
We built a residential client management portal to replace a patchwork of spreadsheets and eleven separate SharePoint lists that a residential program team had been using to track clients, housing assignments, financial records, and regulatory recertification. It runs on Blazor Server and integrates directly with the organization’s clinical record system, pulling in client and admission data automatically rather than requiring manual re-entry.
Why it mattered
Before this system existed, the same client record effectively lived in several disconnected places at once, a spreadsheet for financial tracking, a SharePoint list for housing assignments, another for compliance deadlines, with no reliable way to confirm any two of them agreed with each other. Recertification deadlines for subsidized housing had to be tracked manually against a moving eligibility window, and a missed deadline carried real regulatory and funding consequences.
I set the goal as consolidating everything into one system with a single source of truth, not just digitizing what already existed. Every field needed a clear answer to who could see it, who could edit it, and what happened when the clinical record system reported a change that conflicted with something staff had entered by hand.
Why this project, and why alone
Our main development team was committed to an HL7 integration with a county payer, exacting work with an external deadline. The residential programme’s need was real and would otherwise have waited behind it, so I took it on myself as a deliberate test of whether an AI-assisted approach could produce a genuine production application rather than a demonstration.
My own position matters here. I worked as a web programmer roughly twenty years ago, and my career since has been reporting, data architecture, and database work. I can read code and reason about architecture; writing a modern web application by hand was not realistically available to me. Without an agentic coding tool this application does not get built, which is what makes it a fair test of the tooling rather than a measure of how much faster an active developer can go.
We chose the tool by comparison rather than default, weighing Microsoft Copilot, the chat assistant I had already used for roughly eight months, against Claude and OpenAI’s tooling. Copilot’s limits were clear from use rather than from reading: it was a chat window, so it could not read the codebase, could not compile or run anything, and retained nothing between sessions. Useful as a thinking partner, but every line of code had to pass through me by hand.
The approach
We started with the smallest possible slice, a database and a single working page, and let real usage drive what came next rather than trying to design every feature up front. Early sessions built out client records, housing and bed assignment, and financial tracking one piece at a time, with role-based access control and field-level permissions added once real usage patterns made clear which fields needed tighter control than others.
One design principle I held to shaped almost every feature that touched data from the clinical record system: incoming changes are never applied automatically. Anything the source system reports gets queued for staff review first, since an automatic overwrite could silently discard a correction someone had just entered by hand, or apply a change, like a discharge date, before anyone had actually reviewed it.
A decision I reversed
One design choice is worth naming because I got it wrong first. The staff request intake feature was originally designed around self-hosting an open-source project management tool, on our own infrastructure, for data residency reasons. I had it fully specified: seventeen setup steps, a reboot window, and ongoing maintenance.
Then I checked why the constraint existed, and it had already been lifted. The organisation had adopted Freshservice company-wide as its IT service desk and had already accepted cloud hosting for exactly this category of data. An entire infrastructure workstream disappeared, and the feature improved, because staff already knew where their tickets would land.
The habit that came out of it: before building around a restriction, confirm the restriction is current.
How it works
Every timestamp in the system is stored and displayed in Eastern time, enforced through a single shared time source rather than each part of the codebase calling its own default clock function, after an early bug showed how easily that assumption breaks in practice. Access control runs through a role system layered with field-level permissions, so a single field can be fully editable for one role, visible but read-only for another, and hidden entirely for a third, all configured through an admin screen rather than hardcoded per page.
An impersonation mode lets an administrator view the application as another role for support and testing, with hard guardrails preventing one admin from impersonating another admin, or themselves, so the feature cannot be used to quietly assume a higher level of access than intended.
The result
The system now serves as the operational system of record for an entire residential program, client records, housing and bed management, financial tracking, regulatory recertification, and case management, all in one place with a consistent audit trail. Recurring scheduled jobs handle recertification reminders, inactivity follow-ups on open case matters, and error monitoring automatically, replacing what had been manual, easy-to-miss tracking before.
Where it stands
The application has been in active production use since an early deployment in the project’s first weeks, with continuous feature development and refinement across more than fifty working sessions since then. Development is ongoing, with the next planned phase migrating several remaining scheduled jobs to shared scheduling infrastructure used across other internal applications.