Custom software or off the shelf: who owns what

Custom software versus off the shelf gets argued as a cost comparison and decided as one. That is the wrong test. The question that matters is which of the things your system depends on you can replace, how quickly, and what you lose when somebody else buys one of them.

A reported acquisition this week makes the point better than any framework, and it makes it whether or not the deal ever closes.

What happened

TechCentral covers a reported move by Nvidia to acquire Hugging Face, and reads it as less about revenue than about defending Nvidia's chip business from within. The status matters and is easy to overstate: the deal was first reported by The Information, it has not been signed or publicly confirmed by either company, and it could still fall through. Nvidia had earlier tried for a smaller stake and been turned down.

Hugging Face is where open-weight models are published and downloaded. It is the thing a South African developer means when they say a model can be self-hosted rather than rented from an American API. It has been treated, correctly or not, as neutral ground.

Neutral ground with an owner is not neutral ground. That is the entire lesson, and it applies far below the level of chip strategy.

Custom or off the shelf, the dependencies are the same

Write out what one of your systems actually depends on. Not the vendor. Everything.

• The application you bought, and the company that sells it.
• Whatever database or platform it was built on.
• The cloud region it runs in, and who operates that region.
• Any model or third-party service it calls, and how that is billed.
• The integrations to your accounting, payroll or WhatsApp number.
• The data itself, and the format you could get it out in.

Off the shelf does not reduce that list. It hides it behind one contract. Custom does not eliminate it either, it just changes which items you chose yourself. Anybody selling you either option as "fewer moving parts" is describing the invoice, not the system.

The four questions that actually decide it

For each dependency, ask these. The answers are more useful than any build-or-buy spreadsheet.

Can I get my data out, in a form somebody else can read? Not "does the vendor offer an export". Ask what fields it contains, whether it includes history and attachments, and whether anyone has ever run it.

How much notice do I get before this changes? Price rises, deprecations, region closures and acquisitions all arrive with notice periods that are written down somewhere. Most South African buyers have never read them.

If this owner changed tomorrow, what breaks? An acquisition changes pricing, roadmap and terms. The dependency that worries you is not the one you pay the most for, it is the one you could not replace inside a quarter.

What is the replacement, and has anybody named it? A dependency with no named alternative is a single point of failure regardless of how good it is.

Hosting it yourself is a different set of problems, not fewer

The instinct when an owner changes is to bring the thing in-house. That reflex deserves a South African reality check.

MyBroadband reports that components meant to replace the Lengau supercomputer have been waiting to be deployed at the CSIR since last year, believed to be worth nearly half a billion rand. The CSIR disputes that figure, calling the assertion incorrect and saying the system was acquired on a lease-to-own basis with payments made annually. The CSIR also says the components are now being prepared for deployment. Either way a national research institution with funding, procurement and specialists has had the hardware for about a year and it is not yet in service.

Owning infrastructure is not the same as running it. For a business with 40 or 400 staff, self-hosting a model means power, cooling, a maintenance window, somebody who can debug it at 22:00, and a plan for the week that person is on leave. Load shedding and bandwidth make the local version harder than the article it was read in.

Self-hosting is the right answer sometimes, usually for data residency reasons. It is almost never the right answer as a reaction to a headline.

What this means for a 40-person business here

Very little changes this quarter, and that is the point worth making plainly.

If you rent a model over an API, your dependency is the API and its rand price, and an owner change would eventually move both. If you self-host an open-weight model, your dependency was already the place you downloaded it from, and you now know who owns that place. And where you bought an off-the-shelf product that quietly calls a model, you have this dependency without having chosen it, and your contract probably does not mention it.

That third case is the common one in South Africa, and the fix is a question to your vendor rather than a project.

The position worth holding

The durable answer is not custom or off the shelf. It is to buy the parts that are genuinely commodity, keep your data and your process rules where you control them, and make the seams between systems yours.

That is the staged approach Zorah works to: keep what you already run, fix the bottleneck properly, and own the joins rather than the modules. A business that owns its integrations can change any single vendor without changing everything.

What to do on Monday

Take your most important system and write down every dependency underneath it on one page, then mark each one with how long a replacement would take.

Anything you cannot answer is the thing to ask your vendor this week, in writing. Then check whether your automation and integration layer is something you own or something rented inside a product, because that is the join that decides whether buying or building is reversible. Dealers running a fixed platform, as in motor retail, should ask for the data export specification first, since that is the dependency that decides all the others.