RTEworks About
We are a team of professional engineers who have spent the last two decades inside the AUTOSAR ecosystem. Our industry experts have shipped Classic and Adaptive on real production ECU programs, sat through ASPICE CL2 and CL3 assessments, written ISO 26262 ASIL-D safety cases that held up at audit, enforced MISRA C and MISRA C++ across generated and hand-written production code, and integrated AI into engineering workflows the way it actually should be. RTEworks is what happens when you take that experience and aim it at the tools and services the industry never quite got around to building well.
01 What we believe
Every product we build comes out of a problem we hit on a real automotive program. We use it ourselves first, then harden it for everyone else. The first version of Manifold solved an actual review meeting we did not want to sit through anymore.
BYOK is non-negotiable. Every AI workflow we ship runs on your own LLM endpoint, with your own keys, against your own architecture. Nothing of yours leaves your infrastructure. We never see your ARXML, your prompts, or your responses. This is a posture, not a feature.
When we sit at your team's table, the person there has done the work before. We do not staff projects with juniors and a senior cameo. Our engagements run small, focused, and senior. That is the only way we know how to deliver.
If your release plan depends on someone staying late, the system is broken. We build CI/CD, traceability, and review automation that treats your generated RTE / BSW code with the same rigor as your hand-written production code, and that makes the safe path the easy path to a signed ECU image. The output is your engineers going home at a reasonable hour.
02 The name
In AUTOSAR, the RTE (Runtime Environment) is the layer that makes every other layer possible. It is the connective tissue between software components and the basic services underneath. Without it, nothing composes. With it, everything does.
We named the company after the most boring and most important piece of infrastructure in modern automotive software because that is the work we do. Not the marketing layer. Not the demo layer. The layer that has to actually function for the system to run.
The works suffix is older and quieter. It is what engineering firms called themselves before "Labs" became fashionable. It implies a workshop, a forge, somewhere things get built and shipped.
03 How we work
We run lean. Every project we take on is staffed with engineers who have done the same work before, at production scale. We do not staff with juniors and visit occasionally. The person at your table is the person doing the work.
Our engagements are typically six to twenty-four weeks. We start with a scoped pilot, we measure the actual outcome against a number, and we hand off documentation and training so your team owns what we built after we leave. We do not become a permanent fixture. We become a multiplier.
04 Where we are
We work out of Michigan because that is where the work is. Every major US OEM has a footprint within driving distance. Most Tier-1 suppliers we work with have an office on the same highway as ours. On-site engagements happen weekly, not monthly, because the drive is short and the work is real.
For teams further out, we work remote-friendly with the cadence US-based automotive programs actually run. Our hours overlap fully with yours. Our release calendar tracks yours. We will not ask you to wait until Tuesday morning Tokyo time for an answer to a Friday afternoon Detroit question.
Reply with a one-paragraph description of what you are working on. We respond within a business day.