Community Careline Services
Care Assessment & Recruitment Platform
- Role
- Full-Stack Software Engineer, led architecture and build (via SETS Tech)
- Dates
- Feb 2026
- Status
- Live
- Next.js, NestJS, PostgreSQL (in progress)
- JavaScript
Summary
Website for a UK domiciliary care provider: care-services pages, confidential care-assessment enquiry forms, a careers page with vacancies and applications, and an admin CMS for services, blog, careers and testimonials. A TypeScript operations platform for shifts, visit records and a family portal is in progress.
Two phases
- Phase 1 (live, via SETS Tech): a website for care enquiries and carer recruitment, with an admin CMS.
- Phase 2 (in progress, via SETS Tech): a TypeScript operations platform (Next.js, NestJS, PostgreSQL, Prisma, shared Zod schemas) for shifts, visit records and a family portal.
The problem
Family enquiries were fragmented and recruitment relied heavily on manual, paper-based processes. The business needed a system that could capture sensitive information more consistently while also making vacancies and applications easier to manage. Day-to-day care still runs by hand: carer rotas on paper, visit notes in notebooks, and families kept informed by phone calls when someone has time. That is what the operations platform is for.
Before
- Enquiries by phone
- Paper rotas
- Visit notes in notebooks
- Photos over WhatsApp
- Families waiting for a call
Planned
- One system
- Shifts assigned centrally
- Every visit recorded with photos
- Relatives see updates themselves
- Records ready to show rules were followed
My role
Led the architecture and build via SETS Tech. I led the live website and its admin CMS, and wrote the full product spec for the operations platform with the provider. On the TypeScript rebuild I design the architecture and data model, plan the work, build the core myself and guide the in-house and freelance developers working with me.
What I built
- Mapped the family care journey and the care-worker recruitment journey before implementation.
- Built the confidential care-assessment enquiry forms: each enquiry is saved for the office and emailed to them.
- Built the careers pages: vacancies, job details and applications with CV upload.
- Built the admin CMS for services, blog, careers, testimonials, FAQs, locations, redirects and SEO settings.
- Led the accessibility and responsive design pass for older users, families and mobile applicants.
Current phase: operations platform (in progress)
Rebuilding the platform in TypeScript (Next.js, NestJS, PostgreSQL, Prisma, shared Zod schemas) from a full product spec I wrote with the provider. The spec covers: - Shift scheduling and carer management for the office team. - A phone-first carer view with visit notes and activity photos. - A family portal where relatives see only their own family member's care. In the target architecture, one NestJS API makes every decision. The Next.js app has three faces: the public site and family portal, the carer view, and office admin.
Target architecture of the operations platform, which is still being built.
- A Next.js app with three faces: the public site and family portal, the carer view, and office admin.
- It talks to one NestJS API: every route denied by default, roles checked on every request, and ownership checked in the service, so a family account can only reach its own relative’s records.
- The API stores data in PostgreSQL through Prisma.
- Alongside the API: media storage for visit photos, and background jobs for email, reminders and image processing.
Key decisions and trade-offs
These are design decisions for the operations platform. They are decided, not shipped yet. 1. Family portal shows only their own relative Chose: ownership checked in the service for every record; other people's records return "not found". Not: a shared family view filtered in the front end. Why: a mistake here would expose someone's health information. Downside: every query carries the ownership check, and tests will have to prove it. 2. Photos kept inside the visit record Chose: carers upload activity photos into the visit record, visible to the office and the relative. Not: sending photos over WhatsApp or other chat apps. Why: photos are the clearest evidence for families and for the provider's own records, and they must stay inside the system. Downside: storage and image processing become the provider's responsibility, and consent has to be recorded. 3. Shifts assigned centrally Chose: the office assigns shifts and carers see only their own. Not: carers picking visits themselves. Why: continuity of care and compliance matter more than flexibility here. Downside: the office has to keep the rota current.
Results
The provider runs its care enquiries, careers and website content through the live site: one digital entry point instead of scattered brochures, phone calls and paper-led applicant handling. The operations platform is the current phase of work.
Key features
- Care-services hub covering domiciliary care, supported living and specialist options.
- Confidential care-assessment request forms.
- Careers pages with vacancies, job details, CV upload and applications.
- Admin CMS for services, blog, careers, testimonials, FAQs, locations, redirects and SEO settings.
- Accessible high-contrast interface.
Development timeline
- Phase 1 — PHP website (live)
Care-services pages, care-assessment enquiries, careers and applications, and an admin CMS. - Phase 2 — TypeScript operations platform (in progress)
Next.js, NestJS, PostgreSQL, Prisma and shared Zod schemas: shifts, visit records with photos and a family portal, built from the product spec.