FAQ / Straight answers to useful questions

Before we start building.

A few things organisations ask when they are choosing a cloud partner or deciding what their platform needs next.

12 questions

Start with the question you have.

How do we choose between AWS, Azure and Google Cloud?

We start with your workloads, existing capabilities, data location and sovereignty needs, operating constraints and commercial position. The goal is a decision you can explain and support—not a cloud choice based on a generic ranking.

What happens in an initial discovery?

We agree the decision to be made, talk with the people affected, review current systems and constraints, then share findings, risks and a practical next-step plan. Discovery is scoped and time-boxed before it begins.

Can you take over a cloud migration already in progress?

Often, yes. We first establish what has moved, what remains, what controls are in place and where the schedule depends on assumptions. We can then help re-sequence delivery, improve assurance or add specialist capacity.

Who owns the platform after the engagement?

Your organisation does. We design for your named owners, repositories and operating model, and include documentation, pairing and transition criteria so the team can maintain and extend the platform.

When is Kubernetes a good fit?

Kubernetes can help when teams need consistent orchestration and have the capability to operate the control plane and workload patterns. It is not the default for every service; managed application or simpler container services may be more appropriate.

How do you approach cloud security?

We turn your obligations and threat context into practical identity, network, encryption, logging and workload controls. Automated checks are paired with clear exceptions, ownership and evidence; security decisions remain explicit.

Can you help us control cloud costs?

Yes. We improve allocation and show cost in the context of teams, products and usage. We then work with engineers and budget owners on forecasts, rightsizing and commitments, without treating every cost reduction as a success if it harms reliability.

What does handover include?

Handover is built into delivery: maintainable code, architecture decisions, operating guides, ownership and alert routes, access model, training and a clear acceptance checklist. We test the process with the receiving team before stepping away.

How do embedded engineers work with our team?

Embedded engineers join agreed ceremonies and repository practices, work toward a defined outcome, pair with your staff and review progress regularly. They are not a substitute for a decision owner or product priority.

Do you provide ongoing support?

Support is available to clients with an agreed support arrangement. Standard support is Monday to Friday, 09:00–17:30 UK time, excluding UK public holidays. Response objectives, coverage and any out-of-hours escalation are set out in the engagement schedule.

How long does a typical engagement take?

A discovery or design sprint may take one to three weeks. A platform delivery or migration programme may span several weeks or months depending on risk, dependencies and team availability. We agree milestones and review scope as evidence changes.

Can you work with teams across different locations?

Yes. We work remotely and in person where agreed, use written decisions and demonstrations to keep work visible, and schedule collaboration around the teams involved. Workshops and pairing are planned to be useful across time zones.

Have a situation that does not fit a FAQ?

Tell us what you are weighing up. We will help you understand whether and how we can be useful.

Talk it through