Designing for distance, patchy coverage and six time zones

Australia is a long way from most of the internet, its population is concentrated in a handful of cities on the edge of a very large continent, and it cannot agree on what time it is. All three of those are engineering problems, and all three are solvable if you decide to solve them early.

The physics you cannot argue with

Light in fibre travels at roughly two thirds of the speed of light in a vacuum, and the cable does not go in a straight line. A round trip from an Australian capital to the west coast of the United States is on the order of 150 milliseconds, and to the east coast closer to 200. No amount of optimisation changes that number, because it is a property of the planet.

What matters is not the number itself but how many times you pay it. One round trip is imperceptible. Six in sequence, each waiting on the last, is a page that feels broken. Serial round trips are the single most common cause of software that feels fine in development and sluggish in production.

The fixes, in the order we reach for them:

Run in an Australian region. The cheapest latency win available, and the one most often left on the table because a console defaulted elsewhere.
Serve static assets from an edge network. HTML, CSS, JavaScript, images and fonts should come from a point of presence in the same city as the user, not from your origin.
Collapse the round trips. One request that returns what a screen needs beats six that each return a fragment. This is worth more than any micro-optimisation.
Do not wait to render. Show the interface with what you have and fill in the rest. A screen that appears instantly and settles is better than a spinner that is technically faster.
Cut third-party requests. Every external script is a DNS lookup, a TLS handshake and a round trip to someone else’s infrastructure, on a connection you do not control. This website loads none, which is why it is fast from anywhere.

Coverage by population is not coverage by geography

Mobile network coverage in Australia is usually quoted as a percentage of population, which is a flattering way to measure a country where most people live in a few coastal cities. Measured by area, the picture is very different, and the gap is where a lot of real usage happens: on a highway, in a regional town, in a hospital basement, in a house with one bar of reception in the back bedroom.

The consequence for product design is simple. Connectivity is an input, not an assumption.

For BubSync this is not a hypothetical. The app exists to be used at 3am by someone holding a baby, and at 3am the phone is often on a bad connection or none at all. So logging works offline first: the entry is written locally, the interface confirms it immediately, and the sync happens when the network comes back. The user never waits for a server to agree that their baby was fed.

The design rules that fall out of that:

Write locally, sync later. The local write is the source of truth for the user’s confidence, and the server is the source of truth for everyone else.
Design the conflict rules before you need them. Two caregivers logging the same feed on two phones with no signal is a normal Tuesday, not an edge case.
Make sync state visible but quiet. People need to be able to tell that something has not saved yet, without being nagged about it.
Treat a failed request as a delay, not an error. Retry, back off, and keep the interface usable. An error dialog because a phone went through a tunnel is a bug.

Offline-first is more work than request-response. It is the difference between an app that works where people are and an app that works in the office.

Time zones, the quiet disaster

Australia has three standard time zones, and in summer some of those states move and some do not. Queensland does not observe daylight saving; New South Wales, Victoria, South Australia, Tasmania and the Australian Capital Territory do. Western Australia and the Northern Territory do not. South Australia and the Northern Territory sit on a half-hour offset. Lord Howe Island shifts by thirty minutes.

So a national product has to deal with a country that can be up to five distinct local times at once, twice a year, with the transitions landing on different dates from the northern hemisphere.

What that means in practice:

Store instants in UTC. Always. This part is not controversial and is still got wrong constantly.
Store the zone, not the offset. Australia/Brisbane survives a daylight saving change. +10:00 does not.
Do date arithmetic in the user’s zone. “Today’s feeds” and “this month’s usage” are local concepts. Computing them in UTC produces a day that starts at 10am for half the country.
Never hardcode a midnight job to a single zone. A scheduled task at 00:00 in one zone fires at 21:30 the previous day somewhere else in the same country.
Expect ambiguous and missing local times. When the clock goes back, 2:30am happens twice. When it goes forward, it does not happen at all. A timestamp parser that accepts both without complaint will produce a bug you find in April.

This is unglamorous work. It is also the kind of thing that generates support tickets that are very hard to diagnose from a screenshot, because the reporter’s phone and your server disagree about what day it is.

The energy case, which is worse

My Energy Agent has to reason about electricity usage, and electricity data in the National Electricity Market is recorded in a fixed market time that does not follow daylight saving. So a household’s lived experience of “5pm on a hot afternoon” and the interval data describing it can be an hour apart for half the year, in some states and not others.

Getting that wrong does not produce a cosmetic bug. It produces a peak-demand calculation that is confidently incorrect, on the basis of which somebody might switch plans. This is why the boring rules above are rules rather than preferences.

What we build by default

Every product we start now inherits the same defaults, because they are cheaper to adopt at the beginning than to retrofit:

Australian region for primary data, edge delivery for anything static.
One request per screen where possible, rendered optimistically.
Local-first writes for anything a person expects to be instant.
UTC instants, named zones, local-day arithmetic.
No third-party scripts on the critical path.

This corporate website is the extreme version of the same philosophy: static HTML built ahead of time, served from an edge cache, with no JavaScript framework and no external requests at all. It is not a flex. It is what you get when you take distance seriously and then remove everything that was not earning its keep.

Next: what it actually costs to run software here.

Written by the team at The Trustee for Rowe Digital Trust, in Brisbane. General commentary, not advice for your circumstances. Corrections to hello@rowedigital.net.