Deployment OS for assistive home robots that turns severe-mobility pilots into reliable daily-task programs for rehab providers.

1. Non-humanoid robots are suddenly more credible for home use because the leading real-home story is about safer, more deployable wheeled systems rather than lab-bound humanoids.
2. Severe-mobility users are showing concrete independence gains now, which means buyers can justify budgets around daily-living outcomes instead of speculative future autonomy.
3. Commercial hardware is available at a defined pilot price point today, so deployment repeatability becomes a near-term operational problem rather than a future robotics research question.
4. A sold-out first production run indicates enough early demand that support and rollout bottlenecks will appear before the market reaches mass consumer scale.
5. Hello Robot explicitly frames current pilots as a way to learn what scales in the home, validating that the missing infrastructure is deployment and reliability knowledge.

Catalyst. Stretch 4 is available now, sold-out demand is already visible, and the company itself says current pilots are about learning what scales in the home, making deployment standardization newly urgent.

Home Robot Independence Ops gives rehab providers a structured way to launch and manage each assistive robot deployment. Before installation, the provider captures a lightweight room map, target tasks such as breakfast prep or object retrieval, and the user’s reach and support constraints; the system converts that into a recommended task pack and setup checklist. After deployment, it monitors task completion, navigation failures, caregiver interventions, and downtime, then routes remote support or retraining when a workflow degrades. The product also creates a reusable library of validated home-task templates across kitchen, bedroom, doorway, and medication workflows so each new deployment starts from prior evidence rather than from scratch. That makes a small fleet of assistive robots manageable for providers that are not robotics labs.

What's different. Robot OEMs will focus on hardware, core autonomy, and a small number of marquee pilots, while rehab providers are not equipped to build robotics operations software internally. This startup becomes the neutral deployment layer that captures home-layout data, task success patterns, clinician approvals, and recovery playbooks across many installations and vendors. That dataset compounds into a defensible edge because the hardest know-how in this market is not generic manipulation intelligence; it is knowing which home tasks work reliably for which user profiles under what setup conditions.

Jobs to be done

flowchart LR
  Buyer[Rehab provider] --> Pain[Bespoke home robot installs fail to scale]
  Pain --> Product[Home robot independence ops]
  Product --> Outcome[More reliable daily-task independence with lower support burden]

Executive takeaways

• Real home-assist hardware exists now, but operators still need human-in-the-loop control, pilot learning, and recovery workflows; that makes deployment software more urgent than a new embodiment layer. [1][2][4][37]
• The best initial buyers are provider organizations, not consumers, because severe-mobility use cases require clinician sign-off, home setup, caregiver training, and support labor that families cannot standardize alone. [8][9][11][16]
• The field is crowded with adjacent hardware and companion products, but not with neutral home-deployment operating systems; direct rivalry is therefore moderate today and likely to intensify only after fleet volumes rise. [19][24][29][31][38]
• Budget viability depends less on replacing all care than on reducing failed installs and support hours; compared with $35/hour home-care labor and five-figure robot hardware, a provider-facing deployment layer can clear ROI if it speeds time-to-independence. [4][27][30][41]

Market definition

This is not the whole consumer home-robot market. The relevant spend sits at the overlap of assistive service robots, home/personal care robots, and rehab operations software that standardizes intake, task validation, caregiver training, and remote support for high-acuity home deployments. IFR explicitly includes limited-autonomy assistance robots inside service robotics, which fits this wedge better than a pure consumer-gadget frame. [19][20][21]

Customer and buyer

End users are adults with severe mobility impairments living at home, especially cervical SCI and other conditions where upper-extremity function drives ADL independence, but the economic buyer is the provider organization coordinating deployment, documentation, and support. Family caregivers remain heavily involved even when professional care exists, making provider workflow the more practical early buyer wedge. [6][8][9][11][16]

Buying triggers

• A provider orders its first serious home-robot cohort and discovers that every install still requires bespoke room setup, task selection, and caregiver coaching. [1][2][24][25]
• Clinical teams need a faster path from delivery to a reliable first daily-living outcome for high-acuity users. [2][8][11]
• Manual support becomes too expensive when staffing pressure meets high home-care labor costs. [9][31][41]

Willingness to pay

Current robot price points already span from financed consumer-style models (Labrador, ElliQ) to a $29,950 assistive platform (Stretch 4), while hospital robots are sold as tailored robot-as-a-service. Against $35/hour non-medical caregiver costs, a deployment OS can justify budget if it materially shortens time-to-independence or reduces support hours per active robot. [4][27][30][31][32][41]

Category dynamics

Growth signal 11.5% CAGR

Validation signals

• Hello Robot says the first Stretch 4 production run is already sold out and expects to manufacture 200-300 units.
• Labrador reported alpha pilot usage as high as 100 uses per month in real homes.
• Diligent positions robot implementation as weeks, not months, showing customers already value deployment discipline.
• AARP found 43% of older adults who plan to stay put expect to make home accessibility modifications, and technology is part of the plan.

Regulatory & technical constraints

• ISO 13482 sets safety expectations for personal care robots and explicitly notes unresolved impact and injury-limit issues for some hazard classes.
• Current Medicare reimbursement structures clearly cover traditional DMEPOS items and home-health services, but not a home robot deployment OS.
• Any health or independence claims in marketing must be substantiated with competent support.
• Reliable deployment still depends on navigation, manipulation, and recovery stacks that are production-grade but not plug-and-play in cluttered homes.

Today’s field splits between OEM-first assistive platforms (Hello Robot), constrained home utility robots (Labrador), companion/wellness systems (ElliQ), workflow-heavy enterprise robot operators (Diligent), and attention-grabbing humanoid aspirants (1X, Figure). None is a neutral deployment OS purpose-built for rehab-led, multi-home assistive programs. [1][2][24][29][31][38][40]

Why incumbents do not win by default

• Open robotics stacks. ROS-era tooling gives navigation and manipulation primitives, but not clinician workflow, home-readiness sign-off, or provider support operations.
• Robot OEMs. OEMs focus on hardware, core autonomy, and selling pilots; they do not win cross-vendor deployment workflow by default.
• Companion robot vendors. Companion systems prove subscription willingness in care tech, but they do not solve physical ADL deployment or home robot reliability.
• Enterprise robot operators. Hospital robot companies prove implementation discipline matters, but their workflow playbooks are built for facilities, not cluttered private homes.
• Humanoid home robot vendors. Humanoid players are shaping expectations and scale narratives, but they are still proving household reliability rather than repeatable assistive deployment.

This company should start as a deployment operating system for U.S. complex rehab dealers and neurorehab providers that are placing small fleets of assistive home robots into the homes of adults with severe upper-limb mobility impairment. The urgent pain is not proving that a robot can help in theory; it is getting from delivered hardware to a reliable daily task such as breakfast setup or object retrieval without rebuilding the workflow for every home. The first customer is a provider launching its first 10-30 home robot cohort and discovering that home survey, clinician approval, caregiver training, and recovery support are becoming the real bottlenecks. The wedge is deliberately narrow: room-scan intake, validated task packs, clinician sign-off, caregiver training prompts, and remote reliability monitoring for high-acuity home deployments. That is faster to prove than selling a broad home robotics platform because the buyer can measure time to first reliable ADL, failed installs, support hours per robot, and pilot-to-production conversion inside one operating workflow. The best reason to believe is that orderable hardware now exists and early demand is visible, while both idea.yaml and research.yaml point to deployment standardization as the missing layer. The biggest open question is budget ownership: the inputs do not resolve whether provider operating budgets, OEM bundles, grants, or payer-linked programs will become the dominant payment path. Market sizing is plausible but still narrow at the beachhead, so venture upside depends on expanding from severe-mobility rehab deployments into aging-in-place and broader home-care robot programs after the first workflow is repeatable.

Problem

• Assistive home robot deployments still run like bespoke field projects, with each home requiring custom survey, task selection, safety review, and caregiver onboarding before the robot becomes useful.
• Providers cannot scale small fleets when robot failures, home-layout variance, and support escalations are tracked through spreadsheets, vendor calls, and therapist memory instead of a repeatable operating system.

Solution

• Provide a provider-facing deployment OS that turns room scans, user constraints, and ADL goals into validated task packs, setup checklists, clinician approvals, and caregiver training workflows.
• Monitor task completion, navigation failures, caregiver interventions, and downtime after go-live so support teams can recover failing workflows before the user abandons the robot.

Why we win

• The company targets the operating layer between robot OEMs and rehab providers, where hardware vendors do not naturally own cross-home workflow standardization and providers are not staffed to build robotics software internally.
• Over time the product can accumulate a defensible dataset on which task packs work for which home layouts, user profiles, and support conditions, which is more valuable in this wedge than generic manipulation intelligence alone.

Milestones

flowchart LR
  Wedge[Assistive home deployment wedge] --> MVP[Deployment OS MVP]
  MVP --> Proof[Faster activation and lower support burden]
  Proof --> Expansion[Provider expansion and OEM co-sell]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 10-15 U.S. provider programs can each support enough active robots to justify the researched year-3 SOM case.
• One provider cohort can show measurable ROI through faster activation and lower support hours before reimbursement clarity arrives.
• A limited set of bounded ADLs can be standardized across enough homes to keep deployments productized rather than purely custom services.
• Clinicians will trust software-mediated task activation when approvals, audit trails, and bounded workflows remain explicit.
• OEMs will partner or at least not block a neutral deployment layer because they do not want to own provider-specific workflow operations.

Open diligence questions

• Which budget signs first in practice for the first 10-30 home cohort: provider operations, OEM bundle, grant funding, or another channel?
• What share of early home deployments can use repeatable task packs without custom scripting or heavy teleoperation?
• Which two or three ADLs create the fastest measurable ROI for severe-mobility users and provider programs?
• How much post-install support time does a provider spend per active robot today, and what portion is preventable?
• How defensible is the company if Hello Robot or another OEM decides to bundle its own deployment workflow software?

Model sanity

• Revenue engine. Base-case revenue is driven by growing from 33 active robots at Y1 exit to 300 by Q4Y3 while steady-state revenue settles at the researched $8K per robot level.
• Must go right. The company must keep task-pack deployments template-led enough to hit the 70% gross-margin target while converting pilots into annual production cohorts.
• Model breaks if. If provider budget approvals or OEM telemetry access slow the sales cycle toward the downside case, cash falls below zero before the Y3 SOM target is reached.
• Next-round proof. The next round is justified once the company shows about 165 active robots, two annual conversions, and one repeatable partner-led expansion path by Q4Y2.

Scenarios

Sensitivity

flowchart LR
  Leads[Provider cohort leads] --> Pilots[Paid pilot cohorts]
  Pilots --> Robots[Active robots under management]
  Robots --> Revenue[Onboarding + recurring software revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash runway]

Flags: The model reaches the researched 300-robot SOM only at Y3 exit, so recognized FY2028 revenue is still below the $2.4M exit ARR implied by the SOM math. · Revenue per exit FTE remains below typical mature SaaS benchmarks because clinical implementation and field support still absorb real labor. · Budget ownership remains unresolved in the source material, so the sales-cycle and ARPU sensitivities are more fragile than the headcount plan.

• Channel ambiguity. The market may take longer to choose whether rehab providers, OEMs, payers, or direct-pay consumers are the dominant buying channel. Mitigation: Start with design partners that already control deployments today—complex rehab dealers and neurorehab programs—and keep the product vendor-neutral.
• Hardware immaturity. If assistive robots remain unreliable or ship too slowly, software buyers may postpone purchases because the installed base grows slowly. Mitigation: Begin with monitoring, workflow tooling, and support reduction for the earliest fleets, so value appears before mass hardware adoption.
• Clinical and safety liability. A poorly configured task pack could create safety issues in a high-acuity home environment and damage trust quickly. Mitigation: Keep clinicians in the approval loop, start with bounded low-risk tasks, and require explicit sign-off plus audit trails before activating new workflows.