How I Plan Mobile Connectivity for AI Demos and Field Work

An AI demo can be technically solid and still fail because the room has bad guest Wi-Fi. The same problem appears when working from a client office, construction trailer, event venue, or anywhere else outside a controlled workstation. Repository access, remote inference, authentication, cloud storage, and a live dashboard all depend on a connection that the engineer may not control.

I treat connectivity like every other production dependency: define the workload, remove shared failure points, and make the software recover when the network disappears.

Map the workload before choosing a plan

A video call and a Git pull are not the same workload. Neither is comparable to uploading a model artifact, moving a batch of reference images, or controlling a remote GPU workstation.

For each field session, I identify:

which parts of the demo run locally;
which services require authentication or an API call;
how much data needs to move in each direction;
whether a laptop or tablet will use a phone hotspot;
which files must be available before arrival;
what the audience sees if a request times out.

This prevents a common mistake: buying a plan around a headline speed while ignoring hotspot allowance, upload stability, coverage inside the building, or what happens after a usage threshold.

Local-first does not mean network-free

I build many tools to run locally because that improves privacy, cost control, and responsiveness. But a local model still may need documentation, source control, license verification, remote collaboration, or a delivery path. The network footprint is smaller, not zero.

The useful design question is: what must remain operational when the connection is unavailable?

A strong field setup has the model, runtime, packages, sample data, and presentation assets already on the machine. The connection then supports updates, collaboration, and optional remote capacity instead of being the only thing holding the demo together.

Use a real fallback

Two devices on the same carrier can still share the same outage or congestion problem. When the session matters, the backup should be independent: another network, a pre-approved client connection, a known wired location, or a fully offline demo path.

My minimum preparation looks like this:

Clone the exact repository and verify the target commit.
Cache the packages, model weights, and documentation I may need.
Run the demo with networking disabled.
Prepare a short recorded result for anything that requires remote infrastructure.
Test hotspot behavior with the actual laptop, not only the phone.
Carry charged power banks and known-good cables.

The recorded fallback is not a substitute for a working product. It is a way to keep the conversation moving if the venue network fails.

Test the actual location when possible

Coverage maps help narrow choices, but buildings change the result. Steel, concrete, below-grade rooms, crowd density, and the distance to a window can all affect performance. A parking-lot speed test does not prove the conference room will work.

I care about upload speed, latency, packet loss, and stability over time. A quick burst of high download speed is less useful than a connection that can maintain a remote shell or finish an upload without restarting.

Before moving multiple lines or buying hardware, I would pilot the setup at representative locations and record the result. The best carrier is the one that works where the work happens.

Make the application tolerate interruption

Connectivity planning should reach into the software. Long operations need checkpoints. Transfers should resume. Writes should be idempotent so a retry does not duplicate data. The interface should distinguish pending, failed, and completed actions.

For higher-risk actions, a disconnected system should fail safely and require review after reconnecting. Redundant service does not justify an invisible retry that can alter client data twice.

Protect client information

Using cellular service does not remove security obligations. I use current devices, multi-factor authentication, encrypted services, and the client's approved VPN or access method. I do not copy protected files into a personal sync account because it is faster in the moment.

Before field work, the team should agree on what may be stored locally, who can access the system, how a lost device is handled, and what logs must be retained. The connection is only one layer of the operating environment.

Compare the full cost with the failure cost

The correct plan is not necessarily the most expensive one. I compare the recurring cost with the cost of the actual constraint: travel to find Wi-Fi, an interrupted client session, idle collaborators, failed uploads, or time spent reconstructing incomplete work.

If a better mobile setup removes those failures in the places I regularly work, it is infrastructure. If it does not change uptime or delivery, it is not the bottleneck.

That is the same rule I use across AI systems: measure the failure, design around it, and buy capacity only after understanding what the workflow needs.