Turning a Care Agency’s Manual Operations Into One Connected System

How I designed and built an internal platform for recruitment, onboarding, compliance, training and staff management.

A UK care agency was running critical parts of its operation across paper, WhatsApp, manual processes and several disconnected SaaS tools.

The challenge wasn’t that the team didn’t have a process. They did. The problem was that the process was spread across too many places, creating unnecessary administrative work and making it harder to see what needed to happen next.

I designed and developed an internal system that brought recruitment, onboarding, compliance, training and staff management into one connected workflow.

The interesting part wasn’t building the screens. It was understanding the operation well enough to turn the way the business actually worked into software.

Understanding the operation before designing the product

I didn’t go into the project already knowing every detail of how a care agency operates. The client had that domain knowledge. They understood the recruitment requirements, compliance obligations, onboarding process, training, shadowing and the smaller operational details that someone outside the sector wouldn’t necessarily know.

My job was to understand that knowledge well enough to translate it into a product. That meant asking questions about what happens after someone applies, who reviews their application, what needs to happen before they can progress, which documents are mandatory, who verifies them, and what prevents someone from becoming active staff.

I also needed to understand what happens when the normal process doesn’t go according to plan. Those conversations shaped the product far more than any individual screen did.

Recruitment wasn’t a collection of pages. It was a lifecycle.

Once I understood the process, I mapped the candidate journey as one connected workflow:

Application → Interview → Offer → Pre-employment → Staff Activation → Induction → Shadowing → Active Staff

The journey starts with the job application itself. Candidates can view an available role and apply through a structured application process, providing the personal, employment and role-specific information the agency needs to assess them.

What mattered was what happened after someone clicked submit. The application couldn’t simply become another form submission sitting in an inbox. The information needed to become part of the candidate’s record and give the recruitment team a clear starting point for reviewing and progressing them.

That made the application more than a form. It became the entry point into the wider recruitment workflow.

From there, the recruitment team can review applications and decide who should progress to interview. Interview details, scheduling, outcomes and subsequent decisions all become part of the same candidate journey.

An accepted offer opens pre-employment. Completing the required checks eventually allows the candidate to move into staff activation, induction and shadowing.

The individual screens make those stages visible, but underneath them the system has to understand the candidate’s current state and the rules that determine what should happen next.

That became a recurring theme throughout the project: I wasn’t just designing screens for different tasks. I was designing the relationships between those tasks.

Pre-employment made the complexity much clearer

Before someone can become active staff, the agency needs to collect and verify information such as references, passports, driving licences, DBS information, proof of address, National Insurance details and Right to Work documentation.

When that information is being handled across different channels, the administrative work isn’t limited to collecting it. Someone also needs to know what has arrived, what has been checked, what is still missing and whether the candidate is ready to move forward.

So the system couldn’t just provide somewhere for candidates to upload files. It needed to give the agency a clear picture of each requirement and how it affected the candidate’s progress.

That changes the problem considerably. You’re no longer building document storage; you’re building part of the agency’s decision-making process.

Compliance made me think about data differently

Collecting a document is relatively straightforward. Managing what happens to it over time is more complicated.

A certificate might be uploaded and verified today, approach its expiry date months later, and eventually expire. When its status changes, the employee’s wider compliance position may need to change with it.

Instead of treating these documents as files sitting in a database, I treated them as records with states:

Verified → Expiring → Expired

The system can monitor those states and surface what requires attention. That gives the team a clearer view of who is compliant, what is approaching expiry, what is missing and where someone needs to intervene without manually working through staff files across different systems.

This became an important principle for the product: internal software shouldn’t only store the information a business gives it. It should help the business understand what that information means and what needs to happen because of it.

Not everything should be automated

Once you understand a workflow, it’s tempting to make it perfectly linear. Candidate completes A, the system moves them to B, and once B is complete, C automatically becomes available.

That works well in a flowchart, but real operations are rarely that predictable. An administrator might need to upload something on behalf of a candidate, skip a stage, correct a status or deal with information that arrived outside the expected process. Sometimes someone simply needs to make a judgement call.

I didn’t want the agency to end up fighting its own software whenever reality didn’t match the ideal workflow. So I focused on automating the predictable parts while keeping the team in control of the exceptions.

That balance became one of the more important product decisions in the project. Automation was useful where the rules were clear, but human control still needed to exist where the operation required judgement or flexibility.

Recruitment was only one part of the employee lifecycle

Once a candidate passes the required pre-employment checks, they can be activated as staff and move into induction. The agency can manage the required training and add certificates to the employee’s record, where they become part of the same ongoing compliance process.

After induction comes shadowing. Dates need to be coordinated, an observing senior carer assigned, evaluation forms recorded and an overall outcome determined. Successful candidates can then complete onboarding and move into active staff.

What mattered wasn’t any one of these features in isolation. It was how they connected. Recruitment affects onboarding, training affects compliance, certificates expire, compliance statuses change, and administrators need visibility across the entire journey.

The system needed to reflect those relationships rather than forcing the team to piece them together themselves.

Bringing the employee lifecycle into one place

As the system came together, the employee record became much more than a profile containing basic information. It became a way to see the wider history of that person’s relationship with the agency.

Instead of recruitment information living in one place, training somewhere else and compliance somewhere else again, their recruitment history, documents, training, compliance information, shadowing and ongoing staff records could exist within the same operational system.

[IMAGE — FULL STAFF RECORD / GOVERNANCE OVERVIEW]

The agency is now using the system, and it has reduced the amount of manual administrative work the team has to manage. More importantly, they now have much more of their operation in one place rather than spread across paper, WhatsApp, manual processes and disconnected software.

For me, that’s the more meaningful outcome. The project wasn’t simply about digitising what the agency was already doing; it was about giving those operations a structure that the software could support.

From business process to working product

I used Figma, Pencil.dev and Bubble across the design and development process, working on the interface, database architecture, workflows, permissions, candidate experience, admin operations and automation.

But the project reinforced something I’ve found increasingly important when building internal products: the difficult part is rarely drawing the interface. It’s understanding the operation well enough to model it.

When something happens inside a business, you need to understand what that event actually means. What data changes? Who needs to know? What becomes available next? What should be blocked? What happens when someone fails a stage or a certificate expires? And where does a human still need the ability to intervene?

Those questions determine the product. The screens are how people interact with the answers.

Sometimes another SaaS tool isn’t the answer

The care agency already had processes before I built this system. People were doing the work every day, and the business was operating. The problem was that too much of that operation depended on manual administration, disconnected tools and information spread across different places.

My role was to work with the client’s domain knowledge, understand those processes well enough to model them, and turn them into one connected product.

That’s the kind of product work I enjoy most: understanding a complicated business operation, simplifying it, and building software around how the business actually works.

A lot of businesses still manage important operations through combinations of spreadsheets, paper, forms, WhatsApp, email and disconnected SaaS products. Sometimes the answer isn’t adding another tool to the stack. There may already be a system hiding inside the process.

If you’re working through a similar operational problem and want to see more of the products and systems I’ve designed and built, you can find my work here:

[View my portfolio → tifeolayinka.com]

Turning a Care Agency’s Manual Operations Into One Connected System was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.