AMQ / SYSTEMS
Skip to content

Operating Systemfor Service Organisations

Connecting Customer Management, Operations, Workforce, Finance and Reporting through one operational platform.

Explore CareOS

01 / Platform vision

One platform Five connected business domains

CareOS creates one operational model across customer management, operations, workforce, finance and reporting.

Hover, focus or select a domain to inspect the responsibilities it brings into the shared platform.
CareOS

System design

Architecture emerges from analysis.

Technology is selected only after the business process, domain model and platform responsibilities are understood.

  1. 01
    Business ProcessReal operational work defines the starting point.
  2. 02
    Domain ModelProcesses reveal stable entities, states and rules.
  3. 03
    Platform ArchitectureDomains become authoritative services and boundaries.
  4. 04
    ApplicationsInterfaces expose the platform for specific responsibilities.
  5. 05
    EngineeringTechnology is selected to implement the established structure.

Business analysis

Make the operating problem visible.

Analysis turns fragmented observations into a shared understanding of work, responsibility and information.

  • Identify stakeholdersMake roles, needs and decision authority visible.
  • Map operational workflowsUnderstand how real work and information move.
  • Define business domainsGroup responsibilities around stable business concerns.
  • Clarify responsibilitiesEstablish ownership at each operational stage.
  • Discover bottlenecksLocate delays, duplication and missing context.
  • Model business entitiesRepresent the concepts the organisation depends on.
  • Establish terminologyCreate shared language between business and technology.

02 / Operational lifecycle

One operational workflow
Many connected responsibilities

Every service moves through a structured lifecycle — from customer request to workforce coordination, financial settlement and business reporting.

00 / 09

Select a stage to follow its responsibilities through the operational workflow.

Business insight continuously improves future planning, operations and customer experience.

03 / Business Domains

Five business domains
One shared operational model

Every responsibility inside CareOS is organised into a business domain. Each domain owns specific parts of the operational lifecycle while sharing one connected platform.

Workflow ownership / Customer Management

Customer ManagementCRM
  1. Booking Sources
  2. Booking Request
  3. Confirmation
OperationsOPS
  1. Planning
  2. Assignment
WorkforceWF
  1. Execution
FinanceFIN
  1. Settlement
  2. Finance
ReportingBI
  1. Reporting

Purpose

Customer Management

Build and maintain the customer relationship from first contact through confirmed service.

Business value

Provides one trusted customer record across every interaction.

Responsibilities

Records

  • Client Records
  • Households
  • Care Information

Engagement

  • Communication
  • Consent

History

  • Booking History

04 / Platform Applications

One platform
Different interfaces for different responsibilities

Every user interacts with CareOS through an interface designed for their role. Although each application has a different experience, they all operate on the same operational workflow, business rules and shared data.

WEB

Public Website

The public entry point into the CareOS service experience.

Purpose

Customer acquisition and booking.

Primary users

Customers

Business value

Turns customer interest into structured service requests inside the shared platform.

Responsibilities

  • Information
  • Booking
  • Consultation
  • Contact
  • Service catalogue

Related business domains

Customer ManagementOperationsWorkforceFinanceReporting

Connected workflow stages / Website

IN01Booking Sources
RQ02Booking Request
CF03Confirmation
PL04Planning
AS05Assignment
EX06Execution
ST07Settlement
FN08Finance
RP09Reporting

Shared platform model

  1. Applications
  2. Shared Platform
  3. Business Domains
  4. Operational Workflow
  5. Shared Database

One source of truth

Every application shares the same operational reality.

Managers, employees and customers do not maintain separate records. Changes become visible everywhere through one shared platform.

  • Bookings
  • Clients
  • Visits
  • Invoices
  • Reporting

05 / Platform Architecture

Many interfaces
One authoritative platform

Every application interacts with the same operational engine. Business rules, workflows and organisational data are managed centrally so every user works from one trusted source of truth.

  1. ApplicationsWebsiteManagementEmployeeClient · Planned
  2. Platform APIs
  3. Domain Services
  4. Operational Workflow Engine
  5. Shared Database

Purpose

Applications

Different users interact through different interfaces.

Public Website, Management Workspace, Employee Workspace and the planned Client App.

4Applications
5Domains
9Stages

Connects to Platform APIs

Authority

The backend owns business truth.

Interfaces request actions. The backend validates context, applies business rules and returns the authoritative result.

Example 1

Employee checks in

Frontend requests

Check in

Backend validates

  • Assignment exists
  • Visit is active
  • Employee is authorised
  • Timestamps
  • Status transition

The frontend receives the updated visit.

Example 2

Invoice generation

Frontend requests

Generate invoice

Backend decides

  • Billable items
  • Pricing
  • Tax
  • Payment status

The frontend receives the authoritative invoice result.

Example 3

Booking creation

WebsiteEmployeeManager

Frontend requests

Create booking

Backend guarantees

  • One workflow
  • One booking lifecycle
  • One source of truth

Every interface receives the same booking state.

Shared domain model

Business entities remain connected.

CareOS connects organisational context, service delivery, workforce activity and financial outcomes through one shared business model.

Companies

The organisational context for operations.

Architecture principles

One authoritative platform by design.

  • Backend owns business rules
  • Applications never calculate financial outcomes
  • Shared workflow across every interface
  • One operational lifecycle
  • Centralised validation
  • Shared domain model
  • One source of truth

Operational data flow

One action propagates through the platform.

A customer request becomes shared operational state, coordinated work and business insight without creating separate records in each interface.

06 / Engineering Decisions

Engineering follows business architecture

Every technical decision exists to support the operational model introduced earlier. Technology is a consequence of architecture—not the starting point.

Engineering consequence

Technical boundaries follow real operational responsibilities instead of arbitrary feature groupings.

Request journey

One action. Multiple coordinated systems.

A simple Check In request crosses interface, validation, business logic, persistence and communication boundaries without duplicating responsibility.

Employee taps Check In

A role-specific interface requests an operational action.

Website, management and employee interfaces use the same backend services. Business rules remain authoritative regardless of where an action originates.

Technology decisions

Technology follows responsibility.

Each technology is selected for a specific architectural responsibility—not to create a list of tools.

ResponsibilityTechnology
Web ApplicationsReact · Vite
Mobile ApplicationReact Native · Expo
LanguageTypeScript / JavaScript
Backend APINode.js · Express
ORMPrisma
DatabasePostgreSQL
Web DeploymentVercel
Backend HostingRender
Mobile DistributionAndroid APK

Future scalability

Evolution without replacing the core.

The architecture can support new organisations, interfaces and platform capabilities without redesigning the core domain model.

Capability 01

Multi-company

The organisational model can extend across multiple operating companies.

Capability 02

Client portal

A customer interface can reuse the existing workflow, services and records.

Capability 03

Native apps

New clients can consume the same platform APIs and business rules.

Capability 04

AI assistants

Assistance can operate through governed platform services rather than separate data.

Capability 05

Integrations

External systems can connect through stable platform boundaries.

Engineering conclusion

Technology serves business architecture—not the opposite.

07 / Product Evolution

Designed to grow without starting over

CareOS is structured around stable business concepts rather than temporary features. As organisations evolve, new capabilities can be introduced while preserving the existing operational model.

Phase 1

Operational Foundation

Implemented

Current scope

  • Booking
  • Workforce
  • Finance
  • Reporting

Establishes the shared operational model that every later capability can reuse.

Feature evolution

New capability. Existing foundation.

Future capabilities connect to the workflow, domains, services and data already established.

AI Scheduling Assistant

Assists planning through the platform’s existing operational context.

Workflow

  • Planning
  • Assignment

Business domains

  • Operations
  • Workforce

APIs

  • Booking API
  • Employee API

Database

  • Bookings
  • Employees
  • Availability

The assistant consumes governed services. The operational model and backend authority remain unchanged.

Expansion map

One core. More ways to participate.

Existing and future applications remain connected to the same platform core.

Core Platform

  • Shared domain model
  • Workflow engine
  • Platform APIs

Existing Applications

  • Website
  • Management
  • Employee

Future Applications

  • Client Portal
  • AI Assistant
  • Partner Portal
  • Analytics Hub
  • Integrations

08 / About & Methodology

Designing systems from business understanding

CareOS demonstrates my approach to Business Systems Analysis: understanding organisations, modelling operational processes, designing domain-driven architectures, and implementing practical digital solutions that can evolve over time.

  1. Understand
  2. Analyse
  3. Model
  4. Design
  5. Implement
  6. Validate
  7. Evolve

Selected skills

Capabilities organised around outcomes.

Business Systems

  • Process Analysis
  • Requirements Engineering
  • Domain Modelling
  • Systems Thinking

Architecture

  • Platform Design
  • API Design
  • Data Modelling
  • Workflow Design

Engineering

  • TypeScript
  • Next.js
  • PostgreSQL
  • Prisma
  • REST APIs

Data

  • SQL
  • Data Analysis
  • Reporting
  • Dashboard Design

CareOS / Conclusion

CareOS is more than a software concept.

It represents a structured approach to understanding organisations, designing business systems, and building platforms that can evolve with changing operational needs.

View another case studyPortfolio home