Cloud & delivery / Capability
Cloud architecture.
Choose and structure cloud services around your product’s data, access and operating needs.
Review your release process
When to bring us in
Sound familiar?
- Our cloud account grew one service at a time and nobody can explain it.
- Customers are asking how their data is separated from everyone else’s.
- The bill keeps rising and we can’t say which part of the product causes it.
The cost of leaving it
The account keeps growing one service at a time, and so does the bill. When a customer asks how their data is kept apart, the answer takes a week to assemble.
Why us
What we bring to cloud architecture.
Infrastructure kept in code
Our own products run on AWS with infrastructure defined in Terraform, so environments can be reviewed and rebuilt.
Data kept apart by design
In SoulCare, each care provider has its own PostgreSQL database rather than sharing tables with everyone else.
Accounts set up in your name
Cloud accounts and databases are yours from the first day, not something to transfer at the end.
What the work includes
Design for how the product will be run.
We start from the product’s data, users and obligations: where data must live, who can reach it and what happens if a component fails. Services are chosen for the team that will operate them, not for novelty. Decisions and trade-offs are written down so they can be revisited later.
Architecture review
An assessment of the current setup, its risks and what the product needs next.
Data and tenancy design
Where data lives, how customers are separated and how it is backed up.
Access and security
Identity, network boundaries and least-privilege access for people and services.
Cost and capacity
Service choices and sizing that match real usage, with visibility of what drives the bill.
Use cases
Projects we take on.
Separating customer data
A multi-customer product reworked so each organisation’s data sits in its own database or schema.
A first production setup
A product moving off a prototype host into a cloud account that can answer a customer’s security questionnaire.
Reviewing an expensive account
An account that grew over years mapped service by service, with options to reduce both spend and risk.
What you get
Outputs you can review.
- Architecture diagrams
- Written architecture decisions and trade-offs
- Data isolation and backup design
- Access model for people and services
- Cost breakdown by component
Technologies we use for this
Where it matters
- Health & social care Where each care provider has its own database and access rules, environments, backups and schema changes have to be managed per provider.
- Fintech & professional services Infrastructure changes need review and a record of who approved them; version-controlled code and pipeline approvals give you both.
Where AI helps
Useful, on a short leash.
Choosing where models run
Decide between hosted model APIs and models in your own cloud account, based on where data may go and what it costs.
AI evaluation & testing ↗Searching runbooks and decisions
Let engineers ask how the system is set up, with answers drawn from architecture notes and runbooks.
Knowledge assistants ↗
Where it stops: Where data is hosted and who can reach it are decisions with legal weight. They are made and recorded by people.
What’s changing
Shifts to plan for.
June 2026
Amazon Linux 2 reaches end of life
Amazon Linux 2 reached end of life on 30 June 2026. Lambda runtimes built on it, such as Python 3.10 and 3.11 and older Java, get limited patches until their own deprecation dates.
April 2026
Lambda deprecates Node.js 20
Lambda stopped patching the nodejs20.x runtime on 30 April 2026. Creating functions on it is blocked from 29 July 2027 and updating them from 31 August 2027.
April 2026
MySQL 8.0 reaches end of life
Oracle moved MySQL 8.0 to Sustaining Support, so Oracle no longer releases security fixes for it. Oracle recommends moving to MySQL 8.4 LTS or 9.7 LTS.
Process
How the work runs.
List the obligations
Data residency, retention, uptime expectations and customer security requirements are written down first.
Map current and target
We draw what runs today and what it should become, and mark the differences that matter.
Record each decision
Every significant choice is logged with the options considered and the reason one was picked.
Order the changes
Work is sequenced so the riskiest or most valuable changes land first, without a single big switch.
Cost
What shapes the estimate.
Current state
An undocumented account takes longer to map than one already described in code.
Compliance needs
Data residency and customer audit requirements add design and documentation work.
Depth of change
A review with recommendations is smaller than redesigning and moving live services.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Relevant product work
See it in SoulCare.
Each SoulCare provider has its own PostgreSQL database, with Go services running on AWS Lambda behind API Gateway.
Explore SoulCare ↗
Common questions
Before you get in touch.
Which cloud provider should we use?
Often the one your team or customers already use. We work with AWS, Azure and Google Cloud and recommend based on your existing setup and requirements.
Can you review an architecture without rebuilding it?
Yes. A review can stand alone, with findings and a prioritised list of changes your own team can carry out.
What affects the scope?
The number of services and environments, data residency and isolation requirements, existing documentation and how much change is needed.
Further reading
- MySQL 8.0 has reached end of life: planning the move to 8.4 What MySQL 8.0’s end of life means, and how to plan, test and roll back an upgrade to MySQL 8.4 LTS.
- One database per tenant: isolating customer data in SaaS When each customer gets its own PostgreSQL database, and what that means for migrations, connections and running costs.
- Terraform from day one: infrastructure as code that lasts How to start with Terraform in the first environment, so infrastructure stays reviewable and a new team can take it over.