Overview
Shinro is the layer between firmware and application logic for robotics teams shipping on heterogeneous hardware. It compresses the integration tax every robotics team pays — perception, control, simulation, deployment, hardware abstraction — so engineering teams spend their time on the behavior that differentiates their robot, not on rebuilding the primitives that don’t.
The problem
Robotics development today is fragmented. ROS for the runtime graph. A separate deterministic runtime if you want hard timing guarantees. Vendor SDKs for each sensor and board. A separate simulator for each kind of physics. A handful of bespoke deployment scripts that someone wrote on a Friday afternoon and nobody is allowed to touch.
The learning curve is steep, and deployment to mixed-fleet hardware is artisanal and error-prone. Most teams end up paying a Ph.D. tax — hiring deep robotics specialists for every primitive, even the ones that should be commodity.
Shinro removes that tax for the primitives. Teams keep their specialists for the work that actually moves the product.
Three wedges
Ease of use
A visual Blueprint Editor for hardware composition. A flow canvas for behavior design. An embedded code editor for everything that needs to be code. An in-Studio simulator. A deployment manager. One tool, five modes, one mental model.
Teams compose their first robot in an afternoon, not a quarter.
AI-native
AI assistance is woven across the development lifecycle — at composition, at flow design, in the editor, in the simulator, and at deployment. Bring your own model: a perception module can run an on-device VLM while the deployment manager calls out to a hosted LLM for troubleshooting.
Engineers describe behavior in natural language and refine in code.
Deployment
Hot-swap module deployment lets you update a live system in place. Hardware-agnostic compilation handles Linux, Windows, macOS, Android, ESP32, Jetson, and more. Fleet-wide updates are on the roadmap.
Update a module in production without halting the rest of the system.
Ecosystem and marketplace
Every module is a descriptor — toolchain, library, hardware, capability, resource. The descriptors are the substrate. The marketplace sits on top of them: a place where users, companies, and Shinro itself share modules. Some licensed, some free to use. The descriptor format is the contract that makes the marketplace possible — a module published by one team can be composed, audited, and hot-swapped by another without either side having to coordinate. The marketplace backend is in active development, and a contributor community is forming around it.
Who this is for
Pre-Series-B robotics and hardware companies. Software-strong teams who do not have, and do not want to hire, deep robotics specialists for every primitive.
Not FAANG. Not solo hobbyists. Not pure academia.
If you are shipping a product, on heterogeneous hardware, with a small team that already has more roadmap than headcount — this is for you.
Status
Shinro is pre-MVP. MVP target is late May 2026.
The product is two parallel workstreams: Shinro Studio (the IDE you’ll use) and the Shinro Backend Kernel (the native code that makes everything underneath it work). Integrating them end-to-end is the immediate critical path. See Roadmap & Status for what exists today, what’s in active development, and what’s still on paper.