01Situation
Care agencies must show, for every client and every visit, that care happened: who attended, when, what was administered and what was observed. They also have to pay staff correctly for that time and bill for it under the right reimbursement model.
The platform tied all of this into one record chain: schedule, then clock-in, then medication and notes, then pay, then bill. The existing build worked, but nobody who wrote it was still around, and there was no reliable documentation of how it behaved. Every change was a risk, and the client wanted to grow the product rather than keep patching it.
Before anyone could estimate a rebuild, someone had to answer a simpler question: what does the system actually do today, for each role and each module?
02What I did
Understand the legacy
Walked the existing platform role by role and module by module, and wrote down how it actually behaved.
Make the case
Laid out the options, risks and costs for the client, and won approval for a full rebuild instead of more patching.
Write the SRS
A 15-section SRS covering 7 user roles, 60+ modules, the APIs and the database design.
Milestones and sprints
Split the rebuild into milestones and sprints, assigned tasks and bugs, and ran planning and retrospectives.
UAT and API testing
Designed the mobile app with AI tools, ran UAT and Postman API tests, and demoed every release.
Recommend features
Turned client pain points and market value into feature proposals the client chose to fund.
Compliance from day one
Because the platform handles protected health information for US agencies, I researched the applicable healthcare regulations before design started and made HIPAA and BAA compliance a requirement, not an afterthought. Access control, audit trails, field-level encryption and data handling were specified up front, alongside the functional modules.
03A living specification
The SRS explains; the tracker gets things done. I kept a module-wise SRS tracking worksheet alongside the document, and it became the shared checklist for development, QA and client sign-off, and the input to every change request. This is the shape of one row, with illustrative content:
| Field | What it holds | Example (illustrative) |
|---|---|---|
| Module / sub-module | Where the behavior lives, and for which roles | Scheduling › Recurring visits (Admin, Coordinator) |
| Description and flow | What the user does and what the system does in response | Create a weekly pattern; the system materialises visits 8 weeks ahead |
| Inputs and validations | Every field, its rule and the exact message shown | End date after start date: "End date must be after the start date" |
| Business rules | Conditions, limits and edge cases | No overlap with the caregiver's other visits; authorization units checked |
| APIs and tables | Endpoints and database tables touched | POST /schedules; schedules, visits |
| Open questions | What still needs a client decision, with an owner | Holiday handling for recurring visits (client, due Friday) |
| Review status | Client review and sign-off state | Approved with comments |
Want to see the same depth with real documents? The US Home-Care Operations Platform case study covers similar work, with the full set of documents open to read.
04Key decisions
Rebuild, not patch
With no original developers and undocumented behavior, every patch added risk. A documented rebuild gave the client a platform their team could own and extend.
Compliance is scoped, not retrofitted
HIPAA and BAA obligations were written into the requirements before design, which avoided rework late in delivery.
Grow scope through value, with change control
New features came in through change requests with impact on effort and timeline, so growth never derailed the committed milestones.
05Outcomes
The rebuild shipped to production. I received Employee of the Month (July 2026) for taking this platform and one other to production, after project completion certificates for both in May 2026.
Deliverables
06Tech stack
The platform's stack, which I documented in the SRS and worked against for API testing and UAT.
- Application
- Laravel 12 on PHP 8.2
- Web portal
- Blade, Bootstrap 5; Vite, Tailwind CSS and Alpine.js for public pages
- Database
- MySQL 8 with field-level encryption at rest
- Access
- Session auth for web, Sanctum tokens for mobile, role-based permissions
- Integrations
- Stripe (plans, checkout, webhooks), Twilio SMS, Google Maps geocoding and directions
- Operations
- Queues and scheduler, error monitoring, Docker and Docker Compose
07What I learned
- Document the "as is" before the "to be". On a legacy system the first deliverable is an honest description of current behavior. Without it, nobody can agree on what the rebuild must preserve.
- A tracker beats a long document. Teams act on rows with owners and statuses.
- Scope growth is good news when it is controlled. Recommending features grew the engagement, and change requests kept the delivery predictable.