One platform under everything we make.

Dachshund handles the things every piece of business software needs and almost none of them get right: who you are, what your company pays for, how the software reaches your machines, and how you get hold of a human when it goes wrong. We built it first, so that no product we ship ever has to solve those badly under a deadline.

It is built, it runs, and there is now a product standing on it. You cannot buy Dachshund on its own and there is no signup button on this page, because the way you get it is underneath Lumarix.

In plain words

What it actually is.

A bookkeeper leaves a four-person firm. Two months later somebody works out that she is still the registered owner of the accounting licence, the renewal invoice is going to an inbox nobody can open, and the installer everyone uses was a link in an email she took with her. Nothing was stolen. The company simply never held its own software in its own name.

That happens because each package a business runs keeps its own list of who works there, its own idea of what has been paid for, its own login and its own invoice. Nobody owns the join between them, and the join is exactly where access outlives employment and where money goes quietly missing.

Dachshund is our answer to that gap, for the software we make. It is not an application you open. It is the layer underneath the applications, and it holds four things.

Who you are. One account across every product, so your bookkeeper does not keep six passwords. What your company holds. Subscriptions belong to the business, not to whoever happened to sign up, and you can see exactly what you have and until when. How software reaches you. Releases are signed, and the machine that receives one checks the signature and the bytes before anything installs. How you get help. Support lives inside the product, and it ends at a person.

Solving those four once, properly, is the whole idea. The first product standing on it is Lumarix, an ERP for small and mid-sized South African businesses, and it is open and in use. It started on a foundation that had already been broken on purpose and repaired, not one assembled in a hurry because the real work was somewhere else.

What it does

Six problems, solved once.

Each of these is a thing a business notices when it is wrong, and never thinks about when it is right.

One account, every product

A single Reichmann ID signs you into everything we make. No password per app, no separate silos, no registering again next time. Sign out in one place and you are signed out everywhere, on the next click.

Licences belong to the company

Subscriptions are held by the business, not by the person who happened to sign up. When they leave, the licence does not leave with them. You can see exactly what you hold, and the date it runs until.

Keeps working when the line drops

Your licence is a signed document your software carries. If the connection goes, or the power does, it keeps working for a bounded stretch on what it already holds. Move the clock backwards to stretch it and it refuses.

Updates that check themselves

Think of a sealed courier bag that refuses to be accepted if the seal has been broken. A release is signed by the studio, and before anything installs, the receiving machine checks that signature and re-weighs the bytes that actually arrived. If they do not match what was published, it shows you both figures and installs nothing.

Billing you can audit

Invoices numbered in an unbroken sequence, amounts held in whole cents so nothing rounds away, and payment reminders frozen exactly as they were sent. Paying later changes what you owe. It never changes the record of what you were told.

Support that ends at a person

Chat from inside the product. An assistant handles what it can from documentation we control, and hands you to a human the moment it cannot. Never a bot dressed as a person, never a person dressed as a bot.

How it works

What a day on it looks like.

This was written in the future tense until August 2026, when a real product started doing it. Every step below is built, passes its tests on every change driven by a real browser, and now runs under Lumarix, not only under a test.

You buy once, as a company
You create an account, create your business, and subscribe on its behalf. The subscription starts openly unpaid, with the invoice number and the amount showing, instead of quietly granting you access it has not been paid for.
Your team is your team
Whoever you add can use what the company holds. One bookkeeper, fourteen engineers, or just you. The licence sits with the business, so staff changes are an administrative matter rather than a licensing emergency.
The software arrives verified
Your machine fetches the release, checks it was signed by the studio, and checks the bytes that arrived are the bytes that were published. Anything else is a refusal on screen, showing you exactly what did not match.
Load shedding does not lock you out
The licence your software holds is signed and dated, and covers a bounded period without contact. A fibre cut or a day off the grid does not take away software you have paid for, and the leniency has a limit that cannot be gamed.
When it breaks, you are not alone with it
You open support from inside the product and describe what happened. Whoever picks it up can already see your company, what you hold, and your invoices, so you are not made to prove who you are before anyone will help.

To be exact about the one that matters: you do not buy this. You buy Lumarix, and these are the steps the platform runs underneath it.

Why it is different

Four things most software has never been tested for.

These are properties of the platform, not habits of ours. The eleven checks that hold them in place are named individually on the standards page.

01

One customer cannot see another

Who may see what is enforced by the database itself, not by a check inside a screen. A bug in a page cannot show your data to somebody else's company, because the page was never the thing holding the line. The list of code that is allowed to cross that boundary is fixed, named and counted, and adding one more breaks the build until we have said out loud why it exists.

02

You can prove what happened

Every action leaves a record of who did it and when, on a chain that detects its own tampering. Nothing can edit or delete an entry, including us. Where the law requires content to be removable, removal takes the content and leaves the fact permanently: the message body goes, and a marker saying it existed and was removed stays for good.

03

Money lands exactly once

Payments are settled under a lock that makes a double application impossible rather than unlikely. The books are then reconciled to the cent at the end of the four stress tests and the browser journey where that kind of error would hide, including two payments landing on one invoice at the same moment. A single unaccounted cent fails the run. Amounts are held as whole cents, so there is no rounding for anything to hide in.

04

The one you talk to cannot act

The support assistant, the only one a customer ever meets, can answer and escalate. It cannot change anything, because the code it runs inside can reach exactly one thing that writes, and that one thing is its own record of the conversation. A prompt saying "take no actions" is a comment. Code that cannot reach one is a wall. The tests for this hand it an attacker's script and assume it obeys, then check that not one of the sixteen tables that can carry an action moved by a single byte.

Status · updated 18 August 2026

Where it actually stands.

We build this in numbered phases, and a phase does not close until every check is green and we have sat down and driven the thing ourselves.

Finished and closed
Six phases. Accounts and sign-in, the studio's own operator console, the catalogue with entitlements and billing, the product contract and distribution, support with its assistant, and an internal assistant that helps us run the studio. That last one is allowed to act, unlike the support assistant above, and only where a dated permission for that exact act is sitting in the database, granted by us and expiring on its own. All of it gated, all of it passing, each phase closed on a dated decision rather than a feeling that it was probably done.
The first product
Lumarix, an ERP for small and mid-sized South African businesses, and the seventh phase. It inherits its account, its licensing, its updates and its support chat from the platform instead of building any of that again, which is the whole argument for having built Dachshund first. It opened in August 2026. It is priced and it is in use.

We update this instead of leaving "coming soon" sitting here rotting. If the date above has gone stale, that itself tells you something.

The size of it

What is here, and what is not.

229 automated tests across the database and every way into it, counted on 29 July 2026. Each is named for the claim it proves, so a failure tells us which promise broke.
34 journeys where a real browser drives the actual product the way a person would. Retries are not permitted: something that passes only on the second attempt has told us something.
1 product standing on it, open and priced. Everything the platform holds — the account, the licensing, the billing, the updates — is carrying it in production today.

We built eleven checks and eighty-eight planted faults because the only version of this worth building is one that carries other people's records for years without losing any, and that version has to be right before the first customer arrives. That work was done in advance, and it is the reason Lumarix could open on top of it.

If you came here about client work, not the platform, the useful version is this. What travels to your project is not Dachshund itself but the habits that building it forced on us, and the standards page sets out which of those reach a three-week website and which do not.