Rostering and timesheets for a home-care agency

The agency sends carers to people's homes on fixed schedules, and it was coordinating that with a shared calendar, a phone, and a lot of goodwill. Two problems mattered commercially: visits that were completed but not evidenced, which the funder would not pay for, and last-minute reassignments when a carer called in sick, which took a coordinator most of an hour on the phone. There is also a duty-of-care dimension — someone needs to know quickly if a visit did not happen — which is not really a scheduling feature but shares all the same data.

Contract full-stack developer, about seven months, working with one other developer and a coordinator from the agency who was given half her week to the project. The agency's operations manager acted as product owner and was the one who kept telling us that carers would not use anything with more than two taps in it, which was correct. I built the backend and the coordinator-facing web application; the other developer built the carer-facing side.

I owned the roster model — visits, recurring patterns, and the messy reality of exceptions like a client going into hospital for two weeks — and the reassignment flow that finds who is free and near enough. I built the timesheet derivation, which takes visit check-ins and turns them into something payroll and the funder both accept, including the rules for travel time and for visits that ran long. I also owned the alerting for missed visits and the escalation path, which the operations manager specified line by line. The carer app was not mine but I wrote the API it uses.

I designed the roster as a pattern plus a list of explicit exceptions, rather than generating and storing every future visit. Generating them is simpler to query and is what the previous attempt had done; it also means that changing a recurring pattern rewrites thousands of rows and loses the record of what was originally planned. Since the funder cares about planned versus delivered, keeping that distinction in the model was worth the extra complexity in reads. I also decided against automatic reassignment — the system proposes and a coordinator confirms — because the constraint that actually matters is which carer a client is comfortable with, and that is not in any data we hold.

Funder rules dictated what evidence a visit needs, and those rules changed once during the project with about six weeks' notice, which cost us a sprint. The carers' devices are their own phones on variable connections, so check-ins had to work with no signal and reconcile later. Rollout was region by region at the operations manager's insistence, one region a fortnight, with the paper process kept running in parallel for the first two regions. There was a strict rule that no client's address or care details could go anywhere near a test environment, so we built a data generator early rather than argue about it later.

Unevidenced visits went from roughly six per cent of the month's total to under one, which is straightforwardly money the agency was previously not being paid. Reassigning a sick carer's day went from about fifty minutes on the phone to under ten, and coordinators told us that was the change they would fight to keep. Missed-visit alerts surfaced two situations in the first quarter that would previously have been noticed hours later. We rolled back one region for a week after a timesheet rounding difference against payroll, fixed it, and went again.

The coordinator seconded to the project designed the reassignment screen by walking me through the phone calls she made, and it is her layout, not mine. The other developer owned the carer app and its offline behaviour, which is the hard half. The agency's payroll administrator checked every timesheet rule against her own calculations for two months and found the rounding difference that caused the rollback.