DevOps and Cloud Services
We run infrastructure for products where downtime has a phone number attached to it. That tends to make you conservative in useful ways.
A lot of DevOps work sold to small and mid sized companies is architecture theatre: a Kubernetes cluster for an application that would be happier on two servers and a managed database. We have inherited several of those and the pattern is consistent. The cluster is impressive, nobody understands it, and the person who built it has left.
Our bias is towards the smallest infrastructure that meets your actual availability requirement, with complexity introduced only when something forces it. Sometimes that is genuinely Kubernetes, as it is for Oly Care. Sometimes it is Forge and a well configured server, and admitting that is worth more to you than a diagram.
What we take on
- /AWS architecture and migration, including the unglamorous cost review that usually pays for the engagement.
- /CI/CD pipelines that run tests, build assets and deploy without a human holding a runbook.
- /Containerisation with Docker, and Kubernetes only where the workload justifies it.
- /Observability: logs, metrics, traces and error tracking wired up so an incident starts with evidence rather than guesswork.
- /Hardening and compliance driven hosting, including CJIS compliant environments and single country requirements.
- /On-call, with a rota and an escalation path rather than a hopeful Slack message.
Incidents are a process problem
Most outages we get called into are not caused by exotic failures. They are caused by nobody knowing who is responsible, no alerting on the thing that broke, and a deploy process risky enough that the team avoids shipping the fix.
So we start with the boring layer. Alerts that fire on symptoms users feel rather than on CPU graphs. A deploy that can be rolled back by one person under pressure without reading documentation. A written escalation path with names on it. None of this is interesting to talk about and it removes most of the three in the morning phone calls.
Security work we do by default
Databases and caches bound to localhost rather than every network interface. Firewalls actually verified rather than assumed. SSH keys audited and rotated when people leave. Security updates applied on a schedule instead of during an incident.
None of that is advanced. It is just the set of things that turns up in every audit we run on infrastructure we did not build, including our own when we go looking honestly.
Work we have actually shipped
Infrastructure we currently run or have hardened.
AWS with Kubernetes behind a healthcare staffing platform handling credentialing, shift operations and payroll. Multi year retainer, which means we live with our own architectural decisions rather than handing them over and leaving.
A CJIS compliant hosting environment on AWS for a platform used by US law enforcement across six states, where the compliance boundary shapes the architecture rather than sitting on top of it. We carry the on-call.
Six years of continuous production on AWS with Redis and PostgreSQL, serving thousands of pilots. Long enough that we have migrated it, upgraded it and been paged by it, which is the only honest way to learn what an architecture costs.
Platform hardening for a collaborative B2B risk intelligence product on Python and FastAPI, with Sentry for error tracking, as the system moved from working to scaling.
Questions we get asked
Do we need Kubernetes?
Probably not. Most products under serious load are still fine on managed services and a small number of well configured servers. Kubernetes earns its complexity when you have many services, real elasticity requirements or a platform team to own it. We will say so when the answer is no.
Can you take over infrastructure nobody currently understands?
Yes, and it is a large share of what we get asked to do. We start with an audit: what exists, what is exposed, what is costing money for nothing, and what would happen if the one person who set it up were unavailable. You get that document whether or not you continue with us.
Do you provide on-call?
For clients where we run the platform, yes, with a rota and a defined escalation path. We do not offer on-call for systems we have not been allowed to fix, because being paged for a problem you are not permitted to solve helps nobody.
Can you host inside a specific country or compliance regime?
We have delivered CJIS compliant hosting for US law enforcement and Swiss only hosting including a self hosted speech stack. Tell us the constraint at the start, because it changes the design rather than the deployment.
Tell us what you are building
We will tell you honestly whether we are the right team for it, including when the answer is no. First reply usually comes the same working day.