Not always, not perfectly, but there. Latency measured in tens of milliseconds. A dropped connection that comes back in seconds. A CDN somewhere nearby. When engineers talk about designing for failure, they usually mean a service going down, not the physical link to the outside world being a dish pointed at a satellite in geostationary orbit.

We build things. Roads, gas plants, grid stations, port terminals. Our project portfolio gives a sense of the range, but the relevant part here is where a lot of that work happens. A lot of that work happens in places where there is no fibre, no reliable cellular coverage, and no prospect of either arriving before the project ends. Our sites connect to head office through Ku-band VSAT terminals: a 1.2 metre antenna, a 3-watt block upconverter, an LNB, and an iDirect modem, backhauled through a satellite hub to the enterprise network.

That constraint changes how you think about software. Some of what we learned running engineering and ERP systems on that link maps directly onto problems developers deal with in other contexts.

Geostationary latency is a floor you cannot optimise below

A geostationary satellite sits roughly 35,786 km above the equator. A signal goes up and comes back down, which is about 71,500 km of travel. At the speed of light that is around 240 milliseconds one way, so a round trip is close to half a second before any equipment does anything at all.

You cannot cache your way out of that. You cannot buy a better modem to fix it. It is physics.

What that means in practice is that anything chatty over the wire falls apart. A protocol that needs six round trips to complete a handshake now takes three seconds. An ERP screen that fires a dozen sequential requests to render feels broken even when nothing is wrong. Database connections that assume sub-100ms response times start timing out under default configuration.

The engineering response is the same one you would apply to any high-latency environment: reduce round trips, batch aggressively, and move validation to the client. But most enterprise software is not written with that in mind, and you often cannot change it. So the work becomes configuration and architecture around the application rather than inside it.

Bandwidth is shared, finite, and does not care about your priorities

Terrestrial connections degrade gracefully under load. Satellite links do not, in the same way. Bandwidth is allocated, contended, and expensive per megabyte in a way most developers have not thought about since mobile data caps were a real concern.

A remote site running a hundred people generates a lot of traffic that has nothing to do with the work. Windows updates. Antivirus definitions. Cloud sync clients quietly uploading. Video calls. Left alone, all of that competes with the traffic that actually matters: the ERP transaction, the drawing revision, the daily progress report.

The lesson here is one that applies well beyond satellite: if you do not classify and prioritise traffic explicitly, the least important thing on the network will consume the capacity the most important thing needs. Quality of service rules are not optional in this environment. They are the difference between a functioning site and one where nobody can submit a purchase requisition.

There is a design implication for anyone writing software that might run in constrained environments. Make your sync behaviour configurable. Let an administrator schedule it. Do not assume that "sync continuously in the background" is a reasonable default everywhere, because in some places it is actively hostile.

Weather is a dependency

Ku-band is susceptible to rain fade. Heavy rainfall attenuates the signal, and the link degrades or drops entirely until the weather passes. In the Thar Desert this is rarely a problem. During monsoon in Sindh it is a scheduled outage you do not get to schedule.

This is worth sitting with for a moment, because it is genuinely unfamiliar to most software engineers. Your uptime is partially a function of atmospheric conditions. No amount of redundancy in your application layer helps, because the physical medium is what fails.

What you do instead is accept it and design for the outage. Which brings us to the thing that actually matters.

Offline-first is not a feature, it is the only viable architecture

We implemented ERP across the business in 2014, running inventory management, procurement, and the general ledger with receivables and payables. The hard part was never the modules. It was that a storekeeper at a well site in interior Sindh needs to record a material issue whether or not the satellite link happens to be up at that moment.

If the answer to "what happens when the network is down" is "the user waits," the system will not be used. People will keep paper records and reconcile later, which means your ERP data is now a lagging, incomplete reflection of reality, and every report built on it is wrong in ways nobody can quantify.

So the requirements become:

Local writes must succeed without a server round trip. The transaction is recorded locally and queued.

The queue must survive a reboot, a power cut, and a machine being switched off for the weekend. Durable local storage, not an in-memory buffer.

Reconciliation must handle conflicts deterministically. Two sites issuing from the same stock, a head office adjustment landing while a site was disconnected, a sequence number allocated twice. You need rules for these decided in advance, not resolved by whoever calls support first.

Sync must be resumable. A 40-minute rain fade in the middle of a batch upload should not mean starting over.

None of this is novel. It is the same problem set that mobile applications solved for intermittent connectivity, and that CRDTs and event sourcing address more formally. What is different is the failure duration. A mobile app assumes connectivity returns in seconds or minutes. We plan for hours.

The engineering software has a different problem entirely

The ERP side is transactional and reconcilable. The design and analysis tools are not.

We run AutoCAD, STAAD-Pro for structural analysis, PLAXIS 3D and WALLAP for geotechnical work, and Primavera P6 for scheduling, alongside BIM tooling for coordination. These produce large binary files that multiple people need to work on, and they have essentially no concept of distributed collaboration. A .dwg file is a file. Two people editing it in two locations produces two divergent files and a manual merge that a human has to perform by comparing drawings.

Version control as software developers understand it does not exist here. There is no diff for a 3D geotechnical model. There is no merge for a structural analysis file. The industry's answer is process discipline: file locking, a single source of truth, and a naming convention everyone follows because the tooling will not enforce it for them.

Over a satellite link, this gets worse. Transferring a large model file is a scheduled operation, not something you do casually. Which means the coordination question becomes "who has the file today" rather than "who has the file right now."

BIM is meant to solve this, and it does, partially. A shared model with defined workflows is a genuine improvement over emailing drawings. But it assumes bandwidth, and the bandwidth assumption is exactly what does not hold on a remote site.

If you have ever wondered why construction software adoption lags other industries, part of the answer is that a lot of it was designed for an office with an office's network.

What transfers

The specific situation is unusual. The lessons are not.

Latency you cannot fix forces you to design around round trips rather than optimise within them. Finite shared bandwidth forces explicit prioritisation, because implicit prioritisation always favours the wrong thing. And an unreliable physical layer forces genuine offline-first design, where local state is authoritative until it can be reconciled rather than treated as a cache of remote truth.

Most software gets to ignore all three because the network is usually fine. That is a reasonable bet in most places. It is not a reasonable bet everywhere, and the systems that hold up in difficult conditions are the ones that treated connectivity as a variable rather than a constant from the beginning.

The site does not care that your architecture assumed a working connection. The concrete pour is happening either way.