The challenge
Haven Respite is a Nottinghamshire social enterprise delivering in-home care: dementia support, post-operative recovery, mental health, overnight sitting, and respite for family carers.
From the outside it looks like a marketing problem, and the marketing site is the small part of it. Care operations are the real system. Care plans and risk assessments that change over time and must keep their history. Client intake that collects sensitive information from people in difficult circumstances. Documents that need signing. Staff who need different levels of access to different things, and an audit trail behind all of it.
What we built
The public site is the front door. Behind it sits the operations platform: care plans and risk assessments that keep their version history rather than overwriting it, tokenised client intake with document e-signature, two-factor admin authentication with role-based access control, and an audit trail across the whole thing.
The backend is FastAPI on Python with async SQLAlchemy over Postgres and Redis. The front end is Next.js App Router and React with TypeScript, Tailwind, Radix, TanStack Query, and react-hook-form with Zod.
Every change ships through a pipeline that runs the automated test suite and a security scan before anything reaches production, with end-to-end tests covering the paths that matter most.
The client can write some answers, never the others
A care intake wizard collects two very different kinds of information, and conflating them is a safeguarding failure.
There are answers the person being assessed can and should write: their circumstances, their needs, their preferences. Then there are internal judgements that exist for the organisation, the kind a care team records about risk and complexity. Those must never be writable by the person being assessed, whatever the form sends back.
The intake wizard separates the two at the boundary rather than by convention, so the surface a client can write to and the surface only staff can write to are genuinely different things. A crafted request cannot promote one into the other. In a care context that is not a nice-to-have, it is a correct threat model.
Intake links are credentials, so they are treated as credentials
An intake link is sent to a person, which means anyone holding the link holds the access. That makes it a credential, and it gets the handling a credential deserves.
Links are stored hashed rather than in plain text, so the database never holds a working key to anyone’s intake. Expiry is treated as a real state rather than an error: a link that never existed and a link that has lapsed are different facts, and the system distinguishes them instead of collapsing both into a generic failure.
The same care runs through the request pipeline, where the order of protective layers is reasoned about explicitly rather than left to chance.
Outcome
Haven Respite runs its care operations on the platform: intake, care planning, risk assessment, e-signature and audit, with the public site as the front door.
The work is ongoing.