Why host your business system in Perth

What 2008 taught us

A website is the visible part of a business system. The database behind it is the part that hurts to lose: the product list, the prices, the customer records, the orders, the history. When a hosting company closes, its servers do not keep running on their own, and the people who could have handed over a copy are no longer there to ask.

The businesses that came to us in those years had paid a company in the USA to manage and host their site. What they did not have was a clear picture of who held the system, where the data was, and how to get a copy of it. For some, that meant starting again. We were already running our own servers, and we took those businesses on.

We took four lessons from that, and they still shape how we work:

• Know who holds your system and your data: which company, and in which country.
• Keep backups you can get to yourself, not only the ones the host says it keeps.
• Keep them close. A copy you can collect in person is worth more than one on another continent.
• Deal with the people who wrote the system. When they also host it, there is one door to knock on.

Distance you can measure: 2 ms to Perth, 45 ms to Sydney

Every time your browser asks a server for something and gets an answer, that is one round trip. The time it takes is measured in milliseconds, written ms: one millisecond is a thousandth of a second. On 8 October 2026 we measured round trips from our data centre. To Perth, about 2 ms. To Sydney, about 45 ms. Each round trip to Sydney takes roughly 20 times as long.

That does not make a page 20 times slower. A page needs several round trips, plus the time the server spends doing its work, plus the time your browser spends drawing the result. But each of those round trips carries the extra distance, and in a back office that staff use all day, the extra wait is paid on every click.

There is a physical reason for the gap. Data between Perth and the east coast travels long fibre routes, and some of the country's long routes run under the sea, where a cable can be cut. Those are general facts about how the network is built, not faults we have measured. The point is plain: a server in the same city as your staff has less distance to cover and fewer things in between.

Who answers when something breaks

Hosting is not only where the server sits. It is who you can reach. If your system was written by one company, hosted by a second and supported by a third, a fault becomes a question of whose fault it is before it becomes a question of fixing it.

At SecureSpace, working from Canning Vale in Perth, one team plans the system, builds it, hosts it on our own servers and looks after it. The servers are backed up daily, to three locations. When something needs to change, you talk to the people who built it, not a ticket queue. That is the other half of the 2008 lesson: the people who wrote a system are the ones who know it, and they should be the ones you can reach.

What to ask any host, wherever they are

Whether you talk to us or to anyone else, ask these before you sign, and write the answers down.

• Which city, and which building, are my servers in?
• Who owns the servers: you, or a company you rent them from?
• How often is my data backed up, where do the copies go, and can I get a copy myself today?
• If your company closed tomorrow, how would I get my system and my data out?
• Who wrote the system, and are they the same people who host and support it?
• Measured from my office, how long is one round trip to your server?

A host who answers these plainly is giving you the thing the businesses of 2008 did not have: a clear picture of who holds what, and where.