One product.
Three disciplines.
RMR Dynamics builds engineering tools that share one model of what you are making. Code, board, and enclosure stay in sync — instead of meeting again at a file export.
Hardware design is three tools and a spreadsheet.
The board comes from one vendor, the enclosure from another, and the firmware from a text editor. Each is good at its own job. The problem is the space between them — where a connector dimension is copied by hand, a thermal budget is estimated, and nobody notices the mismatch until the parts arrive.
Our tools are built around one shared model of the product instead of three files that meet at an export. A change in one discipline shows up in the others while it is still a conversation, not a rework order.
What we build
Three disciplines, each with its own tool — designed together rather than bolted together.
Every design ends up
in someone's hands.
A drawing is a promise. The workshop is where it gets tested — real tolerances, real materials, no undo. Better to find the conflict in the model than in the sparks.
From brief to build
The point of one model is that the whole product can move through one workflow, rather than three that meet at the end.
Describe the product
A brief in plain language: what it does, roughly how big, what it has to connect to. No template to fill in first.
Work the three disciplines
The assistant proposes a board, an enclosure, and the firmware that ties them together — and you steer each one in the same way.
Resolve the conflicts
Where the disciplines disagree — a connector that no longer clears the case, a thermal budget that no longer holds — you find out before fabrication, not after.
Take it to manufacture
Exports for the board house, the machine shop, and the compiler, all from the same design that you have been looking at the whole time.
A whole product,
not a folder of
files.
The tools are the foundation, but the goal is the engineering itself. A product is a board, a case, firmware, and a hundred decisions that tie them together — and those decisions are usually spread across three specialists who each see only their part.
We are building toward being able to take a product from an idea to a design you can build from, with the engineer reviewing and directing rather than assembling. That is the ambition, and it is a long road — but it is the reason the tools share a model in the first place.
The ambition
One model of the product, in every discipline.
How we build
One model, not three files
The board, the case, and the code are views onto the same product definition. There is no import step where information quietly gets lost.
Conversation as an interface
Every tool is driven by chat as well as by mouse, and the same way in all three disciplines. Learn one, and you know how to ask the others.
Your machine, your data
The tools are local applications. Your designs and your model credentials do not have to leave your computer to be useful.
Every tool is designed to be driven by an assistant.
Each of our tools is operated through a conversation as well as a mouse — the same way in all three disciplines. The long-term goal is a single brief that carries from an idea to a design you can build from, with the engineer reviewing decisions rather than performing every step.
We are early. The tools are in active development, at different stages.
Follow along
We are building in the open. Create an account to follow progress, or get in touch about what you would use it for.