If your web app has customers, students or clients in other countries, someone is using it while you are asleep. That is good news for your business, and it raises a fair question: what happens if something goes wrong at 3am your time?

For many South African businesses, the honest answer is that nobody notices until the morning. This article looks at four practical building blocks that change that answer: more than one server, a shared database and a public status page, plus a separate beta environment for testing changes.

Your customers are awake when you are not

Once you sell or teach across borders, your working day stops being the only day that matters. A customer in Asia starts their morning while Johannesburg is still asleep. A client in Europe or the Americas may be online long after your team has logged off.

Time zones themselves keep shifting, too. The IANA time zone database, which most software relies on, "is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules." If your app shows booking or lesson times, it needs to keep up with those changes. Modern browsers help here: MDN notes that Intl.DateTimeFormat "enables language-sensitive date and time formatting" and has been "available across browsers since September 2017."

More than one server, one shared database

In plain terms, instead of your web app living on a single server, it runs on two or more, each able to serve your customers. They all read from and write to one shared database, so a booking made through one server is the same booking everyone sees on the other.

The main benefit is resilience. Google's Site Reliability Engineering book includes a simple question on its launch checklist: "Do you have any single points of failure in your design?" With one server, the answer is yes. A shared database is the part every server depends on, so it needs its own backups and protection too. With servers in different regions, a problem in one place does not have to take the whole service with it, and you can reach audiences in other parts of the world from a server close to them.

A public status page shows people what is working

When something does go wrong, customers want to know whether it is them or you. A public status page answers that without anyone needing to send an email or wait on hold.

Status pages are an established category. Atlassian, for example, describes its Statuspage product with the line "Build trust with every incident" and talks about reducing "the flood of support requests during an incident with proactive customer communication." The principle applies whatever tool you use: being open about what is working builds trust.

A beta server lets you test before everyone sees it

A separate "latest" or beta environment runs your newest changes on real infrastructure before they go live for everyone. The SRE book makes the point well: "Having a working configuration in a test instance doesn't guarantee that the same configuration can be rolled out to the live instance." It also notes that "almost all updates to Google's services proceed gradually," with checks along the way.

You do not need Google's scale to borrow the idea. A beta server gives your team, and any customers who opt in, a place to try new features first, so problems surface before they reach your main audience.

A real example: Let's Learn Today

Let's Learn Today is a learning platform built by Hardcode Studios that connects teachers, students and schools with scheduling, progress tracking and payment tools. Its blog also covers the time zone side of teaching online, such as keeping multi-timezone online lessons clear for independent English tutors.

Behind the scenes, the platform runs on West and East servers in different regions, sharing one database. The East server is in Hong Kong, close to audiences in Asian time zones. A third, Latest/Beta environment sits alongside them for testing changes.

Anyone can check the Let's Learn Today status page. It lists four parts: West (lets-learn-today.com), East (lets-learn-today.org), Latest/Beta (latest.lets-learn-today.com) and the Database, shared by all web servers. When we checked on 15 October 2026, the header read "All systems operational" and all four showed as operational. The page refreshes itself every 60 seconds and has a "Run check now" link for anyone who wants an immediate update.

Is this right for your business?

Not every website needs several servers. A simple brochure site can live happily on one. This setup earns its place when:

  • your customers or users are spread across regions and time zones
  • people rely on your web app for bookings, lessons, orders or payments
  • a few hours of downtime overnight would cost you sales or goodwill
  • you release changes often and want to test them safely first

If several of those apply, it is worth planning for from the start, as it is easier to design in than to add later.

Hardcode Studios builds this into web apps: more than one server, a shared database, a public status page and a beta environment, tested and supported after launch. Tell us about your project and we will help you work out what your app needs.

See how this works in practice in the Action Plan field-team scheduling case study.