South Africa builds software for people at desks.
Most of our workforce is not at one.

Think about the last piece of business software anyone demonstrated to you. It opened on a login screen. It assumed a laptop, or at least a phone carrying a work email account. It assumed you would be sitting down.

Now think about who actually keeps this country running.

The guard who takes over the gate at six in the morning. The cleaning team arriving at an office park before anyone else does. The driver somewhere on the N3. The merchandiser restocking a shelf in Pinetown. Kitchen staff, farm workers, home-care nurses, technicians on call-out.

None of them have a work email address. Most have never had an intranet login. They do not sit down.

The word for them is deskless, and in South Africa they are not a niche segment. They are most of the employed workforce.

What happens when every system assumes a desk

Companies do not stop managing these people just because the software will not fit them. They manage them with whatever is left: phone calls, printed sheets, and WhatsApp groups.

That works, after a fashion. What it does not do is record anything. A controller phones eight sites at six in the morning and establishes that seven are covered and one guard has not arrived. By nine that knowledge exists nowhere. It cannot be reported on, cannot be billed against, cannot be shown to a client who asks for proof of service. Nothing accumulates.

These businesses are not undigitised. They are digitised in a form nobody can query.

WhatsApp already won, and nobody decided it

Walk into any of these companies and you will find the roster in Excel and the workforce on WhatsApp. No one chose that architecture. It assembled itself, because WhatsApp is the thing everybody already has.

It runs on entry-level Android handsets. It is light on data, which matters enormously when data is bought in small amounts. It is already installed, already understood, and requires no one to be trained on anything. Every competing channel — an app, a portal, a rugged device at each post — has to overcome all of that before it delivers a single unit of value.

So the channel question is settled. The interesting question is what you build on top of it.

Building for a channel, not an app

What you gain is significant. Nothing to install. No device to buy, charge, replace or explain. No training beyond "send a message". It works on the phone already in the person's pocket, which means rollout is a message rather than a logistics exercise.

What you give up is real, and pretending otherwise produces bad systems:

• No background processes. You cannot poll, cannot run a service, cannot track anyone continuously.
• Location is a pin somebody chooses to send, not a feed you subscribe to.
• You cannot message freely. Outside the window a person's own message opens, you pay per template, and those costs compound at headcount.
• The interface is a conversation on a small screen. There is no dashboard, no table, no hover state.

Design against those constraints and the result is usually simpler and more used than the app would have been. Ignore them and you get a chat window that behaves like a badly ported web form.

Six rules we build by

The chat is transport, never the record. Conversations scroll away and get deleted. The system of record lives somewhere queryable, and the chat is simply how an event reaches it.

Let the worker open the conversation. A message the guard sends starts a window in which replies cost little. A business pushing templates to every worker for every shift is the design that quietly becomes unaffordable at two hundred people.

One button beats a form. Every question asked is a place to drop out. If the whole interaction is "tap On duty", almost everyone completes it, at six in the morning, in the rain.

Send exceptions, not dashboards. A manager does not want a daily report showing that everything is fine. They want one message when a post is unmanned. Everything else is noise wearing a chart.

Do not take away the spreadsheet. The roster in Excel has survived every salesman who ever walked through the door. Read it, write back to it, and leave the controller's Monday exactly as it was. Software that demands a new habit gets abandoned in week three.

Assume the phone is shared, flat or lost. It will be. Identity, fallbacks and failure modes all have to survive that, which is a different design problem from the one an office app solves.

Why so little of this gets built

The buyers are not at tech conferences. The users cannot file a support ticket or complain publicly about a bad experience, so nobody hears when the software is poor. And the work looks unglamorous next to another consumer app — nobody demos a shift check-in on stage.

Which is precisely why it is worth doing. The operational pain is real and daily. The budgets already exist, attached to compliance obligations, skills-development levies and the plain wage cost of a post standing empty. And the competition is a phone call.

Where we are

Some context for why I keep coming back to this. Before I built software for security companies, I worked in one — as a guard, then a supervisor, then a controller running a shift from the other side of the radio. The six rules above are not principles I reasoned my way to. They are things I watched fail.

We build WhatsApp and AI systems for South African businesses, and we are increasingly convinced this is the part of the market that matters: not customers messaging a company, but companies reaching the people who work for them.

We are building it in the open and writing down what happens — starting with the simplest question a security company asks every single morning. Did the guard arrive?

If you run people who start work somewhere other than an office, we would like to hear how you keep track of them today. Message us. That conversation is free, and it is the most useful hour we spend.