About

I live where the software has to work.

I grew up on a farm, I live on one, and almost all my time is spent here and with the farming community around me. That isn't a marketing angle — it's the reason the first thing I built was a safety net for the people next door.

The first real product came out of a question that has an obvious answer everywhere except where I live. If something happens to you at night — who notices, and when? The nearest neighbour is kilometres away. Real help is much further. Nobody was coming to build us an answer, so I built one.

The other half of what I do is behind a camera: wildlife photography and video, part-time, when the light and the season allow it. You can see that work at johanevert.co.za. It's a more useful second discipline than it sounds — composition, patience, and the habit of waiting for the right thing instead of settling for the thing in front of you. Those are the same instincts that decide whether a screen is worth looking at.

If it fails quietly on a Tuesday night, someone doesn't get help. That's not a bug report. That's the standard.

Farm Safety has been in daily use in my own community ever since. Thirteen people tap a button every evening to say they're okay. I'm one of them — my name is on the roster like everyone else's, which means every rough edge in that app is one I run into myself. It turns out that's the most useful quality-assurance process I've ever used.

Why I build the way I do

When the people using your software are your neighbours, you learn a particular kind of care. You can't ship a change and disappear. You can't let a notification cry wolf, because the next time it screams at 2am somebody needs to believe it. You can't quietly break the thing that tells the community someone hasn't checked in.

So: every deploy is verified by reading the file back and checking its hash, not by assuming the upload worked. The parts that carry real consequences are covered by tests. Updates explain themselves in plain language the first time the app opens. Fixes go out over the air, usually the same day, without asking anyone to reinstall anything.

None of that is exotic engineering. It's just refusing to leave loose ends in something people depend on — and it's the same standard I bring to a website or a backend as to a safety app.

Working with me

I'm one person, not an agency. That has obvious limits and one real advantage: you talk to the person who writes the code, every time, and nothing gets lost being relayed through an account manager.

I'll tell you honestly if what you want isn't something I should be building — if it needs a team, a different specialism, or an off-the-shelf product that already does the job for less than I'd charge you. That answer costs you nothing and saves us both a bad project.

What I'm most interested in is work with the same shape as Farm Safety: practical software for people the industry usually overlooks, built to keep running long after the excitement of launching it has worn off.

In short

Four things you can hold me to.

  • You deal with me directly. No layers, no handovers, no "I'll check with the developer".
  • I say no when no is the right answer. Including when it costs me the work.
  • Nothing ships unverified. Deploys are confirmed, not assumed.
  • It has to keep working. Software that only works on launch day isn't finished.

Get in touch

Tell me what you're dealing with.

An app, a website, or a system that has to keep running without anyone watching it. Email is the fastest way to reach me.