Miru

What do they actually do

Miru provides hosted configuration management for robot fleets. Teams get a web dashboard and cloud APIs, a small agent that runs on each robot, and developer tools (CLI and SDK) to define schemas and manage config instances. Current capabilities include typed schema validation, a visual editor, history/audit of changes, device and release management, and programmatic access so config changes can run through CI/CD pipelines (docs, product changelog).

In practice, engineers push schemas and configs via the CLI or API, product/ops edit values and stage releases in the dashboard, and the on-robot agent pulls the deployed config; the SDK exposes config to the robot application as typed objects (C++ supported today) with a full audit trail for who changed what and when (blog, docs). Miru shows at least one production user (Pickle Robot Co.) and is listed by YC as an active S24 company with a focus on pushing changes, provisioning devices, and fleet deployments (site, YC profile).

Who are their target customer(s)

• Robotics software engineers: They need a single source of truth for configs with schema validation and typed access in code. Today they juggle scattered files and risky runtime edits without guardrails.
• Deployment/support engineers and operators: They must push releases, run rollouts, and debug issues across fleets. SSH-based changes and ad‑hoc tools make rollouts slow and obscure who changed what.
• Product/field operations (non‑engineer operators): They need to adjust per-site or per-customer behavior safely. Without scoped overrides and staged releases, changes either wait on engineering or risk breaking live systems.
• Robotics startups / fleet owners: They manage many robots, need to provision devices, prevent config drift, and keep per‑customer or per‑hardware differences consistent while tracking history across the fleet.
• DevOps / CI engineers: They need programmatic config management and schema checks in CI/CD. Lacking these, automated, safe rollouts and audits are hard to implement.

How would they acquire their first 10, 50, and 100 customers

• First 10: Directly recruit a few robotics startups and fleet operators for hands‑on pilots; the team handles initial schema import and agent install and secures a champion who will co‑author a case study.
• First 50: Turn early wins into references; run technical workshops and publish templates for common robot stacks and CI workflows; use SDR/solutions pilots with a tight 2–4 week playbook focused on schema validation, dashboard edits, and audit trails.
• First 100: Enable self‑serve with docs, SDKs (Rust/Python), and Git/CI integrations; list on robotics/IoT marketplaces; partner with OEMs, SIs, and OTA/CI vendors; offer clear self‑serve and enterprise tiers to move pilots to production at scale.

What is the rough total addressable market

Top-down context:

Mobile robots (AMRs/AGVs and service robots) represent a multi‑billion‑dollar market, with Interact Analysis estimating about $4.5B revenue in 2023 and continued growth; shipments are expected to rise significantly through 2030 (Interact Analysis, ABI Research).

Bottom-up calculation:

Using an installed base of ~2.7M AMRs/AGVs and per‑robot annual pricing of $12, $120, and $600 yields ~$32M, ~$324M, and ~$1.62B TAM scenarios, respectively (industry summary). Per‑device SaaS benchmarks like balena/Particle support these price points, with higher enterprise tiers raising ARPU (balena pricing, Particle pricing).

Assumptions:

• Addressable installed base for near‑term focus: ~2.7M mobile robots (AMR/AGV).
• Per‑robot annual revenue scenarios of $12, $120, and $600, anchored to IoT SaaS comparables and enterprise contracts.
• Not all robots are addressable; adoption is a fraction of the base, but shipments are growing quickly (expanding TAM over time).

Who are some of their notable competitors

• Balena (balenaCloud): Runs and updates containerized apps on fleets with a dashboard and OTA; notable for provisioning and software delivery at scale. Focus is software/OS updates rather than typed, operator‑editable config with audit.
• AWS IoT (Device Shadow & Device Management): Cloud primitives for device state, jobs/OTA, and fleet management; powerful building blocks but not a robot‑focused UI with schema validation and an on‑robot config SDK.
• Mender: OTA update management and phased deployments for embedded Linux with features for unreliable networks; centered on software/image updates rather than runtime config schemas and audit workflows.
• LaunchDarkly: Feature flagging and progressive delivery for software applications; analogous rollout controls but not built for device/robot runtime config or on‑device agents.
• Particle: End‑to‑end IoT platform (device OS + cloud) with provisioning, OTA, and cloud variables/functions; oriented to microcontrollers/edge devices, not typed, versioned robot configs with operator editing.