Expertise / 04 of 04
Cloud & delivery.
Make releases repeatable and systems easier to operate as the product grows.
Review your release process
When to bring us in
Sound familiar?
- Releases depend on one person remembering the steps.
- You find out about problems when a customer reports them.
- Nobody is sure how the production setup was built.
Why us
What we bring to cloud & delivery.
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.
Benefits
What changes for you.
Routine releases
Deploying becomes a normal step any authorised person can take, rather than an evening one engineer has to set aside.
Problems seen first
Alerts reach your team when something fails, before a customer has to phone and tell you.
Infrastructure you can read
The production setup is written down as code, so a new engineer can see how it was built and why.
A known way back
Rollback and recovery are written down and rehearsed, so undoing a bad release means following steps, not improvising.
Capabilities
Start with the part you need.
- 04.1Cloud architectureChoose and structure cloud services around your product’s data, access and operating needs.Explore ↗
- 04.2Infrastructure as codeDefine environments in version-controlled code, so changes are reviewed and drift is easy to spot.Explore ↗
- 04.3CI/CD pipelinesAutomated builds, tests and deployments, so every release follows the same checked path.Explore ↗
- 04.4Monitoring & supportLogs, metrics and alerts that show problems early, with agreed support for after launch.Explore ↗
What the work includes
Make the route to production understandable.
We work through environments, configuration, access, deployment and visibility so releases do not depend on memory or one person. Operational needs shape the setup, and the team inheriting it gets a clear path forward.
Infrastructure & deployment
Environments and configuration kept in version control and deployed the same way every time.
Observability & recovery
Logs, metrics and alerts that show what the system is doing, and a plan for when it fails.
Ongoing engineering support
A defined scope for maintenance and improvements after launch.
Use cases
Projects we take on.
Codifying a hand-built setup
Bringing cloud resources created by hand in a console under Terraform, so future changes are reviewed and repeatable.
One pipeline, web and mobile
A pipeline that builds, tests and deploys a web app and its API, and prepares the mobile builds for app store submission.
Monitoring a live product
Adding logs, metrics and alerts to a product already in use, with a short runbook for the failures that keep coming back.
Where AI helps
Useful, on a short leash.
Bounded jobs a model can take on inside cloud & delivery work, with a person checking the result.
- Cloud architectureAI evaluation & testing ↗
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.
- Infrastructure as codeAI workflow automation ↗
Summarising planned changes
Turn a long Terraform plan into a short note on what will change, for the reviewer to check against the plan itself.
- CI/CD pipelinesAI workflow automation ↗
Explaining failed builds
Summarise why a pipeline failed from its logs, so the developer starts from a likely cause.
- Monitoring & supportAI workflow automation ↗
Grouping alerts and errors
Cluster related errors and log lines into one incident, so the on-call person sees the pattern rather than the noise.
Where it stops: permissions, releases and decisions that matter stay with ordinary tested code and a named person, not a model’s output.
A practical sequence
How the work runs.
Review how it runs
Understand the application, deployment path, access model and recurring operational problems.
Make releases repeatable
Version infrastructure and configuration, define environments and add relevant delivery checks.
Prepare for operation
Document recovery steps, monitoring needs, responsibilities and the support scope.
Relevant product work
See it in practice.
Home care operations / Our product
SoulCare
Each SoulCare provider gets its own Postgres database. Small Go services run on AWS Lambda behind API Gateway, with sign-in through Cognito and infrastructure defined in Terraform.
Explore SoulCare ↗
Industries
Cloud & delivery by sector.
- 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.
- Medical education A training app on the app stores and the web needs one pipeline that ships every platform from the same tested commit.
- Property & field services Field apps in daily use need releases that don’t interrupt a worker mid-job, and alerts when uploads or payments start failing.
- Fintech & professional services Infrastructure changes need review and a record of who approved them; version-controlled code and pipeline approvals give you both.
What’s changing
Shifts to plan for.
Dates that affect cloud & delivery work, checked against the official sources.
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.
Technologies we use
Tools chosen for the product.
Cost
What shapes the estimate.
Starting point
A setup built by hand with little documentation takes more investigation than one already partly defined in code.
Number of environments
Each extra environment, region or tenant adds configuration to define, test and keep consistent.
Compliance requirements
Audit, access control and data residency rules add review steps and limit what can safely be automated.
Support expectations
Response times, hours of cover and the scope of ongoing work all change the size of the arrangement.
Engagement
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.
Choosing a partner
Questions to ask any provider.
Including us. The answers tell you more than a portfolio does.
Will we have full access to our infrastructure?
Cloud accounts, domains and pipelines should sit with you, so you aren’t tied to one provider to make a change.
How would we roll back a bad release?
If the answer is vague or has never been tried, the first real failure is where you find out.
What do you monitor, and who gets alerted?
Monitoring only helps if someone with the right access sees the alert and knows what to do next.
Could our own team maintain this?
A clever setup nobody in-house understands can cost more to keep running than the problem it was meant to solve.
Common questions
Before you get in touch.
Do you support products you did not build?
We can review an existing product and its infrastructure before agreeing a support scope. Access, documentation, dependencies and the condition of the code affect what is practical.
Do you offer round-the-clock support?
Coverage, response expectations and escalation are agreed for each engagement. We don’t offer a default 24/7 support commitment.
Can you help reduce cloud costs?
We can review resource usage, architecture and operating requirements to identify options. Any saving depends on the current setup and the trade-offs you can accept.
What does handover include?
We agree that with the scope. It can include source and infrastructure repositories, deployment instructions, environment requirements and operating notes for your team.