The situation
Pietas Healthcare does two related things. It is a healthcare recruitment business, supplying care homes and healthcare companies across the UK with the professionals they need. And it is a care provider in its own right, running a domiciliary care operation: care delivered in people's homes, end to end. The company I co-founded, and where I lead the digital and product work, is structurally interesting for exactly this reason: the two halves of the business operate at two different speeds, and most companies in this space run only one of them.
Recruitment is a pipeline business. Candidates flow in, are screened, vetted and placed, and the pace is set by demand: a care home short of staff needs a response measured in days. Domiciliary care is a continuity business. Its unit of work is not a placement but an ongoing relationship: a carer, a client, a schedule that must hold, week after week, in someone's actual home. When those two businesses live in the same company, the second one feeds on the first: a strong recruitment operation becomes the supply line for a care operation that never has to buy its workforce at retail.
The design problem, and the reason this study exists, is the handover. The moment a recruited professional becomes a delivering carer is where the two speeds meet, and it is where most operators improvise. This is the story of the digital and service infrastructure that carries a recruitment-plus-care model end to end, built while co-founding the company.
The constraints
The sector's constraints are unusually hard. Care recruitment carries vetting obligations that cannot be treated lightly, because the person placed tomorrow works with vulnerable people. Domiciliary care adds logistics: real schedules, real travel, real continuity, and a regulatory frame around every visit. Between the two sits a compliance surface that never stops moving.
The operational constraint is tempo mismatch. A pipeline that moves in days shares data with a service that runs for months, and the systems must not force either half to work at the other's pace. And the founder's constraint, the one that shapes everything I build: this company would never be a place with an IT department and a two-year roadmap. Whatever infrastructure existed had to exist early, work immediately, and scale quietly.
Discovery
The discovery question was not "what software does a recruitment company need" or "what software does a care company need". Those are both solved problems, badly, by the market. The question was what a company needs that is deliberately both, in which the recruitment lane feeds the care lane.
Mapping the model exposed the truth that organised the build: the company has one asset flowing through both halves, the professional, and two entirely different relationships to that asset. To the recruitment side, a carer is a candidate in motion. To the care side, the same person is a provider of scheduled, continuous, accountable service. The whole architecture exists to let one human being hold both roles without the company ever losing sight of either.
The decisions, and what was rejected
One architecture for both speeds, not two systems and a bridge. The recruitment lane and the care lane share one foundation, with each surface shaped for its own tempo. Rejected: separate recruitment software plus separate care software joined by exports and re-entry, the industry's default, which spends the handover moment, the most important moment in the model, on copy and paste.
The handover is the designed moment. When a recruited professional becomes a delivering carer, the system carries the transition: identity, vetting status, availability, all moving with the person. The handover was treated as the product's signature interaction, designed like a checkout, because it is where the company's advantage either materialises or leaks. Rejected: treating placement as the finish line, which is how recruitment companies think and precisely the assumption this model has to break.
Vetting is a status that lives with the person, not an event that lives in a folder. In a business that both recruits and delivers, compliance is not a stage of the pipeline; it is a property of the professional that both halves read. Rejected: compliance as a recruitment-stage document, which expires invisely and surprises the care operation later.
Schedules are designed for continuity, not coverage. A domiciliary roster is not a puzzle of slots; it is a network of relationships that should resist unnecessary churn. The design favours consistency of assignment, because continuity is a care outcome, not just an operational preference.
The website and public surfaces are part of the infrastructure. A company that recruits professionals and serves families has two publics, and both need to encounter the same standard of clarity and calm that the internal systems enforce. The public site, the recruitment presence and the care service description are one voice.
The process
The model was mapped first: the professional's journey from candidate to carer, the client's journey from enquiry to ongoing care, and the points where the two journeys touch. The shared foundation was designed second: identity, vetting status, availability and history as one model both lanes read. Then each lane's own surfaces were built to its own tempo: pipeline views that move at recruitment speed, and rota and continuity views that move at care speed. Finally the public surfaces, carrying the same design language, because a company's standard should not have an inside and an outside.
Craft details
The system's signature piece is the continuity of identity across the handover: the person arrives on the care side already known, already vetted, already carrying their history, and the organisation never asks them who they are twice. Around it, the scheduling design treats consistency as a feature, and the compliance design treats status as a living property rather than a filed document. Those three decisions, identity, continuity and status, are the load-bearing structure.
The outcome, stated honestly
Pietas Healthcare operates its recruitment and its domiciliary care on one digital architecture built for the model it actually runs: recruitment for care homes and healthcare companies, and care delivered in people's homes, end to end. The two halves feed each other the way the model intends, and the handover, the moment most operators improvise, is designed.
Per the standard this portfolio holds, no invented client counts, placement figures or operational metrics appear here. The honest outcome is architectural: the company's structural advantage, a recruitment engine feeding a care operation, is enforced by its infrastructure rather than maintained by its staff's memory.
What the work taught
When a business is two businesses by design, the software must never be allowed to see two businesses. The moment the systems split along the org chart, the advantage drains out through the gap, because the handover stops being designed and starts being remembered. I learned to design the seam first: every company has one, the place where its two halves meet, and the quality of that seam decides whether the model works in practice or only works on paper.
Studies 4 through 10 (Evuve, the Compliance Bundle, the Founder Launch System, Maison, Meridian, Codex, Signals) follow in my next message, same depth standard, on your go.
