A software studio building in South Africa

Small on purpose, and building for the day you no longer need us.

A small team, a rule about handover we have never once bent, and a short list of things we will not do.

The studio

TUMO OLO is a software studio in Johannesburg. The name means what it looks like it means: a maker, and a thing made. Applied Intelligence Mzanzi is the line under it — intelligence applied to a real business problem, built here.

We started because too much software in this market ends up rented back to the people who paid for it: a licence that never stops, an automation nobody outside the supplier can read, a repository that quietly stays in the supplier's account. Every rule below follows from not wanting to be that.

What we hold to

Handover is the deliverable, not the launch. How a project is documented, how the things in it are named, what is covered by a test — all of it is chosen so that the question at the foot of this page has an easy answer.

The boring answer is usually the right one. A rule beats a model more often than this industry admits, and a fix beats a rebuild more often than a quote admits. Saying so out loud costs us work, and keeps the work that is left worth doing.

Nothing ships that we would not hand to a stranger. Accessibility, performance and security are gates a branch passes before it merges, not an audit somebody commissions after a complaint.

What we will not do

Hold your domain, your repository or your deployment hostage.
Quote a model where a rule is better, or a rebuild where a fix is better.
Take on more workstreams than we can staff, or let you find the ceiling in week three.
Put a number on work we have not scoped.

If this supplier disappeared tomorrow, could another developer pick the project up from the repository alone? That question shapes everything above.