Next.js development for Perth mining and resources businesses

Perth has the best working overlap of any city in Australia, and that is the first thing worth saying because it changes everything else.

Five hours ahead of us, against one hour for Sydney and Melbourne. Our morning is Perth's afternoon, and there are several hours every day when both teams are at their desks. For a market that normally has to be worked asynchronously, that makes Perth engagements feel closer to European ones than to Australian ones.

Five hours changes the engagement, not just the calendar

With one hour of overlap, everything has to be written down because there is no time to discuss it. With five, a question gets answered the same afternoon and a decision can be made in a conversation when a conversation is genuinely faster.

What stays the same is that the written record still matters - a decision made verbally at four o'clock is a decision nobody can find in March. But the pace is different, and for work with real uncertainty in it, being able to resolve a question in twenty minutes rather than twenty-four hours is worth more than any tooling.

Screens that are not used at a desk

The second thing that distinguishes Perth work is who is looking at it. Mining and resources applications have a real population of users on a site, in a vehicle, in a workshop or in a crib room - not in an office.

Three consequences follow, and all three are usually discovered after launch.

Touch targets have to be large, because somebody is using a phone or a tablet with gloves on or with one hand. Contrast has to be well beyond the minimum, because the screen is being read in direct sunlight and a design reviewed on a good monitor indoors tells you nothing about that. And the flow has to be short, because an interface that needs five screens to record one observation will not be used - the observation will go into a notebook and be typed up by somebody else next week, which is the outcome the application was meant to prevent.

Usefully, the first two are the same decisions accessibility work produces. A page designed for somebody outside at midday is a page that works for somebody with low vision.

Losing the network mid-submission

The connectivity question is the one that most often gets over-engineered, so it is worth being precise about what actually goes wrong.

The failure is not that someone needs the application to work for hours offline. It is that a form submission is in flight when the signal drops, and the application has to be honest about what happened. A silent failure loses the entry and the person will not type it again. A blind retry can create two records.

The arrangement that handles both posts to the server with an identifier generated before sending, so the server can recognise a repeat as the same submission rather than a new one, and the interface states plainly whether something was saved. That is a small amount of work and it is the difference between a field application people trust and one they work around.

Genuine offline operation - hours of work with no connection at all - is a different and much larger commitment, and it is worth deciding deliberately whether it is actually required. When not to use Next.js covers the cases where a native application is the honest answer.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - the privacy and breach regime, accessibility expectations, invoicing - is on the Australia market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT because exported services are exempt.