Plan the connection before you buy the gear

PLAN · 10 MIN · LAST FACT-CHECKED JULY 16, 2026

Most connectivity projects begin with a product question: Which router? Which Starlink? Which antenna? Which carrier?

We would start one step earlier. Write down what has to work, where it has to work, and what can happen when it does not. Those answers determine whether you need one good connection, a manual backup, automatic failover, or a managed multi-path system.

The goal is not the most hardware. It is the simplest system that handles the real consequence of an outage.

The short answer

Before you buy anything, answer six questions:

1. What must keep working?
2. Where will the system be used?
3. What connection paths are realistically available there?
4. How much interruption is acceptable?
5. What power, mounting, and cable constraints exist?
6. Who will operate and support the system after installation?

If you can answer those in plain language, equipment selection becomes much easier. If you cannot, a longer product list usually creates more uncertainty rather than less.

1. Start with the work

“Fast internet” is not a useful requirement on its own. A better requirement names the application, the number of simultaneous users, and the behavior that matters.

Application requirements are often lower than people expect, but a speed test is only part of the picture. Microsoft’s current Teams planning guidance, for example, lists recommended per-endpoint bandwidth in the low single-digit Mbps range for common video scenarios and notes that actual use varies with resolution, layout, and frame rate. Microsoft also treats packet loss, round-trip time, and jitter as important contributors to call quality. (Microsoft Teams network planning; Microsoft call-quality guidance)

That is why a connection with an impressive download result can still produce a poor call. The workload should define the test.

2. Describe the environment honestly

An RV in an open desert site, a trawler near shore, a cabin under tall trees, and a construction trailer beside a city all have different options.

Record:

• The locations or routes you actually use.
• Whether the system operates while parked, at anchor, underway, or all three.
• The likely view of the sky.
• Cellular service from more than one carrier.
• Available fixed service, marina or campground Wi-Fi, or a nearby building connection.
• Interior materials that may reduce radio performance.
• Heat, cold, salt, dust, vibration, and water exposure.
• Height limits, roof penetrations, and cable routes.

Coverage maps are a starting point, not an acceptance test. The FCC says its mobile map shows where a consumer should be able to connect outdoors or in a moving vehicle; it does not show indoor coverage. The underlying provider maps are propagation models with defined speed and receiver assumptions. (FCC map guide; FCC mobile map methodology)

Satellite has a different environmental constraint. Starlink’s own installation guidance says the terminal needs a clear view of the sky and that objects such as branches, poles, or a roof can interrupt service. Its app includes an obstruction check for evaluating a potential location. (Starlink installation guide; Starlink obstruction guidance)

Neither map replaces a site visit or a real test under the conditions that matter.

3. Decide what failure is allowed to look like

This is the question that changes the architecture.

A brief interruption is acceptable

One well-chosen connection may be enough. Keep a phone hotspot or second option available for manual recovery. This is often sensible for occasional travel, personal use, or work that can tolerate a reconnect.

New traffic should move automatically

Use a router that can monitor more than one upstream path and fail over when the preferred path becomes unusable. A meeting or VPN may still reconnect when the public path changes. That can be acceptable if the interruption is short and understood.

Active sessions should survive a path failure

This is a more demanding requirement. It may call for a tunnel or bonding service that keeps a consistent remote endpoint while traffic moves among available links. It adds configuration, data use, and another service dependency. Test it with the real application; do not infer session continuity from the word “failover.”

The site must remain reachable without a local operator

Now connectivity is an operating system, not just equipment. Add monitoring, remote recovery, documented account ownership, stable power, escalation paths, and a clear maintenance plan.

4. Choose a system pattern

Pattern 1: one good path

Shape: primary connection → router or gateway → local network

Good fit: ordinary browsing, entertainment, occasional travel, or a site where manual recovery is acceptable.

Trade-off: when the only upstream path stops, the internet stops.

Pattern 2: a path and a fallback

Shape: primary + backup → multi-WAN router → work network

Good fit: remote work, point-of-sale, and connection-sensitive travel.

Trade-off: better continuity requires another plan or service, more power, configuration, and a test procedure.

Pattern 3: a system someone can operate

Shape: multiple independent paths → managed policy or tunnel → segmented local network → monitoring and support

Good fit: fleets, vessels, remote sites, public-safety or field operations, and unattended equipment.

Trade-off: operational resilience requires ongoing ownership. Buying the equipment is the beginning, not the handoff.

5. Check whether the backup is meaningfully different

Two connections are useful only to the extent that they do not share the same likely failure.

Ask:

• Do two cellular plans use different underlying carrier networks?
• Do both paths depend on the same roof antenna, cable entry, router, or power circuit?
• Will trees block the satellite path at the same place where cellular is weak?
• Does one billing or account problem disable both services?
• Does the backup have enough data and capacity for the essential workload?

Independence is not all-or-nothing. A cellular link and a satellite link can fail for different reasons, but they may still share local power, cabling, or router hardware. Record the shared dependencies rather than calling the system redundant and moving on.

6. Include the physical installation

A good network diagram that ignores the install is incomplete.

For every device, write down:

• Normal and peak power requirements.
• Whether it needs AC, DC, or Power over Ethernet.
• Fuse, breaker, and wire requirements where applicable.
• Mounting surface and fasteners.
• Cable type, length, bend radius, entry, strain relief, and weather sealing.
• Ventilation and temperature limits.
• How a technician will inspect or replace it later.

For off-grid systems, estimate daily energy from measured use when possible:

average watts × hours of operation = watt-hours per day

Then include conversion losses and a reserve appropriate to the power system. Nameplate ratings help with circuit design, but measured average use is usually more useful for energy planning.

A one-page connection brief

Copy this before the first shopping list:

Environment

• Place or route:
• Stationary, moving, or both:
• Sky view and obstructions:
• Weather, vibration, salt, dust, or heat:

Essential work

• Applications that must work:
• Simultaneous users and devices:
• Largest routine upload or download:
• Remote-access or public-IP needs:

Existing equipment and services

• Fixed connection:
• Cellular carriers or plans:
• Satellite hardware or plan:
• Router, antenna, switches, and access points:

Failure requirement

• Acceptable interruption:
• Manual or automatic recovery:
• Must an active call or VPN survive a path change?
• Must the site remain reachable while unattended?

Installation

• Available power:
• Roof or exterior mounting limits:
• Cable paths and entry points:
• Service-access constraints:

Ownership

• Account owner:
• Day-to-day operator:
• Monitoring owner:
• Support contact and escalation path:

What we would do

We would finish this brief, identify the simplest viable pattern, and test the uncertain assumptions before specifying hardware. That might mean checking the satellite view, testing two carriers at the site, measuring power, or tracing a cable route.

If one connection and a phone hotspot meet the real requirement, stop there. If an outage stops work, define the fallback behavior before choosing the router.

Next: Cellular, satellite, or both? How to choose a connection stack.

Sources

• FCC: How to use the National Broadband Map
• FCC: Mobile broadband availability map methodology
• Microsoft: Prepare your organization’s network for Teams
• Microsoft: Network conditions and video-call quality
• Starlink: Installation guide
• Starlink: Obstruction-map guidance

Editorial note: Product specifications, service terms, and plan availability change. Verify current first-party documentation before selecting or installing equipment.