Referenzen
Wir reden nicht über Stacks — wir bauen sie
Von der Unternehmensplattform über den Betriebssystem-Kern bis zum eigenen Betriebssystem für Arbeitsplätze und Server: Was wir empfehlen, setzen wir zuerst bei uns selbst und unseren Kunden produktiv ein. Hier zehn Beispiele — die Auftraggeber bleiben ungenannt, die Technik nicht.
- 01
Unternehmensplattform für einen internationalen Industriekonzern
Was es ist
Eine geschäftskritische, buchhaltungsrelevante (GoBD-konforme) Fachplattform, die gewachsene Alt-Prozesse ablöst — Reisekostenabrechnung, E-Rechnung/ZUGFeRD-Verarbeitung, Belegerkennung, Exporte in SAP/DATEV-Welten. Rund 40.000 Zeilen Rust, Oberfläche und Logik durchgängig in Leptos + WebAssembly; ein einziger Prozess bedient zwei getrennte Mandanten (Kundenportal und internes Werkzeug).
Was es bringt
Dieselben Datentypen laufen nativ im Server und — nach WebAssembly übersetzt — im Browser: Es gibt keine zweite, abweichende API-Definition, die auseinanderdriften könnte. Über 230 Tests sichern die Fachlogik (Kontierung Deutschland/Schweiz, Genehmigungswege, Belegparser, Export). Kein PHP-/Node-Wildwuchs, keine Laufzeit-Überraschung im Quartalsabschluss.
Warum so bauen
Buchhaltungsrelevanz heißt: jede Verarbeitung muss belegbar korrekt sein. Rust macht Korrektheit zur Eigenschaft des Codes, nicht zur Hoffnung auf Testabdeckung. WASM bringt native Geschwindigkeit in den Browser, ohne ein schweres JS-Framework zu pflegen.
- 02
Eigener Betriebssystem-Kern — und ein Dateisystem der nächsten Generation in Rust
Was es ist
Ein selbst gepflegter Linux-Kernel (eigener Patch-Stack auf dem neuesten 7.3-Stand): latenz-optimierter Scheduler, Google-BBRv3, und als Alleinstellung sprachübergreifende Link-Time-Optimierung — C und Rust werden über die Sprachgrenze hinweg gemeinsam optimiert und ineinander inlinet, etwas, das der offizielle Kernel bewusst ausschließt. Dazu unser Herzensprojekt: das Next-Gen-Dateisystem Reiser5 nach Rust portiert, samt eigener Rust-Abstraktionen für die Dateisystemschicht des Kernels, die es nicht einmal in der Entwicklungsvorschau von Linux gibt.
Was es bringt
Unser Leitsatz: eine Behauptung ohne Messung ist keine Verbesserung. Also gemessen: Unter Volllast bleibt die Reaktionszeit (99,9. Perzentil) bei rund 30 µs statt über 1000 µs mit dem Standard-Scheduler — Faktor 34, im selben Systemstart gegengemessen; für Fokus-Anwendungen fiel die Latenz von 621 auf 11 µs. Die sprachübergreifende Optimierung senkt die Aufrufkosten an der C↔Rust-Grenze um fast die Hälfte. Beim Dateisystem geht es um die Zukunft: Rust bringt Speichersicherheit genau dorthin, wo ein Fehler bisher das ganze System und die Daten mitreißt — in den Kernel.
Warum wir das machen
Weil der Unterschied zwischen „läuft“ und „läuft flüssig“ im Kernel entschieden wird — und weil wir in sicherem Systemcode aus Rust eine echte Zukunft sehen. Dieses Stück ist kein Auftrag, sondern Überzeugung: Wir investieren hier, weil wir glauben, dass die Systeme von morgen so gebaut werden.
- 03
Eigenes Betriebssystem für Arbeitsplätze und Server
Was es ist
Eine komplett aus dem Quellcode gebaute Linux-Distribution (auf Gentoo-Basis) für Clients und Server — eine gemeinsame Basis in zwei Varianten (Arbeitsplatz mit Desktop, gehärteter Server). Dazu ein eigener Paket-Build-Host (Binhost), ein einziger selbst gepflegter Kernel (unser Kernel mit latenz-optimiertem Scheduler und den neuesten Dateisystemen als Modul) und ein Rust-first-Userland — moderne Werkzeuge in Rust statt alter C-Standbeine.
Was es bringt
Volle Kontrolle und kein Hersteller-Lock-in: Jedes Paket ist aus geprüftem Quellcode gebaut und auf die gemeinsame CPU-Basis der Flotte übersetzt, nichts Fremd-Binäres kriecht unbemerkt ins System, Client und Server teilen dieselbe gehärtete Grundlage. Aktualisiert wird rollend über den eigenen Binhost — immer aktuell, ohne großen Versionssprung.
Warum so bauen
„Aus Quellcode bauen“ ist bei uns Grundregel, kein Hobby — es ist die einzige Art, wirklich zu wissen, was auf der Maschine läuft. Das ist Sicherheit (nachvollziehbare Lieferkette, Härtung von Grund auf), Leistung (echte Optimierung auf die eigene Hardware) und Konsistenz (ein Stack über die ganze Flotte) in einem.
- 04
Wandkalender aus Alt-Hardware, zu neuem Leben erweckt
Was es ist
Ein in die Jahre gekommener Kalender-/Bilderrahmen, dem wir ein komplett neues Innenleben gegeben haben — ohne Android, ohne Android-App, wie es bei solchen Displays sonst Standard ist. Stattdessen ein eigenes, schlankes Betriebssystem auf Linux-Basis und eine Oberfläche, die direkt aus Rust auf den Linux-Framebuffer gezeichnet wird (ohne X11/Wayland-Zwischenschicht) — local-first, ohne Browser- oder App-Ballast.
Was es bringt
Selbst auf schwächster Hardware (sparsame ARM-Chips, 2 GB RAM) läuft eine flüssige Oberfläche: Ein rund 8,5 MB kleines, statisches Programm zeichnet nur neu, wenn sich etwas ändert, und schläft sonst. Datenquellen (Kalender, Wetter) laufen als austauschbare, sandboxed WASI-Module — ein fehlerhaftes Modul kann das Gerät nicht lahmlegen. Aktualisiert wird über A/B-Slots mit signierten Komplett-Abbildern (minisign): Ein misslungenes Update fällt automatisch auf den funktionierenden Stand zurück. Kein Konto-Zwang, keine Telemetrie, keine App aus einem fremden Store.
Warum so bauen
Weil „nimm ein Android-Tablet“ zwar bequem ist, aber Altgeräte in den Müll und Nutzer in ein fremdes Ökosystem zwingt. Rust direkt auf einem minimalen Linux beweist: Mit Kontrolle über den ganzen Stack wird aus schwacher Hardware etwas Ordentliches — nachhaltig und unabhängig.
- 05
Eigenes Post-Quantum-Verschlüsselungsverfahren
Was es ist
Ein selbst entworfenes Ende-zu-Ende-Verfahren, das Daten zusätzlich zur Transportverschlüsselung (TLS) gegen Angriffe künftiger Quantencomputer absichert. Es kombiniert ausschließlich NIST-standardisierte Bausteine — Schlüsselkapselung mit ML-KEM (FIPS 203), Ableitung per HKDF-SHA-512, Inhaltsverschlüsselung mit ChaCha20-Poly1305 — in reinem Rust, ohne eine einzige C-Bibliothek.
Was es bringt
„Harvest now, decrypt later“ läuft ins Leere: Wer heute den Verkehr mitschneidet, um ihn in zehn Jahren mit einem Quantenrechner zu knacken, steht vor einem quantensicheren Verfahren. Jede Anfrage bekommt ein frisches, flüchtiges Schlüsselpaar; der Serverschlüssel wird täglich durch eine Einwegfunktion ersetzt und lässt sich danach aus keinem späteren Zustand der Maschine mehr herstellen — mitgeschnittener Verkehr bleibt also auch dann zu, wenn der Server später in fremde Hände gerät. Der Client-Schlüssel ist kryptografisch an die Antwort gebunden: Eine umgelenkte Antwort fliegt sofort auf.
Warum selbst bauen — und was wir nicht selbst bauen
Die mathematischen Primitive erfinden wir ausdrücklich nicht neu — das wäre fahrlässig; wir setzen auf die geprüften, standardkonformen Implementierungen. Was es als fertige Bibliothek so nicht gibt, ist genau diese Kombination und Anwendung: ein quantensicherer Ende-zu-Ende-Kanal über TLS, ringfrei, lauffähig bis in WebAssembly hinein. Dieses Verfahren haben wir gebaut — und dasselbe Muster läuft bereits produktiv in unserer Unternehmensplattform.
- 06
Normkonforme E-Rechnungs-Prüfung in Rust
Was es ist
Ein Prüfwerkzeug, das elektronische Rechnungen gegen die europäische Norm EN 16931 validiert — in Rust, mit den originalen amtlichen Prüfregeln (KoSIT-XRechnung, CEN-Schematron, Mustang/Factur-X), nicht nachgebaut. Es läuft als native Anwendung und als WASI-Component aus einer Codebasis, ohne Datei- oder Netzzugriff (die Sandbox bekommt nur Uhr und Zufall).
Was es bringt
Verlässlichkeit, die man nachweisen kann: Über die amtliche Testsammlung liefert unsere Prüfung in 255 von 255 Fällen bitgenau dasselbe Urteil wie die offizielle Referenz. Dabei ist sie ein Vielfaches schneller als die schwere Java-Toolchain (bei einem Belegtyp rund 27-fach) und zieht nur knapp 60 Fremdbausteine — ringfrei, einbettbar überall dort, wo die Rechnung ankommt (Server, Browser, Gateway), statt als externer Dienst.
Warum so bauen
Weil Normkonformität nicht „müsste eigentlich passen“ sein darf, sondern beweisbar. Und weil dieselbe Prüflogik als WASI-Component direkt am Ort der Verarbeitung läuft, statt als schwergewichtiger Zusatzdienst daneben.
- 07
Eigenes Netzwerk-Gateway mit austauschbaren WASI-Modulen
Was es ist
Eine selbstgebaute Office-Appliance auf einem kleinen Rechner: ein einziger Rust-Dienst macht DNS, DHCP, Routing und VPN — ohne Docker, ohne Fremd-Appliance, der komplette Betrieb läuft im RAM (stromausfallfest). Die eigentliche Logik (Filterregeln, Routing, Statusseite, Zertifikate) steckt in vier WASI-Modulen, die sich im laufenden Betrieb austauschen lassen (Hot-Swap). Dazu eine plattformübergreifende Steuerzentrale für Windows und Linux.
Was es bringt
Volle Kontrolle über das Büronetz in einem prüfbaren Stück Software statt in einer Blackbox — abgesichert durch über 360 Tests, viele davon „Fallen-Tests“, die einmal aufgetretene Fehler für immer festnageln. Ein fehlerhaftes Modul kann den Kern nicht abstürzen lassen (Sandbox); fällt es aus, entscheidet der Kern nach derselben Regel weiter. Regeln ändern sich ohne Neustart. Und: genau diese Appliance liefert die Seite aus, die Sie gerade lesen.
Warum so bauen
Weil ein Gateway das Herz eines Büronetzes ist — da will man wissen, was läuft, und es im Zweifel selbst reparieren können. Das geht nur mit eigenem, schlankem Code, nicht mit einer Kiste von der Stange.
- 08
Automatisierung & Schnittstellen im Verwaltungsalltag
Was es ist
Kleine, scharf zugeschnittene Werkzeuge, die lästige Routine aus Verwaltungsprozessen nehmen. Produktiv: ein Zeiterfassungs-Extraktor in Rust, der per OAuth2 Stunden- und Abteilungsdaten aus einem Cloud-Dienst liest, Überstunden bis zum Monatsende hochrechnet und als fertige Mehr-Blatt-Excel-Auswertung ausgibt. In Entwicklung: ein automatisierter Abschreibungslauf (AfA) mit Datenbank-Anbindung und Excel-Export (derzeit als Designstudie).
Was es bringt
Was vorher Hand- und Copy-&-Paste-Arbeit war, läuft reproduzierbar durch — weniger Fehler, weniger Monatsende-Stress, und die Zahlen stimmen mit der Quelle überein, weil sie direkt von dort kommen (nur lesende Zugriffe auf die Fremdsysteme).
Warum so bauen
Weil Standardsoftware selten genau die Brücke baut, die ein konkreter Prozess braucht. Eine kleine, passgenaue Automatisierung spart mehr Zeit als jedes große Allzweck-Tool — und sie gehört dem Haus, nicht einem Abo-Anbieter.
- 09
Technologie-PoC: interaktives Streaming in reinem Rust
Was es ist
Ein Proof-of-Concept, in dem wir bewusst neue Technologien an einem Stück erprobt haben — ein reines Rust-Einzelbinary (Leptos SSR+Hydrate, GPU-Rendering über wgpu, SQLite-in-Rust, durchgängig ring-freies TLS). Herzstück: eine GPU-gerenderte, interaktive Ansicht wird live in den Browser gestreamt — die Grafikkarte zeichnet das Bild, ein Hardware-Encoder packt nur die Änderung zum Vorbild als HEVC-Videostrom, den der Browser über die moderne WebCodecs-API dekodiert.
Was es bringt
Der Unterschied ist drastisch: Statt für jedes Bild ein ~1,6 MB großes PNG zu schicken, reichen rund 26 KB pro Frame (Faktor ~60), weil nur die Differenz codiert wird. Dazu ein Sitzungs-Pool für mehrere gleichzeitige Zuschauer und ein PNG-Rückfallweg, wenn ein Browser kein WebCodecs kann. Ergebnis: flüssige, interaktive Server-Grafik, ohne dass der Client die Rechenlast trägt.
Warum als PoC
Weil man neue Technik erst an etwas Echtem versteht — dafür sind Proof-of-Concepts da. Hier haben wir GPU-Streaming, Hardware-Codecs und WebCodecs zusammengeführt und mit über 870 automatisierten Tests abgesichert: Bausteine, die wir in künftigen Produkten gezielt einsetzen können, weil wir sie einmal sauber durchgespielt haben.
Mehr zum Stack dieser Seite auf der Technologie-Seite, das volle Leistungsspektrum unter Leistungen. Ein konkretes Vorhaben? Sprechen Sie uns an.