How engagements work
What you are buying when you hire a routing specialist: the shapes an engagement takes, what is written down before work starts, and how the commercial side is agreed.
Routing work is easy to scope badly. "Fix our latency" can mean a two-week measurement exercise or a six-month migration off a single-region load balancer, and the difference is not obvious from outside. So we do the same thing every time: agree in writing what is being done, what exists at the end, and who signs it off. For how the work runs week to week, see the process page.
Three engagement shapes
Nearly all work takes one of three shapes, differing in how long the commitment runs and what exists at the end.
Routing Review
Suits: a symptom with no diagnosis — P99 latency that moves unexplained, an egress bill nobody can attribute, a failover path nobody has exercised.
You get: a written findings document — topology as it actually is, measured path behaviour, ranked findings with their evidence, and a remediation plan your own engineers could execute.
Duration: fixed scope, weeks not months, agreed up front.
How it ends: we walk your team through the document and stop. No obligation to have us implement it.
Design & Implementation Project
Suits: a decision already made — a multi-region build-out, transit gateway consolidation, an Anycast or GSLB rollout, a move to active-active against a defined RTO and RPO.
You get: design docs, infrastructure-as-code, health-check and failover configuration, a cutover runbook with a rollback path, and the cutover itself.
Duration: milestone-based, each with its own deliverables and acceptance criteria, so progress is visible rather than asserted.
How it ends: at a handover milestone — documentation transferred, runbooks rehearsed with your on-call, and an agreed period of post-cutover support.
Ongoing Advisory Retainer
Suits: platform and SRE teams who make routing decisions often enough to want a specialist on call, but not often enough to hire one.
You get: a standing block of engineering time each month — design review before you commit to a topology, a second pair of eyes on BGP policy and TTL changes, post-mortem support, and a periodic check that failover still fits your traffic.
Duration: a rolling term with a defined notice period; how unused time carries over is in the agreement.
How it ends: on notice, from either side. Documentation stays with you.
Shapes often follow one another — review, project, retainer — but each is agreed separately. Finishing one does not commit you to the next.
What every engagement includes, regardless of shape
A written scope, agreed before work starts
Deliverables, boundaries, assumptions and acceptance criteria, signed by both sides. If it is not in the scope document, it is not in the engagement.
A named engineer accountable for the outcome
One person owns the result, attends the calls and answers for the technical decisions. No account manager relaying questions to someone you never meet.
Work in your own accounts
We work inside your cloud accounts, repositories and IaC, under credentials you issue and can revoke. Nothing lives in a CloudRoute-owned environment you cannot inspect: no black box, no dependency on us to read your own configuration.
Documentation you keep
Diagrams, decision records, runbooks and configuration land in your systems in a format your team can edit. We do not withhold artefacts as leverage.
A handover
An explicit end, not a fade-out: a walkthrough with the people who will own the system, a rehearsal of the failure paths, and what we would watch next.
How scope is agreed
Four steps, in order. Nothing is billable until step three is signed.
| Step | What happens |
|---|---|
| 1. Discovery call | You describe the symptom or goal; we ask about topology, traffic profile, providers, regions and what you have tried. |
| 2. Current-state review | A short read-only look at the relevant accounts and monitoring — enough to scope honestly, not the assessment itself. |
| 3. Written proposal | Deliverables, milestones, acceptance criteria, exclusions, dependencies on your team, fixed quote. |
| 4. Change order | If a finding changes the shape of the work, we stop, write down the change and its effect on timeline and cost, and wait for approval. |
Acceptance criteria matter more than they sound. "Improve failover" is not one; "DNS failover completes inside the agreed detection window at the specified health-check interval and record TTL, demonstrated in a game day" is. Targets are written as targets — the SLO a design aims at — and how they get measured is settled in advance.
What we need from you
Three things, and they are usually the difference between a date that holds and one that does not.
- Read access to the relevant cloud accounts — VPC and routing configuration, load balancer and DNS settings, flow logs and whatever monitoring exists. Write access, where implementation needs it, is scoped separately with your security team.
- A technical counterpart who can answer architecture questions without escalating — someone who knows why the topology looks the way it does. That history is rarely written down and is often the fastest route to the cause.
- A decision-maker with authority to approve a design and accept a milestone. Not on every call, but reachable when a decision blocks work.
To be blunt: client-side delay is the most common cause of a slipped date on this work — access that takes three weeks to provision, a change window that keeps moving, a decision waiting on someone who is travelling. Proposal timelines state plainly which dates depend on you.
When we would turn work down
A specialist who takes everything is not a specialist. Three cases get a no, on the first call rather than after a paid discovery phase.
The problem is application-level, not network-level
A large share of "the network is slow" turns out to be an N+1 query, a cold cache, a synchronous call to a third-party API, or a thread pool that saturates under load. Network tuning fixes none of those. We will say where to look, but we are not the people to fix it.
The traffic volume does not justify the engineering
Anycast, active-active and custom BGP policy carry real operational cost: more failure modes, more to reason about at 3am, more to keep current. Below a certain scale a single-region deployment with a sane recovery plan is the better answer, and we will say so even though it is the smaller engagement.
Another specialism fits better
Application security review, database performance, cloud cost management, platform migration: these touch routing at the edges but are not what we do. Where we know the shape of the answer we will describe it, so you can brief someone else.
The FAQ covers more boundary cases; the services pages — routing consulting, traffic optimization, multi-cloud architecture, reliability and failover — set out what does.
How pricing is set
We do not publish rates — not as a negotiating tactic, but because a published number for work this variable misleads in both directions. A two-region review of one AWS account and a four-provider active-active redesign under a regulated change process are not the same job. A quote is built from:
- Scope — what is in, what is explicitly out, how deep the analysis goes.
- Duration — how many weeks of focused engineering the deliverables need.
- Environments and regions — every extra account, provider, region and production-like environment adds surface area to review and to change.
- Whether implementation is included — advising on a design is a different commitment from building it, running the cutover and standing behind the rollback path.
- Urgency — work that displaces other commitments, or runs inside a compressed change window, is scoped differently.
Those inputs produce the fixed quote in the step-three proposal. If scope changes, the change-order process applies: written first, approved second, worked third. You will never receive an invoice for work that was not agreed in writing beforehand.
Engagements run remotely for clients worldwide from San Francisco, as they have since 2010. Numbers we can publish are on the results page, framed as what was measured rather than as a promise about your environment.
Start with a call, not a commitment
Email [email protected] with two lines about the symptom or the goal. No form, no phone queue: the message reaches the engineers who would do the work, and you get a reply within one business day during Mon–Fri, 9:00–18:00 Pacific.
Start a conversation Read the technical insights