SpaceX wants Starlink Mobile to compete with AT&T, T-Mobile, and Verizon. The company says its service could eliminate dead zones, and Gwynne Shotwell has described a future where Starlink broadband dishes also act as small cellular base stations. Ars Technica reported that SpaceX plans to use distributed equipment rather than traditional large cell towers.
Whether those claims hold up is not the decision small businesses need to make this week. The useful signal is that connectivity infrastructure is becoming more distributed, more software-defined, and harder to evaluate using old assumptions.
The question is not whether Starlink will beat the major carriers. The question is whether your business can keep working when the network changes underneath it.
Connectivity is not the same as resilience
A stronger connection does not automatically produce a resilient operation. It only improves one layer of the system.
A plumber still needs to receive a lead, confirm an appointment, access the customer record, send a quote, collect payment, and follow up after the job. A salon still needs its booking calendar and client messages to work during a broadband outage. A restaurant still needs to communicate with delivery partners and customers when its primary connection fails.
Those workflows cross several dependencies:
- The local internet connection
- The router, modem, or Starlink terminal
- DNS and authentication services
- Cloud software and APIs
- Customer communication channels
- Payment and scheduling providers
- The employee who has to decide what happens next
If any one of those layers fails, the business may appear offline even when the connection itself is available.
That is the mistake we keep making with infrastructure announcements. We evaluate the speed of the pipe and ignore the shape of the work flowing through it.
The hidden risk is infrastructure coupling
Most small-business software is built around a stable network assumption. The application expects a persistent session, a reachable API, a known device, and an employee who can see the latest state.
That assumption is fragile.
A business may move from cable to fiber, add Starlink as a backup, switch mobile carriers, install a new router, or rely on a phone hotspot during an outage. Each change can affect IP addresses, latency, DNS behavior, firewall rules, device authentication, and how quickly a failed request is retried.
The software may not crash visibly. It may do something worse. It may create uncertainty.
A customer sends a message, but the owner cannot tell whether it was delivered. A payment screen times out, but the charge succeeds. A lead is entered twice because the first submission looked like a failure. An appointment is moved in one system but not another. A follow-up disappears because the job that should have scheduled it never completed.
These are not telecommunications problems. They are workflow design problems exposed by telecommunications changes.
The best resilience work makes the network less important to the business outcome. That means the system must preserve state, make failures visible, and recover without asking an already busy owner to reconstruct what happened.
What most software evaluations miss
When a small business evaluates a new operational tool, the conversation usually centers on features, integrations, and monthly price. Network behavior gets reduced to one question: Is the app cloud-based?
That is not enough.
You need to ask what happens when the connection disappears at each step of the workflow. A useful evaluation should answer five questions.
1. What state is preserved?
If a lead form is submitted during an outage, does the system queue it locally, save a draft, or lose it? If an employee reconnects from a different network, can they see the exact status of the work?
A workflow that cannot preserve state is not automated. It is a fragile series of browser sessions.
2. What happens when an action is uncertain?
Every external action needs a clear result: completed, failed, or pending verification. Payment, email, SMS, calendar updates, and CRM changes should not depend on someone guessing after a timeout.
This is where idempotency matters. If the same request is retried, the system should not send two messages or create two appointments. Small businesses do not need the term in their interface, but they need the behavior in their software.
3. Can the business operate in a degraded mode?
A resilient system does not require every feature to remain available. It identifies the minimum viable operation.
During a network failure, a salon may need to view tomorrow’s appointments and record new bookings for later entry. A contractor may need access to the day’s job list and customer phone numbers. A gym may need to check memberships and communicate a closure.
Design for those narrow fallback paths before you need them.
4. How does recovery work?
When connectivity returns, queued work should reconcile automatically. The owner should see what was completed, what failed, and what needs attention.
Recovery should not mean comparing text messages, handwritten notes, and three browser tabs. If the system cannot explain its recovery process, treat that as an operational risk.
5. Can you change infrastructure without rebuilding the business?
Your software should not be permanently coupled to one carrier, one device, or one office connection. Test it from the primary network, the backup network, and a mobile hotspot. Use a separate device if possible.
If moving networks breaks authentication, blocks a key integration, or makes the dashboard unusable, the system has an infrastructure dependency that should be documented and fixed.
A practical resilience test for this week
You do not need an enterprise disaster-recovery program to find the dangerous gaps. Run a 30-minute tabletop test with one person who understands the business and one person who uses the software every day.
Pick the most valuable workflow, such as new lead to booked appointment. Then simulate these conditions:
- The primary internet connection fails for 20 minutes.
- The backup connection has high latency.
- A request times out after the customer clicks submit.
- The employee changes devices during the incident.
- Connectivity returns after several actions were performed manually.
Record four things: what the system saves, what it duplicates, what it hides, and what the owner has to remember.
That last category is the most important. Human memory is a poor recovery system. If the business depends on someone remembering which customers called during an outage, the workflow is not resilient yet.
This builds on the lesson from Zoox’s Paid Robotaxis Expose the Real Autonomy Test: autonomy becomes real when customers pay for dependable outcomes. Infrastructure resilience applies the same standard one layer earlier. The software must continue producing a trustworthy outcome even when its environment is unstable.
It also extends the workflow argument from Ambrook’s $30M Bet: Own the Workflow. Owning a workflow means owning its exceptions too, including the moments when the network, device, or provider changes.
The buying rule
Do not buy software because it works perfectly on the vendor’s preferred connection. Buy it because you understand how it behaves when conditions are ordinary, degraded, and recovering.
Starlink Mobile may change how businesses connect. That makes portability and failover more valuable, but it does not make fragile software dependable. The winning system will be the one that keeps business state intact while the infrastructure underneath it evolves.
Hitch is built around that operational boundary, helping small businesses keep lead follow-up, customer communication, and recurring work moving across the systems they already use. If your workflows still depend on perfect connectivity, start with the 30-minute resilience test and fix the first failure you can reproduce.