On this page

Most AI products assume great connectivity. Fast internet. Low latency. Always-on cloud endpoints.

I'm building a product right now where that assumption doesn't hold. The users work in fields and apiaries. Signal comes and goes. Strong in the morning, gone by afternoon, and the afternoon is when the actual work happens.

This changes how you think about AI features.

🔗The connectivity assumption most teams miss

If you design your AI workflows on the assumption that the cloud is always reachable, you end up with features that work great on your laptop and fall apart in the real environment.

The usual pattern goes like this:

  1. User captures something — a note, a photo, a voice memo
  2. Device sends it to the cloud
  3. Cloud runs the AI pipeline — transcription, classification, extraction
  4. Results come back
  5. User sees the output

Step 3 is the problem. If step 3 can't happen because there's no signal, steps 4 and 5 don't happen either. And the user is left wondering whether they need to do the work over later, or just give up on the feature entirely.

Once a user learns that a feature only works with signal, they stop depending on it. They adapt their workflow around it instead of through it. That's a hard trust gap to close later.

🔗What you actually need

I've landed on a few constraints that make the architecture harder to build but much more useful in practice.

The AI should degrade gracefully. If the cloud is unreachable, the feature should still do something useful. Maybe it falls back to a local model with lower accuracy. Maybe it queues the work and processes it when connectivity returns. The worst option is a spinner that never resolves.

Local inference matters more than you think. You don't need a 70B parameter model running on a phone. You need something small and focused that handles the highest-frequency operation well. On-device transcription of a short voice note. Local classification of a few known patterns. Offline detection of whether the user just completed a common workflow.

Model size is a design constraint, not a technical limitation. You make different choices when you know the fallback path matters.

The sync layer is the actual product. If you queue work offline and process it later, the user needs to trust that the system actually handled it. That means clear status indicators. A queue that's visible, not magic. Results that arrive and get surfaced without the user having to check back manually.

I spent more time on the sync feedback design than on the AI pipeline itself. Wouldn't have guessed that going in.

🔗What happens when you get it wrong

A user finishes a task in the field. They captured what they needed. The app says "processing." They move on.

Three hours later, they check in — because they're good operators who verify — and nothing happened. The data was sitting in a queue that never flushed. The workday is over. The thing they entered needs to be reconstructed from memory or re-entered.

That is worse than if the feature didn't exist. The user lost the value and they lost trust in the system. And they have to redo the work.

One bad offline experience can make a user treat an AI feature as unreliable for weeks.

🔗What I've found works so far

I'm still learning, but these patterns are holding up:

🔗Voice-first capture works well offline

A short voice note takes seconds, stores locally, and can be transcribed in batch when signal returns. The latency of transcription is less important than the speed of capture. The user says the thing and keeps moving.

🔗Local-first, cloud-enhanced

Process the common path on-device. Use the cloud for the heavy lifting — the deeper analysis, the cross-referencing with historical data, the pattern matching across many records. The user gets immediate feedback from the local step and richer results when sync completes.

🔗Make the offline state visible

Don't hide that the user is offline. Show them. Show the queue. Show what's waiting and what's been processed. A visible queue is a trust mechanism. A hidden one is a trap.

🔗Batch aggressively and notify sparingly

Process large batches when connectivity returns, not one-at-a-time. But only alert the user if something needs their attention. If everything processed cleanly, a quiet sync indicator is enough.

🔗The hard part

The hardest thing is admitting that some AI features just can't work offline, and deciding whether to ship them anyway or leave them out.

I've cut features that only worked with always-on connectivity. They were good features. They looked great in a demo. But in the actual use case, they would have created more frustration than value.

That's a hard call to make when you're excited about what the AI can do. But the user won't know about the feature you didn't ship. They will know about the feature that failed on them in the field.

🔗Final thought

If your users work where connectivity is unreliable, the best AI feature you can ship is one that never makes them wonder whether it worked.

Build for the environment your users actually work in, not the one you can demo from your desk.

🔗Next step

If you're building AI for environments that aren't a well-connected office, I'd like to hear about it.