FAQ / Before we begin
Useful answers for platform decisions.
The best starting point is a clear view of your context. These answers explain how we approach common platform engineering questions and what to expect from working together.
Engagement, technology, and operations
What engagement models do you offer?
We work through focused engineering engagements, defined migration programmes, or ongoing reliability and platform support. Each starts with scope, ownership, decision points, and measures agreed with your team; the model can change as needs become clearer.
Which cloud providers and environments do you support?
Our work spans AWS, Microsoft Azure, Google Cloud, Kubernetes, and hybrid environments. The right pattern depends on your existing estate, regulatory obligations, team capability, and workload needs—not a preference for one provider.
Can you help us build or improve a Kubernetes platform?
Yes. We can assess cluster architecture and operations, create workload onboarding paths, improve GitOps and policy controls, and establish upgrade, recovery, and observability practices. We also help determine when managed containers or a simpler runtime are a better fit.
How do you approach security?
Security is part of platform design and delivery. We work with your risk and security stakeholders to apply cloud-native controls, identity boundaries, encryption, logging, vulnerability checks, policy-as-code, and reviewable change workflows proportionate to the service.
How do you reduce migration risk?
We make dependencies visible, agree migration waves, validate data and service behaviour, and plan cutover and rollback before execution. Where possible, we rehearse the sequence and move a representative workload first. Risk and readiness remain explicit programme measures.
Who owns infrastructure code and cloud resources after delivery?
Ownership is agreed at the start and documented. In most engagements, your organisation owns its cloud accounts, source repositories, and deployment credentials. ForgeSpan contributes through access you authorise, and hands over code, decisions, and operating knowledge.
What documentation do you provide?
Documentation is created alongside the engineering work. Depending on scope, it includes architecture and decision records, module and workflow guidance, service boundaries, runbooks, recovery steps, operational measures, and onboarding notes.
What support coverage is available?
Support can be arranged for agreed operating hours or broader coverage where service needs and resourcing make that appropriate. Response expectations, contact methods, escalation routes, and responsibilities are defined before the support arrangement begins.
What observability tooling do you work with?
We work with existing cloud-native monitoring and established metrics, logs, and traces tooling, and use OpenTelemetry-compatible instrumentation where appropriate. The focus is on useful service signals, actionable alerts, and clear ownership—not collecting data without a question in mind.
How long does a platform engagement usually take?
A focused foundation or workflow can often be delivered in weeks when scope and access are clear. Broader cloud programmes depend on estate complexity, decisions, workload dependencies, and team availability. We set milestones after discovery rather than promising a universal duration.
How is pricing approached?
Pricing reflects scope, delivery team, duration, operational coverage, and dependencies. After a discovery conversation, we provide a clear proposal with assumptions, deliverables, responsibilities, and options for phasing the work.
What happens in a discovery workshop?
We bring the relevant engineering, security, product, and operations perspectives together to map goals, constraints, current architecture, and delivery friction. The output is a prioritised problem statement, initial technical options, key risks, and a recommended next step.
Do you work with our existing engineering team?
Yes. Embedded collaboration is central to our approach. We pair on implementation, involve service owners in decisions, and make knowledge transfer part of delivery so the resulting platform remains understandable and operable by your team.
Still weighing the options?
Bring your real constraints to the conversation.
We can help you decide whether the next step is a discovery workshop, a focused engineering engagement, or ongoing support.