References
We don’t talk about stacks — we build them
From the enterprise platform and the operating-system kernel to our own operating system for workstations and servers: whatever we recommend, we first put into productive use ourselves and with our customers. Here are ten examples — the clients remain unnamed, the technology does not.
- 01
Enterprise platform for an international industrial group
What it is
A business-critical, accounting-relevant (GoBD-compliant) specialist platform that replaces legacy processes grown over the years — travel expense accounting, e-invoicing/ZUGFeRD processing, document recognition, exports into SAP and DATEV systems. Around 40,000 lines of Rust, interface and logic consistently in Leptos + WebAssembly; a single process serves two separate tenants (customer portal and internal tool).
What it delivers
The same data types run natively on the server and — compiled to WebAssembly — in the browser: there is no second, divergent API definition that could drift apart. More than 230 tests safeguard the business logic (account assignment Germany/Switzerland, approval paths, document parser, export). No PHP/Node sprawl, no runtime surprise at the quarterly close.
Why build it this way
Accounting relevance means every operation must be provably correct. Rust makes correctness a property of the code, not a hope pinned on test coverage. WASM brings native speed to the browser without maintaining a heavy JS framework.
- 02
Our own operating-system kernel — and a next-generation file system in Rust
What it is
A self-maintained Linux kernel (our own patch stack on the latest 7.3 level): a latency-optimized scheduler, Google BBRv3, and — as a unique feature — cross-language link-time optimization: C and Rust are optimized together across the language boundary and inlined into one another, something the official kernel deliberately rules out. On top of that, our labor of love: the next-gen Reiser5 file system ported to Rust, including our own Rust abstractions for the kernel’s file-system layer that don’t even exist in Linux’s development preview.
What it delivers
Our guiding principle: a claim without a measurement is not an improvement. So we measured: under full load, the response time (99.9th percentile) stays at around 30 µs instead of over 1000 µs with the standard scheduler — a factor of 34, measured head-to-head within the same boot; for focus applications the latency dropped from 621 to 11 µs. The cross-language optimization cuts the call cost at the C↔Rust boundary by almost half. With the file system it is about the future: Rust brings memory safety exactly where a bug has so far taken down the whole system and its data — into the kernel.
Why we do it
Because the difference between “it runs” and “it runs smoothly” is decided in the kernel — and because we see a real future in safe system code written in Rust. This piece is not a commission but a conviction: we invest here because we believe tomorrow’s systems will be built this way.
- 03
Our own operating system for workstations and servers
What it is
A Linux distribution built entirely from source (Gentoo-based) for clients and servers — one shared base in two variants (workstation with desktop, hardened server). Plus our own package build host (binhost), a single self-maintained kernel (our kernel with a latency-optimized scheduler and the newest file systems as a module) and a Rust-first userland — modern tools in Rust instead of aging C mainstays.
What it delivers
Full control and no vendor lock-in: every package is built from vetted source and compiled for the fleet’s common CPU baseline, no foreign binary creeps unnoticed into the system, client and server share the same hardened foundation. Updates roll out continuously via our own binhost — always current, without a big version jump.
Why build it this way
“Building from source” is a ground rule for us, not a hobby — it is the only way to really know what runs on the machine. That is security (a traceable supply chain, hardening from the ground up), performance (genuine optimization for your own hardware) and consistency (one stack across the entire fleet) all in one.
- 04
A wall calendar built from old hardware, brought back to life
What it is
An aging calendar/photo frame to which we gave a completely new inner life — without Android, without an Android app, as is otherwise standard for such displays. Instead, a lean operating system of our own on a Linux basis and an interface drawn directly from Rust onto the Linux framebuffer (without an X11/Wayland intermediate layer) — local-first, without browser or app ballast.
What it delivers
Even on the weakest hardware (frugal ARM chips, 2 GB RAM) a smooth interface runs: a static program of around 8.5 MB redraws only when something changes, and sleeps otherwise. Data sources (calendar, weather) run as interchangeable, sandboxed WASI modules — a faulty module cannot bring the device down. Updates go through A/B slots with signed full images (minisign): a failed update automatically falls back to the working state. No forced account, no telemetry, no app from a foreign store.
Why build it this way
Because “just grab an Android tablet” is convenient, but it sends old devices to the landfill and forces users into a foreign ecosystem. Rust directly on a minimal Linux proves it: with control over the entire stack, weak hardware becomes something decent — sustainable and independent.
- 05
Our own post-quantum encryption scheme
What it is
A self-designed end-to-end scheme that secures data — in addition to transport encryption (TLS) — against attacks by future quantum computers. It combines exclusively NIST-standardized building blocks — key encapsulation with ML-KEM (FIPS 203), derivation via HKDF-SHA-512, content encryption with ChaCha20-Poly1305 — in pure Rust, without a single C library.
What it delivers
“Harvest now, decrypt later” runs into a dead end: anyone recording traffic today to crack it in ten years with a quantum computer faces a quantum-safe scheme. Every request gets a fresh, ephemeral key pair; the server key is replaced daily by a one-way function and cannot be reconstructed from any later state of the machine — so recorded traffic stays closed even if the server later falls into the wrong hands. The client key is cryptographically bound to the response: a diverted response is exposed immediately.
Why build it ourselves — and what we don’t build ourselves
We explicitly do not reinvent the mathematical primitives — that would be reckless; we rely on the vetted, standard-compliant implementations. What doesn’t exist as a ready-made library is precisely this combination and application: a quantum-safe end-to-end channel over TLS, ring-free, runnable all the way into WebAssembly. This scheme is what we built — and the same pattern already runs in production in our enterprise platform.
- 06
Standards-compliant e-invoice validation in Rust
What it is
A validation tool that checks electronic invoices against the European standard EN 16931 — in Rust, with the original official validation rules (KoSIT-XRechnung, CEN Schematron, Mustang/Factur-X), not reimplemented. It runs as a native application and as a WASI component from one codebase, without file or network access (the sandbox is given only clock and randomness).
What it delivers
Reliability you can prove: across the official test suite, our validation delivers the exact same verdict in 255 of 255 cases, bit-for-bit, as the official reference. At the same time it is many times faster than the heavy Java toolchain (around 27 times for one document type) and pulls in barely 60 third-party components — ring-free, embeddable wherever the invoice arrives (server, browser, gateway), instead of as an external service.
Why build it this way
Because standards compliance must not be “it should fit, really,” but provable. And because the same validation logic runs as a WASI component directly at the point of processing, instead of alongside it as a heavyweight add-on service.
- 07
Our own network gateway with interchangeable WASI modules
What it is
A self-built office appliance on a small computer: a single Rust service handles DNS, DHCP, routing and VPN — without Docker, without a third-party appliance, with the entire operation running in RAM (resilient to power loss). The actual logic (filter rules, routing, status page, certificates) sits in four WASI modules that can be swapped out while running (hot-swap). Plus a cross-platform control center for Windows and Linux.
What it delivers
Full control over the office network in an auditable piece of software instead of a black box — safeguarded by over 360 tests, many of them “trap tests” that nail down bugs once encountered for good. A faulty module cannot crash the core (sandbox); if it fails, the core keeps deciding by the same rule. Rules change without a restart. And: this very appliance serves the page you are reading right now.
Why build it this way
Because a gateway is the heart of an office network — there you want to know what’s running and, in case of doubt, be able to repair it yourself. That is only possible with your own lean code, not with an off-the-shelf box.
- 08
Automation & interfaces in everyday administration
What it is
Small, sharply tailored tools that take the tedious routine out of administrative processes. In production: a time-tracking extractor in Rust that reads hours and department data from a cloud service via OAuth2, projects overtime to the end of the month and outputs a finished multi-sheet Excel report. In development: an automated depreciation run (AfA) with database connection and Excel export (currently a design study).
What it delivers
What used to be manual and copy-and-paste work now runs through reproducibly — fewer errors, less month-end stress, and the figures match the source because they come straight from it (read-only access to the third-party systems).
Why build it this way
Because standard software rarely builds exactly the bridge a specific process needs. A small, precisely fitting automation saves more time than any big all-purpose tool — and it belongs to the company, not to a subscription provider.
- 09
Technology PoC: interactive streaming in pure Rust
What it is
A proof of concept in which we deliberately tried out new technologies all in one piece — a pure Rust single binary (Leptos SSR+Hydrate, GPU rendering via wgpu, SQLite-in-Rust, consistently ring-free TLS). At its heart: a GPU-rendered, interactive view is streamed live into the browser — the graphics card draws the image, a hardware encoder packs only the change from the reference as an HEVC video stream, which the browser decodes via the modern WebCodecs API.
What it delivers
The difference is drastic: instead of sending a ~1.6 MB PNG for every frame, around 26 KB per frame suffice (a factor of ~60), because only the difference is encoded. Plus a session pool for several simultaneous viewers and a PNG fallback path when a browser can’t do WebCodecs. The result: smooth, interactive server-side graphics, without the client bearing the compute load.
Why as a PoC
Because you only understand new technology on something real — that’s what proofs of concept are for. Here we brought together GPU streaming, hardware codecs and WebCodecs and safeguarded it with over 870 automated tests: building blocks we can deploy deliberately in future products, because we once played them through cleanly.
More about this page’s stack on the technology page, the full range of services under Services. A concrete project in mind? Get in touch with us.