About // eramux
The legal record.
eramux UG is the parent. Each product is operated from inside the same entity with its own brand, surface and contracts, but one engineering bench, one set of standards, one balance sheet.
- Entity
- eramux UG (haftungsbeschränkt)German limited-liability entrepreneurial company
- Registered office
- Richard-Strauss-Straße 31 · 81677 München · Deutschland
- Director
- Daniel SchneiderGeschäftsführer · sole authorised representative
- Founded
- 2024
- Commercial registry
- Amtsgericht MünchenHRB 297923
- VAT identification
- DE450895728USt-IdNr. (Umsatzsteuer-Identifikationsnummer)
- Status
- operating · independentpublic release cadence intentionally low
A handful of principles
we don't bend.
The studio is opinionated on purpose. These principles are how we end up shipping smaller, sharper, faster tools than we'd otherwise build, and why each one feels like the same studio underneath.
Local-first, cloud-coordinated.
Data lives on the user's machine by default. The cloud handles only what local can't: synchronisation, reconciliation, collaboration. Never your storage by default.
Engineering as the standard.
Strong types, end-to-end traces, every error path thought through, runbooks for everything in production. The work that never demos well and always decides whether a tool lasts.
The primitive is the product.
Find the single operation the user actually performs and rebuild the tool around it. Surface area shrinks, latency drops, confusion disappears.
Models earn their place.
Deterministic algorithms first. Models only when an algorithm provably can't do the job, benchmarked against the alternative, and replaced when the alternative wins.
Stay on the tool.
Whoever ships a product keeps operating it. No hand-offs, no "v2 team". What exists is what we maintain.
Quiet, then loud.
We don't preannounce. We release when there's something sharp enough to defend, and then we say so clearly. Roadmaps are private.
Free at the bottom,
paid only on top.
The free baseline is not a marketing trick. It is how we keep the studio honest in every category we touch: the primitive has to be good enough that the paid layers above it have to earn their keep. If we can give it away, we do.
The primitive is free.
Some categories price the primitive like infrastructure and ship it like a prototype. Where that's the case, we publish the primitive for free and earn only on the surface above it. The work on top funds the studio; the primitive does not collect rent.
Better than the incumbents.
Categories don't get to coast on incumbency. Across every industry we ship into, where the loudest tools are overpriced and underbuilt, we build the version that should already have existed, ship it free, and build the paid surfaces around it. We hold ourselves to a higher engineering bar than the category does, and we let the bar do the talking.
Hypothesis to handover,
in four stages.
Every product runs through the same pipeline. If a stage can't be measured, it doesn't count. If the next stage isn't earned, we don't move on.
Sharpen the problem.
One paragraph that describes the operation, the user, and the failure mode of the existing solution. If we can't write it, it isn't the problem yet.
Build the smallest thing.
A working spike in days. Crude UI, real data, a measurable outcome. If the spike doesn't move the needle against what's already shipping, we kill it here.
Make it boring.
Strong types, observability, fault injection, load tests, a runbook. The least glamorous phase, and the one that decides whether the tool survives real production use.
Release, then maintain.
Private beta → public release → quiet stewardship. Whoever built it keeps operating it; we don't move on the day it goes public.
Two disciplines,
one engineering bench.
On the surface these read as two kinds of work; underneath it is one bench and one set of standards. The studio is the constant: the work changes with the problem, the engineering bar doesn't.
Systems & application engineering
The deep technical work: regulated, high-stakes environments where audit, observability and safe rollback aren't features but the baseline. Both the systems behind our own products and the selective client engagements that share the bench. Already live; the clients just aren't ours to name.
Product development
The named products and the unannounced ones; each a single-purpose instrument, held to a higher engineering standard than the category usually bothers with. Small surface, narrow promise, the long-tail work that decides whether a tool lasts.
Where the studio is, today.
Numbers we can show, with the rest withheld until they're worth quoting. We add to this as new products move from internal use into the world.
A short, honest log.
The studio is young; the timeline is short by design. We add entries as things ship, not when they're imagined.
Partnerships, beta access, press,
or just comparing notes.
We reply to most messages as soon as we reasonably can. The faster the message gets to the point, the faster the reply.