Cloud engineering
We deploy into cloud accounts you own, on Azure or AWS, and hand over the pipelines with the code. One client asked us to build so they could leave a SaaS vendor entirely, and now they host the whole platform themselves.
Book a 30-minute scoping call See the deployments
If your current setup works and the bill is sane, we will tell you to leave it alone.
| Who owns the account You, or your last supplier | Day 1 |
|---|---|
| Where data must sit Region and residency rules | Day 1 |
| What the bill is now And what drives it | Day 1 |
| Who can deploy And who reviews it | Day 1 |
| How you would leave us Written down at the start | Day 1 |
The honest question first
Migrations get sold on cost savings and then deliver a similar bill with new problems. There are good reasons to move. Cost alone is usually not one of them.
Stay where you are when
A migration here buys you risk and a project plan. We will say so.
Worth moving when
The IoT Workz project was exactly this. They now own the platform and the data outright.
Plain definitions
The second one changes the cost by a factor of five, and it usually gets decided by accident.
Four things, in order. An assessment of what runs where and what it depends on. A landing zone, meaning the accounts, networks, identity and guardrails your systems will live inside. The move itself. Then the cutover, which is the only part anybody sees.
The assessment is the part people skip and the part that decides everything else. Half the systems in a typical estate turn out to depend on something nobody documented.
Rehosting moves the system as it is onto cloud servers. Nothing improves, but the move is quick and the risk is contained. Replatforming swaps components for managed equivalents, so the database becomes a managed database and the file share becomes object storage. Rebuilding rewrites the system for the cloud.
Two more options get forgotten. Retire the systems nobody uses, and retain the ones with no case for moving. On most estates those two cover more machines than anybody expects, and they are the cheapest wins available.
What we build
What people ask us for
Cost reduction is the reason people give and rarely the reason that holds up. These are the ones that do.
Our work
Case study, IoT platform
IoT Workz was locked into a SaaS vendor with fragmented integrations and no white labelling. The brief was ownership. We built on Docker and Kubernetes with Keycloak for identity, HashiCorp Vault for secrets, Kafka and TimescaleDB behind it, and Prometheus with Grafana watching the whole thing. It runs on their infrastructure, not ours.
On the managed side, we run production workloads on Azure and on AWS for clients in Norway and Germany.
Technology
This list is what we have deployed and handed over, rather than everything the clouds offer.
Who does the work
Infrastructure gets judged the first time something breaks at an inconvenient hour, which is usually long after handover. Twenty people means the person who built your environment can still be asked about it.
You interview whoever we put forward. A fair question is how they would hand the environment back to you, and whether they have written that down before.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Whichever your organisation already has skills and agreements for. We ship on both. Picking the one your team cannot support after we leave is a false economy.
No. The account is in your name and you grant us access, which you can revoke at any time.
Sometimes, but we do not lead with it. Ownership, data residency and the ability to deploy without waiting are the reasons that hold up.
Probably not. It earns its keep on multi-tenant platforms and large workloads. For a handful of services it adds operational cost you will feel every week.
We deploy in the region your policy requires. For the Norwegian platform this included meeting national educational data protection rules.
You keep the account, the pipelines, the definitions and the documentation. We write the exit into the arrangement at the start rather than at the end.
The assessment is two to three weeks and produces the only estimate worth trusting, because until you know what depends on what every number is a guess. A single system rehosted with its data is a short project. An estate move with a landing zone, several systems and a real cutover is a long one. Running costs are separate and continue forever, which is why we look at the bill first.
We work in whatever your team already runs, and where there is no existing choice we keep environment definitions in version control alongside the code. Our own production deployments are Docker and Kubernetes rather than a large Terraform estate, so if you are hiring specifically for deep Terraform module work, say so and we will tell you honestly whether we are the right team.
We build to the controls those frameworks ask for, and we do not issue certificates. Access enforced at the server, secrets in a vault, audit trails, residency and retention, all set up during the build rather than retrofitted before an assessment. The certificate itself comes from an accredited firm, and we work alongside them and fix what they find.
If the answer is a former supplier, that is worth fixing before anything else. Thirty minutes is enough to establish where you stand.
