Über uns // eramux
Die rechtlichen Eckdaten.
eramux UG ist die Muttergesellschaft. Jedes Produkt wird aus derselben Gesellschaft heraus betrieben, mit eigener Marke, eigener Oberfläche und eigenen Verträgen, aber einer Werkbank, einem Satz Standards, einer Bilanz.
- Firma
- eramux UG (haftungsbeschränkt)haftungsbeschränkte Unternehmergesellschaft nach deutschem Recht
- Sitz
- Richard-Strauss-Straße 31 · 81677 München · Deutschland
- Geschäftsführer
- Daniel Schneideralleinvertretungsberechtigt
- Gegründet
- 2024
- Handelsregister
- Amtsgericht MünchenHRB 297923
- Umsatzsteuer-ID
- DE450895728USt-IdNr. nach § 27a UStG
- Status
- aktiv · unabhängigVeröffentlichungstakt bewusst niedrig
Eine Handvoll Prinzipien,
die wir nicht biegen.
Das Studio hat bewusst eine Haltung. Diese Prinzipien sind der Grund, warum wir am Ende kleinere, schärfere, schnellere Werkzeuge ausliefern, als wir sonst bauen würden, und warum sich jedes darunter nach demselben Studio anfühlt.
Local-first, cloud-coordinated.
Daten liegen standardmäßig auf der Maschine der Nutzer. Die Cloud übernimmt nur, was lokal nicht geht: Synchronisierung, Abgleich, Zusammenarbeit. Niemals dein Speicher als Standard.
Engineering als Standard.
Strenge Typen, durchgängige Traces, jeder Fehlerpfad durchdacht, Runbooks für alles, was produktiv läuft. Die Arbeit, die sich nie gut vorführen lässt und immer darüber entscheidet, ob ein Werkzeug Bestand hat.
Das Primitiv ist das Produkt.
Finde die eine Operation, die die Nutzer wirklich ausführen, und bau das Werkzeug darum herum neu. Die Oberfläche schrumpft, die Latenz sinkt, die Verwirrung verschwindet.
Modelle verdienen ihren Platz.
Erst deterministische Algorithmen. Modelle nur, wenn ein Algorithmus die Aufgabe nachweislich nicht lösen kann, gegen die Alternative gebenchmarkt und ersetzt, sobald die Alternative gewinnt.
Am Werkzeug bleiben.
Wer ein Produkt ausliefert, betreibt es weiter. Keine Übergaben, kein „v2-Team“. Was existiert, ist das, was wir pflegen.
Erst leise, dann laut.
Wir kündigen nichts vorab an. Wir veröffentlichen, wenn etwas scharf genug ist, um es zu verteidigen, und sagen es dann klar. Roadmaps sind privat.
Unten frei,
oben bezahlt.
Der kostenlose Sockel ist kein Marketing-Trick. Er ist die Art, wie wir das Studio in jeder Kategorie, die wir berühren, ehrlich halten: das Primitiv muss gut genug sein, dass die bezahlten Schichten darüber sich ihren Platz verdienen müssen. Wenn wir es verschenken können, verschenken wir es.
Das Primitiv ist kostenlos.
Manche Kategorien bepreisen das Primitiv wie Infrastruktur und liefern es wie einen Prototyp aus. Wo das so ist, veröffentlichen wir das Primitiv kostenlos und verdienen nur an der Oberfläche darüber. Die Arbeit obendrauf finanziert das Studio; das Primitiv zieht keine Rente.
Besser als die Etablierten.
Kategorien dürfen sich nicht auf ihrem Bestand ausruhen. Über jede Branche hinweg, in die wir liefern: wo die lautesten Werkzeuge überteuert und unterentwickelt sind, bauen wir die Version, die längst hätte existieren müssen, liefern sie kostenlos aus und bauen die bezahlten Oberflächen darum herum. Wir setzen die Engineering-Latte höher, als die Kategorie es tut, und lassen die Latte sprechen.
Von der Hypothese zur Übergabe,
in vier Stufen.
Jedes Produkt durchläuft dieselbe Pipeline. Lässt sich eine Stufe nicht messen, zählt sie nicht. Ist die nächste Stufe nicht verdient, geht es nicht weiter.
Das Problem schärfen.
Ein Absatz, der die Operation, die Nutzer und den Fehlermodus der bestehenden Lösung beschreibt. Wenn wir ihn nicht schreiben können, ist es noch nicht das Problem.
Das Kleinste bauen.
Ein funktionierender Spike in Tagen. Grobe UI, echte Daten, ein messbares Ergebnis. Bewegt der Spike nichts gegenüber dem, was bereits ausgeliefert ist, beenden wir ihn hier.
Mach es langweilig.
Strenge Typen, Observability, Fault Injection, Lasttests, ein Runbook. Die am wenigsten glamouröse Phase, und die, die entscheidet, ob das Werkzeug echten Produktiveinsatz übersteht.
Veröffentlichen, dann pflegen.
Private Beta → öffentliches Release → stille Betreuung. Wer es gebaut hat, betreibt es weiter; wir ziehen nicht weiter an dem Tag, an dem es öffentlich wird.
Zwei Disziplinen,
eine Werkbank.
An der Oberfläche liest sich das als zwei Arten von Arbeit; darunter sind es eine Werkbank und ein Satz Standards. Das Studio ist die Konstante: die Arbeit wechselt mit dem Problem, die Engineering-Messlatte nicht.
Systems & Application Engineering
Die tiefere technische Arbeit: regulierte, hochkritische Umgebungen, in denen Audit, Observability und sicheres Rollback keine Features sind, sondern Grundvoraussetzung. Sowohl die Systeme hinter unseren eigenen Produkten als auch die selektiven Mandate, die sich dieselbe Werkbank teilen. Läuft bereits; die Kunden dürfen wir nur nicht nennen.
Product Development
Die benannten Produkte und die unangekündigten; jedes ein Instrument für genau einen Zweck, an einem höheren Engineering-Standard gemessen, als die Kategorie üblicherweise ansetzt. Schmale Oberfläche, klares Versprechen, und die Long-Tail-Arbeit, die entscheidet, ob ein Werkzeug Bestand hat.
Wo das Studio heute steht.
Zahlen, die wir zeigen können; der Rest bleibt zurück, bis er es wert ist, genannt zu werden. Wir ergänzen das, sobald neue Produkte vom internen Einsatz in die Welt wandern.
Ein kurzes, ehrliches Log.
Das Studio ist jung; die Chronik ist bewusst kurz. Wir ergänzen Einträge, wenn Dinge ausgeliefert werden, nicht, wenn sie erdacht werden.
Partnerschaften, Beta-Zugang, Presse,
oder einfach zum Austausch.
Auf die meisten Nachrichten antworten wir, sobald wir es vernünftigerweise können. Je schneller die Nachricht auf den Punkt kommt, desto schneller die Antwort.